Long existing Codex conversations intermittently fail to load in Cursor.
Short Codex conversations usually open normally, but longer existing conversations sometimes open as a blank panel or stay stuck loading. The behavior is intermittent: the same long conversation may load successfully sometimes and fail at other times.
Cursor is already updated to the latest version. I also tested both the latest/preview Codex extension and the release Codex extension, but the issue still happens.
The logs suggest a possible Cursor/Codex extension integration or host API compatibility issue. On startup I see:
Codex chat session item provider not registered errorMessage="nt.chat.registerChatSessionItemProvider is not a function" errorName=TypeError
When opening or restoring long threads, I also see IPC/broadcast and app-server queue warnings such as:
[IpcClient] Received broadcast but no handler is configured method=query-cache-invalidate
[IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
WARN codex_app_server::transport: dropping overload response for connection ConnectionId(0): outbound queue is full
I filed the same issue on the OpenAI Codex side as well:
Steps to Reproduce
Open Cursor with the Codex IDE extension installed.
Open the Codex extension panel.
Open a short existing Codex conversation.
Observe that it loads normally.
Open a much longer existing Codex conversation.
Sometimes the panel stays blank or stuck loading.
Reload Cursor and retry.
The same long conversation may sometimes load and sometimes fail.
Expected Behavior
Long Codex conversations should load reliably in Cursor.
If a host API is unsupported or the webview bridge is not ready during long thread replay, Cursor/Codex should show a visible error instead of leaving the panel blank or stuck loading.
I dug into the stack traces, and all three signals are coming from inside the Codex extension itself, not Cursor:
nt.chat.registerChatSessionItemProvider is not a function is a proposed VS Code API (vscode.proposed.chatProvider) that Cursor doesn’t implement. The extension falls back gracefully, which is why short threads still load, but this isn’t the cause of the long-thread issue.
[IpcClient] Received broadcast but no handler is configured (query-cache-invalidate / thread-stream-state-changed) is IPC inside the Codex extension, not Cursor messaging.
The key one is WARN codex_app_server::transport: dropping overload response ... outbound queue is full. That’s backpressure in the Rust-based app-server process used by the Codex extension (codex_app_server) when replaying a long history. This is entirely on OpenAI’s side.
The Codex extension runs client-side through its own app-server, and Cursor is only acting as the VS Code extension host. We don’t control conversation loading. So the fix needs to come from OpenAI, and you already opened the right issue.
The best place to track updates is that GitHub thread. If OpenAI asks for more diagnostic data, it makes sense to attach it there.