Codex VS Code Extension: Disappearing Prompts, Stuck Requests, and What to Do
Users have reported that prompts in the Codex VS Code extension sometimes disappear without starting a task, or remain stuck as queued follow-ups. If you see these symptoms, do not assume that your PC settings or network are the only possible cause: the extension’s request handling also deserves investigation. Similar reports do not, however, establish a single confirmed cause for every case.
This guide explains what to check and how to respond while protecting your work. It is based on public issues and official documentation, not our own testing of a particular extension release.
Checked on October 5, 2026. All four issues below were open at the time of review. We did not find confirmation in those issues of a common root cause or a release that resolves all these symptoms. Check the linked reports for subsequent updates.
A slow response is different from a request that never starts
Codex can take time to read code or run tools. A task that appears in the conversation and continues updating is different from an input box that clears without a new task appearing. Conversely, a period without visible progress does not prove that a request has been permanently lost.
- Only the input box clears: check whether the submitted prompt appears in the conversation.
- A follow-up remains queued: check whether the previous task actually ended and whether pending items remain.
- A completed request appears pending again: compare the interface with the real execution result.
- Restarting helps temporarily: record whether the same conditions trigger the problem again rather than assuming it is fixed.
For example, if a file-editing request is missing from the conversation, inspect file changes and running work before resubmitting it. An absent message is not enough evidence that nothing executed.
What has actually been reported on GitHub?
The OpenAI Codex repository contains the following user reports. Dates follow the registration dates displayed on the GitHub pages. A reported environment should not be generalized to all users.
| Issue | Opened | Main reported symptom | Status when checked |
|---|---|---|---|
| #50075 | October 1, 2026 | After an update, the first submission clears the input without starting work. | Open |
| #50486 | October 3, 2026 | A processing state remains after completion, blocking or losing follow-ups. | Open |
| #50491 | October 3, 2026 | Messages fail to register on Windows; a full restart temporarily helps. | Open |
| #50653 | October 3, 2026 | Apparently missing prompts, indefinite loading, and completed requests displayed as pending. | Open |
Sources: First-submission report #50075, Persistent streaming-state report #50486, Windows message and queue report #50491, and Submission and pending-state report #50653.
These reports establish that other users describe similar symptoms. Filing an issue does not itself mean the developers have reproduced it or confirmed its cause. Even a closed issue requires interpretation: it may have been marked as a duplicate rather than fixed, and any fix may apply only to certain releases.
Why might follow-up prompts remain queued?
One possible explanation is a mismatch between a task’s actual completion and the extension’s internal state. The author of #50486 reports that markedStreaming=true remains after completion. Streaming means receiving a response incrementally; in this report, the flag is used to describe a task that the extension still treats as active.
Source: User report about a persistent processing state.
The following simplified flow explains how a state mismatch could affect subsequent requests. It is an explanatory example, not a verified diagram of the extension’s implementation.
| Stage | Expected flow | Possible flow with inconsistent state |
|---|---|---|
| Submit a prompt | Register and execute a task. | The input clears, but registration or execution is unclear. |
| Finish the task | Show completion and clear the active state. | A result is visible, but the active state remains. |
| Submit the next prompt | Execute a new task. | It remains queued, or display and execution disagree. |
The confirmed fact is that similar symptoms have been reported. State management is a reported explanation, not an established universal cause. Whether all cases share it, or whether your environment is affected, requires further evidence. Authentication and connection failures can also produce similar symptoms, so avoid diagnosing a single cause without examining the relevant logs.
Can this happen while the service status is normal?
Yes. The official status page is a starting point for identifying service-wide incidents, not a guarantee that every extension release and individual environment is error-free. OpenAI notes that its availability metrics are aggregated and individual availability can vary. The status page showed normal operation when checked for this article on October 5, 2026.
Source: OpenAI service status.
Comparing a short request in another client with the same account can help narrow the scope. If it repeatedly fails only in the extension while the app or CLI works, there is reason to investigate an extension-related problem first. If several clients fail, investigate service, authentication, usage, or connectivity problems too. A single success or failure does not prove the cause either way.
A safe order for troubleshooting
These steps are practical checks, not an official patch or guaranteed fix. If a missing request involved deletion, publishing, or deployment, verify the actual outcome before considering resubmission.
- Record the request and interface state. Keep the prompt, timestamp and timezone, last successful response, and visible pending items. Check whether the new prompt registered in the conversation.
- Inspect the real changes. For file work, inspect changes and running terminals. For an external service, inspect the outcome there. Avoid submitting the same request repeatedly.
- Protect your work. Save unsaved files. If you use Git, review the changes and commit only the intended work, or make a separate backup. Where possible, confirm whether active tasks completed or stopped before restarting.
- Fully close and reopen VS Code. If reloading the window does not help, close the relevant windows and relaunch. Do not make forced process termination your first step: it can lose unsaved work.
- Test a short, non-mutating prompt in a new chat. Ask for a one-sentence explanation, then a follow-up. If that works, add the conditions present during failure, such as an image attachment, one at a time.
- Compare clients and check for fixes. Use the same account and, where possible, model, but do not rerun uncertain work simultaneously elsewhere. Review extension updates and follow-up information in the related issues.
The author of #50491 reports temporary improvement after a full restart, while window reloads did not reliably help. This is a workaround worth evaluating, not a permanent fix or a guarantee for every environment.
Source: Report describing the effect and limits of restarting VS Code.
When should you consider an earlier extension version?
If the problem began immediately after an update and restarting does not let you continue working, temporarily comparing with a version you previously used may be reasonable. This guide does not identify a verified fixed release or a universally stable older version. First record your current version, release channel, and relevant settings.
On Windows, open Extensions with Ctrl+Shift+X and locate OpenAI’s Codex extension. Right-click it, choose Install Another Version, and select an available release. If necessary, temporarily turn off Auto Update for that extension only.
To return, update the extension and re-enable automatic updates. An older release may lack fixes or compatibility with newer settings, so do not treat it as a permanent solution. Test with read-only requests first and restore your recorded version and settings if the comparison makes things worse.
Source: VS Code documentation on extension versions and automatic updates.
What should you collect if the problem continues?
A timestamp and reproducible sequence make a report more useful than simply saying that the extension freezes. Gather the following without sharing passwords, authentication tokens, API keys, or private file contents:
- Codex extension version and release channel, VS Code version, and operating system.
- Model, authentication method, and failure timestamp with timezone.
- The sequence that triggers failure, including task completion and follow-up submission.
- Whether it happens in a new chat, with image attachments, or with queued follow-ups.
- Results before and after a full restart and in another client.
- Relevant errors from the same time period and redacted screenshots.
Open View → Output in VS Code and, if a Codex or OpenAI output channel is available, inspect the period when the failure occurred. Channel names and availability may vary by version. If you see errors such as 401, 429, or connection termination, preserve the timestamp and surrounding context rather than concluding that one error code explains the whole problem.
If an existing issue matches your symptoms and environment, use it as a reference. A new report should distinguish expected behavior from actual behavior and include a minimal reproduction sequence. When a fix is announced, check its version and scope, then retest the conversation flow that previously failed.
Check actual task state before blaming your PC
Other users have reported disappearing or queued prompts in the Codex VS Code extension. There is reason to investigate extension state handling, but evidence of similar symptoms is different from confirmation of a common cause or a fixed release.
Verify outcomes and protect your work first. Then use restarting, a fresh chat, and a client comparison to narrow the problem. Temporary recovery is not proof of a fix: combine the latest issue updates with what you can reproduce in your own environment.





