Browser extension API request: read-only ChatGPT conversation metadata/status events

Hi OpenAI team,

I’m building a local-first browser extension that helps organize ChatGPT conversations into a custom project tree: client → project → subproject → chat. The extension is intended to run locally in the browser and does not need access to message contents through an API.

The main missing piece is a stable read-only way to know basic conversation status, without relying on fragile DOM scraping.

The useful minimal API/events would be something like:

  • conversation_id
  • last_activity_at
  • generation_started
  • generation_completed
  • has_unread_update
  • current_visible_conversation_id
  • conversation_updated event

Use case:

A developer or power user can maintain their own local ChatGPT project organizer, link conversations to local project contexts, and see whether a chat is active, updated, or waiting for a response. This would make browser extensions and local productivity tools much more reliable and privacy-friendly.

Why DOM scraping is not ideal:

  • ChatGPT UI changes can break extensions.
  • It is hard to reliably detect when generation starts or finishes.
  • Extensions may need to observe too much page structure just to infer simple status.
  • A small read-only status API would be safer, more stable, and easier to build around.

This request is not about reading private message contents via API. The goal is only basic conversation metadata/status, so local organizers and browser extensions can avoid unreliable UI scraping.

I attached a small demo screenshot showing how this kind of organizer could look and where the missing status API would help.

Small MVP clarification:

Even a very limited read-only surface would already be useful. For example, browser extensions could work much more reliably with just:

  • current_visible_conversation_id
  • generation_started / generation_completed events
  • last_activity_at or conversation_updated event

This would not require access to message contents. It would simply allow local browser extensions to avoid fragile DOM polling when tracking basic conversation state.

Welcome to the dev Community! @Vigrius

Thanks for taking the time to write this up. I can definitely see how having access to lightweight conversation status metadata and events could make it easier to build reliable local tools and browser extensions without relying on DOM scraping.

I appreciate the detailed use case and the clear distinction that you're requesting conversation status information rather than access to message content.

I've passed this feedback along for consideration. Thanks again for sharing the idea and the MVP examples.