VS Code/Cursor Codex Extension: Submitted Prompts Randomly Disappear Before Entering Queue

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #25268

Powered by Codex Action

@codex

What version of the IDE extension are you using?

Codex – OpenAI’s coding agent v26.602.40724

What subscription do you have?

ChatGPT Pro 229 € / month

Which IDE are you using?

VS Code

What platform is your computer?

Microsoft Windows 11 Home 25H2 26200.8524 1000.26100.315.0

What issue are you seeing?

Every now and then, but I have counted several times already, I send a prompt to my queue and it vanishes. It happens while Codex is working on a previous prompt and has not finished yet. That is very frustrating cause this has forced me to re-write many long prompts and now I have to copy them all before sending them to prevent the Codex extension to make me lose them...

@etraut-openai Please add server-side message queueing, I believe it's the same problem with the client-side caches sporadically having issues?

Same problem here. Please fix!

Hi Codex team @codex @openai,

I am seeing what appears to be the same issue reported in this thread: queued follow-up prompts sent while Codex is actively working sometimes disappear instead of being reliably added to the queue.

After comparing my setup with the setup reported by the original poster, this no longer looks like an issue limited to Remote-SSH or to a specific VS Code Server version.

My setup:

• VS Code Remote-SSH
• VS Code Server: 1.128.0
• Codex extension: openai.chatgpt@26.623.141536
• Remote OS: Debian Linux

The logs in my case repeatedly show:

[IpcClient] Received broadcast but no handler is configured method=thread-queued-followups-changed
[IpcClient] Received broadcast but no handler is configured method=thread-stream-state-changed
[IpcClient] Received broadcast but no handler is configured method=query-cache-invalidate

remoteexthost.log also shows:

PendingMigrationError: navigator is now a global in nodejs

I tried the usual cleanup steps for a possible Remote-SSH / extension state mismatch:

1. Uninstalled the Codex extension from the remote SSH host.
2. Reinstalled the Codex extension on the remote SSH host.
3. Confirmed that the Codex extension version is the same locally and remotely.
4. Killed / restarted the VS Code Remote-SSH server.
5. Reconnected to the remote host.
6. Reloaded the VS Code window.
7. Retested by sending multiple follow-up prompts while Codex was actively processing a turn.

The issue still reproduced after those steps. Some follow-up prompts were queued, but others appeared to be submitted and then disappeared.

However, the original report in this thread uses a different environment:

• Cursor version: 3.6.31
• VS Code Extension API: 1.105.1
• OS: Windows_NT x64 10.0.26200
• Codex extension: openai.chatgpt@26.5527.60818

That makes this look broader than my specific Remote-SSH setup. Remote-SSH may make the issue more visible in my case, and the navigator migration error may be additional noise or a related activation problem, but the core symptom seems to be the same: queued follow-up prompts are not being reliably persisted or rendered in the thread queue.

This may point to a race or state synchronization issue in the Codex extension queue handling, possibly between the extension UI/webview, IPC broadcasts, query cache invalidation, and the thread queue state.

Expected behavior:

All follow-up prompts sent while Codex is working should be reliably added to the queue and remain visible in the UI.

Actual behavior:

Only some follow-up prompts are queued. Others briefly appear to be submitted but then disappear and are not added to the thread.

This is especially disruptive for long-running Codex tasks, because queuing follow-up instructions is a core workflow feature. Without a reliable queue, users have to wait for each turn to finish before safely sending the next instruction.

Could the Codex team confirm whether this is a known issue, and whether there is a fixed extension version or recommended workaround for VS Code / Cursor users?

@Avnsx Did you get this issue fixed? Would you mind editing the start of this thread's title to "Cursor/VS Code"? Thanks!

Not fixed.. waiting for OpenAI.

Same problem

@supersekai64 @AndreasKaratzas Could you please share your Setup and what your logs say, in a similar way as I did? That could help us research on this as @codex team doesn't seem to care...

Confirming this is still reproducible on a current VS Code extension build.

Environment:

• VS Code 1.128.1 (x64)
• openai.chatgpt@26.707.91948
• Windows x64
• Local VS Code workspace (not Remote-SSH)

Reproduction:

1. Start a long-running agent turn in the Codex VS Code extension.
2. While the agent is still actively working, submit a follow-up message.
3. Intermittently, the message is swallowed: it never remains visible as queued/sent, never appears in the conversation context, and the agent does not receive it. No user-facing error is shown.

Observed on 2026-07-17: I sent a detailed follow-up about a favicon/PWA change while the agent was working. The message was absent when the agent later checked the conversation, so I had to resend it.

Expected: once Enter is pressed, the follow-up should be durably queued and remain visible. If queueing fails, the editor should preserve the text and show an explicit retryable error instead of silently discarding it.

This makes it unsafe to send follow-ups during long-running turns and forces users to keep external copies of prompts.

This is unacceptable, not only it loses the last sent prompt, I just saw it clears the entire queue so then when you come back, you see none of the queued prompts were done. How hard it is to do this, they are not even on the server side, so it should be easy to save the queue locally. OpenAI should provide limit reset anytime this happens. It causes loss of work.