Environment
Surface: Codex IDE extension in VS Code.
**Codex version:**26.1007.21434, Linux x64.
OS and IDE:
Ubuntu26.04.1LTS; kernel7.0.0-38-generic
GNOME on Wayland
VS Code1.141.0
AMD Ryzen9 7900X,12cores/24threads
Approximately128GB RAM
AMD Radeon AI PRO R9700, Radeon Pro W7500, integrated graphics
Model and authentication: GPT-6.1 Sol, ChatGPT Pro account authentication.
At the time, I had five Codex overseer/coordinator chats open in separate windows and three Claude Sonnet sessions running.
Bug
Codex repeatedly appears stuck thinking and stops accepting messages.
The only recovery I’ve found is Developer: Restart Extension Host. I’ve been killing sessions, restarting everything, and reopening the overseer lanes in separate windows. It’s a bit annoying… and time-consuming.
I expect the composer to become available after a turn finishes. If Codex loses track of its turn state, it should recover without requiring an extension-host restart that also affects other extensions.
Reproduction
I don’t have a deterministic reproduction yet. The observed sequence is:
Work in a long-running Codex conversation alongside other agent sessions.
Submit a follow-up.
Codex appears busy, but the message fails with a timeout or missing-active-turn-ID error.
Further attempts fail.
Restart Extension Host restores access.
Multiple sessions were open, but we haven’t proved that concurrency caused the failure.
Diagnostics
Exact errors:
Error submitting message
timeout
Cannot steer conversation without an active turn id
Verified timeline —12October2026, BST/UTC+1:
08:18:03: Backend recorded the affected turn as completed.
08:18:36: Extension rejected a follow-up because it had no active turn ID.
08:19,08:21 and08:23: Further submissions timed out.
Other conversation events continued arriving during those minutes.
The backend turn had finished, while the interface still behaved as though it was running. Stale turn state is a hypothesis; the underlying cause remains unconfirmed.
Frequency: Recurring over the last week or so, requiring repeated recovery.
A later memory check showed approximately85GiB available RAM; that wasn’t measured at the exact failure instant.
Screenshots attached.
github report tagged on to
