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.

Experience the same issue, on Windows, Mac, and Linux systems I run on. Slows down development significantly.

My experience is that it 'swallows' or loses your prompt when it's just posting a 'thinking' or moving to a new step.
it's not all the time, it's rare, and but it seems to happen when the chat log is active - something is just being added to it.

So, for long complex 'steering' prompts, it is safest to ctrl-c before you post them; because you could accidentally enter them 'just' as an update happens, and then they get lost **.

i don't have proof for this as it is so intermittent, but it is what i've begun to assume.

This has been around for awhile, a few months or so.

windows 11, vscode 1.130, 26.5721.30844

[** edit: as other have reported, they often seem 'lost' but will re-appear unexpectedly as very delayed steering prompts, minutes later. So if you re-send them, you'll be doubling up your steering, which often codex just considers and shrugs off but does cause extra wasted analysis]

Same as above, I can reproduce this very easily. Its definitely when the agent is "Thinking" or running commands as mentioned before. I often find myself thinking about follow-ups right after sending a prompt so I experience this all the time. It does queue it for a small amount of time before disappearing so I sometimes find myself playing the "click the steer button before it disappears" game 😄

MacOS Tahoe 26.5.2, vscode 1.130.0

It seems to have some strange behaviour. I've had instances of this happening where the prompts have disappeared and re-emerged later in the conversation, which has recently caused me significant inconvenience. Like others, I have experienced this on Windows and MacOS.

Well copy paste trick only works if you have only a single item in the queue, otherwise when it loses the entire queue, you are SOL. And forcing copy paste reduces trust in the tool. They have unlimited tokens but they can't fix this trivial bug?

Same thing on Code Insider's Window (1.131.0-insider) and latest codex (v26.5721.30844)

https://github.com/user-attachments/assets/b8479714-fc09-48bb-b249-220fef5a1420

For me as of today it no longer happens (so far).

UPDATE: It still happens. Before though, a queued message would disappear immediately, now I have about 2 seconds to force steer it before it disapears.

Ok. What I have found is, I can't use the latest codex (26.7) as it breaks all my multi-root projects and forgets all my chats. So I need to use the previous one, which sucks up all my steering prompts and doesn't acknowledge them. But if you have faith, type in your steering, just accept it will steer 'after it is finished', then all is good. *

Since steering was such a powerful yet fragile feature, having that visual confirmation was reassuring. But the bug is just the visual confirmation it seems, it still does it, just doesn't confirm it, or maybe execute when you expect.

** or not. often, most often, not

I also sort of suspect nobody at openai is using vscode which is why it is neglected.

I’m experiencing this in the Codex VS Code extension as well. Follow-up messages submitted during an active turn can disappear without being visibly queued or processed.

This wastes substantial usage: users must resend prompts and repeat work, while messages that later reappear may cause duplicated processing and consume even more quota. It makes follow-up queuing unreliable for long-running tasks.

note: Still encountering this in 26.5727.51351.

For anyone who also runs into this I've been pinged that way to get attention, is to upvote the issue, with the thumbs up emoji on the original post of the issue.

I’m experiencing this in the Codex VS Code extension as well. Follow-up messages submitted during an active turn can disappear without being visibly queued or processed. This wastes substantial usage: users must resend prompts and repeat work, while messages that later reappear may cause duplicated processing and consume even more quota. It makes follow-up queuing unreliable for long-running tasks.

anytime this happens they need to reset the limits for that person, maybe then they will have some motivation to fix it. lost a lot of work because of this issue.

Linux vscode:
26.727.40816

Still an issue; Kind of silly that this has gone on for +2 months across multiple distros, multiple versions, and seems reproducible very consistently.

CC @anp-oai @etraut-openai

Still happens, basically every time I tried to queue message

Confirming that this queue failure is still reproducible on a newer Codex extension in a Windows Remote-SSH setup.

Observed behavior

While Codex is already working, submitting a new follow-up prompt repeatedly fails to add it to the queue. The prompt is not reliably retained or processed, making it unsafe to queue new instructions during an active turn.

Expected behavior

A submitted follow-up prompt should be durably added to the queue, remain visible, and be processed in order. If enqueueing fails, the prompt should remain in the composer and the UI should show a retryable error.

Environment

VS Code

• Version: 1.133.0 Stable
• Commit: a5b500951314efd502d07465bd138dfbd714a960
• Connection: Remote-SSH

Codex extension

• Name: Codex – OpenAI’s coding agent
• Extension ID: openai.chatgpt
• Version: 26.810.52044
• Bundled Codex CLI: 0.148.0-alpha.9
• Installed and running in the SSH remote environment

Local VS Code client

• OS: Windows_NT x64, version 10.0.26100
• CPU: Intel Xeon Platinum 8375C, 4 logical CPUs
• Memory: 24 GB
• Environment: Virtual machine
• GPU: Microsoft Basic Render Driver; GPU acceleration mostly unavailable/software-rendered

Remote development host

• OS: Amazon Linux 2023.12.20260629
• Kernel: Linux 6.1.175-219.359.amzn2023.x86_64
• Architecture: x86_64
• Instance: Amazon EC2 r7i.12xlarge
• CPU: Intel Xeon Platinum 8488C, 48 logical CPUs
• Memory: approximately 372 GB
• Shell: Bash
• Not WSL and not a container

Other tools on the remote host

• Separately installed Codex CLI: 0.146.0-alpha.3.1
• Git: 2.50.1
• Python: 3.11.15
• Node.js is not available in the remote shell PATH

Confirming issue is still alive and real. Ubuntu, VSCode, Codex... Codex drops 75% or more of my follow-up changes that should be queued. Running 5.5 high. SSH webserver.

I am on Ubuntu over SSH too, since I see other people have suggested the problem is intermittent, but mine is 75% or more like @jgwisdala , maybe SSH is really the issue?

Confirming this on VS Code Codex extension 26.818.22352 with bundled CLI 0.148.0-alpha.21 and followUpQueueMode="queue". During an active turn, Enter/Ctrl+Enter can briefly show the queued follow-up/Steer bar, then the message disappears without delivery.

The extension log repeatedly showed:

[queued-followups] Failed to release send lock conversationId=<redacted>
[IpcClient] Received broadcast but no handler is configured method=thread-queued-followups-changed

Switching follow-up queueing off and running Developer: Reload Window restored message delivery for now; long-term stability is not yet confirmed. A newer Marketplace build (26.818.61809, bundled CLI 0.149.0-alpha.4.3) was available today, but I have not rerun this composer reproduction on it.