Goal stays in “Thinking” after a steered message was sent
Open 💬 3 comments Opened Jul 27, 2026 by JavierPiedra
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
What version of the Codex App are you using (From “About Codex” dialog)?
Version 26.721.41059
What subscription do you have?
Pro
What platform is your computer?
Darwin 25.5.0 arm64 arm
What issue are you seeing?
During an active Goal workflow, after a parallel task finishes, the main task can remain stuck in “Thinking.”
The goal does not advance: it does not continue to the next step, report a blocker, or return a response. However, it continues consuming tokens while showing no tool calls, visible progress, status update, or completion message.
What steps can reproduce the bug?
- Start a Codex task with an active Goal workflow.
- Run a parallel task as part of that workflow.
- Let the parallel task finish.
- Return to the main task.
- The main task may remain indefinitely in “Thinking” while token usage continues increasing and no visible work occurs.
Session ID: 019fa43d-4f1b-7171-a529-c7cd290de92f
What is the expected behavior?
After a parallel task finishes, the main Goal workflow should promptly continue with its next required step, report a concrete blocker, or finish.
It should not remain in “Thinking” or consume tokens without executing observable work.
Additional information
_No response_
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Not a duplicate. this was because of a steered message
This is not just a UI hang; it is an unbounded-spend state. A Goal should carry a progress lease: after the last tool call or subtask completion, require a new observable state transition within a bounded time or token budget. If the lease expires, stop generation, preserve the last verified checkpoint, and surface whether the root task is waiting on a child, a steer acknowledgement, or a tool result. “Thinking” should never be a valid indefinite state while spend is still accruing.
If you can reproduce it once more, run the same workflow through MartinLoop and share the receipt so we can see whether the missing transition is visible: https://github.com/Keesan12/martin-loop