codex - 💡(How to fix) Fix [extension][Windows][Cursor/Antigravity] Long existing threads open as blank panel while short threads load normally [1 comments, 2 participants]

What version of the IDE extension are you using?

• Cursor: openai.chatgpt-26.5417.40842-win32-x64
• Antigravity: openai.chatgpt-26.417.40842-win32-x64

What subscription do you have?

Unknown

Which IDE are you using?

• Cursor
• Antigravity (VS Code fork)

What platform is your computer?

Microsoft Windows NT x64

What issue are you seeing?

The Codex IDE extension can list recent chat sessions correctly, but opening a longer existing local thread often leaves the panel blank.

Observed behavior:

• The recent session list loads normally.
• Short sessions with only a few turns open quickly.
• Longer sessions reproduce a failure mode where:
  • the chat panel is empty,
  • Full access stays greyed out / stuck on loading,
  • the thread never becomes usable in the extension.

Important isolation detail:

• The exact same thread opens quickly in the Codex desktop app on the same machine.
• So the stored local session itself does not appear to be corrupt.
• This looks extension-side or extension-host-side, not a bad .codex thread file.

In my setup this reproduces in both Cursor and Antigravity, but not in the Codex desktop app.

What steps can reproduce the bug?

1. Install the Codex IDE extension in Cursor or Antigravity on Windows.
2. Open the Codex extension sidebar/panel.
3. Wait for recent local sessions to load.
4. Open a short session with only a few turns.
5. Observe that it loads normally.
6. Open a much longer existing local session.
7. Observe that the panel becomes blank and Full access stays stuck loading.
8. Open the same thread in the Codex desktop app.
9. Observe that the desktop app renders it quickly.

What is the expected behavior?

Long existing local threads should open in the IDE extension as reliably as they do in the Codex desktop app.

If a host feature is unsupported or a webview bridge is not ready yet, the extension should degrade gracefully instead of leaving the thread UI blank.

Additional information

This appears related to, but not identical to:

• #13343
• #14917
• #15393
• #15368

I inspected local logs and found two separate signals.

1. Proposed API / host compatibility problems in VS Code forks

Antigravity renderer logs report that the extension cannot use:

• chatSessionsProvider
• languageModelProxy

and explicitly suggest launching with:

--enable-proposed-api openai.chatgpt

Cursor logs are slightly different: they report that those proposals do not exist in the host.

So at least part of the failure is host compatibility, especially in VS Code forks.

2. Extension-side broadcast delivery appears brittle during thread replay

When opening an affected long thread, the extension logs fall into a bad IPC / webview state during thread replay.

Locally I observed failures in the sendBroadcast(...) path for events in this family:

• thread-stream-state-changed
• thread-read-state-changed
• client-status-changed
• thread-archived
• thread-unarchived
• thread-queued-followups-changed
• query-cache-invalidate

In Cursor, once replay starts, the bridge can enter a not-connected failure mode and the thread UI stays blank.

Local workaround that restored usability

I was able to restore behavior locally with a runtime-only patch:

1. Launch the editor with:

--enable-proposed-api openai.chatgpt

1. In the installed extension bundle, change broadcast sends to fail soft:

• if the target bridge/webview is missing, return instead of throwing;
• if sendBroadcast(...) throws because the bridge is not connected, catch and log a warning instead of tearing down the UI state.

Conceptually:

if (!bridge) return;
try {
  await bridge.sendBroadcast(method, payload);
} catch (err) {
  logger.warning("Dropped broadcast", { method, err });
}

That workaround is obviously not a real upstream fix, but it strongly suggests the extension currently assumes the webview bridge is present and connected during long-thread replay, and that assumption is false in some hosts or replay timings.

Proposed fix direction

• Handle unsupported proposed APIs gracefully in VS Code forks.
• Do not throw from thread replay / broadcast paths when the webview bridge is missing or disconnected.
• Consider buffering or skipping replay-only notifications until the webview has actually registered its handlers.
• Add regression coverage for opening a long existing local thread in:
  • VS Code
  • Cursor / VS Code forks if supported