Starting around September 30, 2026, the Codex VS Code extension intermittently starts queueing normal prompts even though the previous turn has already completed and no other request is running.
The problem usually does not happen immediately in a new thread. A new thread works normally for several messages, then eventually a normal completed response is followed by the next prompt being placed into the queue as if Codex still thinks another turn is active.
Sometimes the queued prompt disappears from the UI completely. Pressing the Up Arrow key restores the text in the input box, so the prompt appears to still exist in input/history state even though it is no longer visible as queued.
The problem has reproduced:
- after fully restarting VS Code
- in brand-new Codex threads
- after stopping use of multiple VS Code windows
- with only one VS Code window running
- after confirming there were no remaining VS Code/Codex processes
The immediately preceding Codex response can be a completely normal completed answer. No cancellation, interruption, compaction, approval dialog, or failed tool call is required.
Relevant log output shows the latest turn as completed while the thread is still marked as streaming:
latestTurnStatus=completed markedStreaming=true
The log also shows the queued-message send lock failing:
Failed to release queued message send lock ... errorMessage="\"undefined\" is not valid JSON"
A similar send-lock failure also occurs during extension startup.
Expected behavior:
After a turn completes, the next submitted prompt should start normally.
Actual behavior:
After several successful turns, Codex sometimes still treats the completed thread as streaming and queues the next prompt. The queued prompt may remain stuck, disappear, or later send successfully once the state recovers.
Environment:
- macOS, Intel
- VS Code
- Codex extension:
openai.chatgpt-26.928.40906-darwin-x64
log1.txt
Starting around September 30, 2026, the Codex VS Code extension intermittently starts queueing normal prompts even though the previous turn has already completed and no other request is running.
The problem usually does not happen immediately in a new thread. A new thread works normally for several messages, then eventually a normal completed response is followed by the next prompt being placed into the queue as if Codex still thinks another turn is active.
Sometimes the queued prompt disappears from the UI completely. Pressing the Up Arrow key restores the text in the input box, so the prompt appears to still exist in input/history state even though it is no longer visible as queued.
The problem has reproduced:
The immediately preceding Codex response can be a completely normal completed answer. No cancellation, interruption, compaction, approval dialog, or failed tool call is required.
Relevant log output shows the latest turn as completed while the thread is still marked as streaming:
latestTurnStatus=completed markedStreaming=trueThe log also shows the queued-message send lock failing:
Failed to release queued message send lock ... errorMessage="\"undefined\" is not valid JSON"A similar send-lock failure also occurs during extension startup.
Expected behavior:
After a turn completes, the next submitted prompt should start normally.
Actual behavior:
After several successful turns, Codex sometimes still treats the completed thread as streaming and queues the next prompt. The queued prompt may remain stuck, disappear, or later send successfully once the state recovers.
Environment:
openai.chatgpt-26.928.40906-darwin-x64log1.txt