Repository navigation
Codex with GPT-5.4 (1M context window, set to compact at 500k) keeps stopping for no apparent reason, and forgetting to wait on subagents. #13799
Description
What version of Codex CLI is running?
v0.111.0
What subscription do you have?
Pro
Which model were you using?
gpt-5.4 (reasoning high, summaries detailed)
What platform is your computer?
Darwin 25.3.0 arm64 arm
What terminal emulator and version are you using (if applicable)?
Ghostty
What issue are you seeing?
Codex repeatedly stops work or forgets to check on some in-progress task.
GPT-5.3-codex was really really good at this - truly relentlessly good - so this is a regression!
What steps can reproduce the bug?
Uploaded thread: 019cc496-d2c9-74c0-9308-1bf04b3f6243
What is the expected behavior?
No response
Additional information
No response
Activity
github-actions commentedon Mar 6, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
etraut-openai commentedon Mar 6, 2026
Thanks for reporting. It sounds like you're manually overriding the default context size and compaction threshold. Are you seeing the problem if you use the defaults?
LoadStar822 commentedon Mar 7, 2026
Under the default settings, I encounter this issue even when using GPT-5.4. It reports what it plans to do next and then just stops. It also appears extremely impatient and does not wait for the sub-agents. Even when a sub-agent is in the middle of modifying a file, it becomes unable to wait (it explicitly says it will not wait) and proceeds to modify the same file as well, which causes everything to become disorganized.
etraut-openai commentedon Mar 7, 2026
OK, it sounds like this is model behavior. We'll share the feedback with the team responsible for training our codex models. We're tracking this feedback and similar reports so we can improve future models. And thanks for using the
/feedbackcommand. That additional information is useful.DhruvDh commentedon Mar 16, 2026
I have the default context windows but also run into this reliably, so much so that I have considered disabling mutli-agents.
The root cause is model behavior yes but this behaviour can be managed at least partially via prompts and introducing some concept of time. So when a subagent is spawned there is some duration set as reasonable for the subagent work and that the model should not consider the subagent as hung before that time duration is reached.
I haven't looked into the code but I feel like this sort of thing is a solved problem from how background terminals are managed. In fact I feel if I just disable mutli-agents and instruct it to use codex exec in a background terminal it would work much better.
So while root cause is model behaviour, I would urge treating this as something to be fixed now, especially if the model behavior cannot be addressed in the near term due to no new model releases.
It would also not suprise me that the higher than usual "usage drain" is caused due to improper use of multiple agents. It's such a waste of compute to spin up subagents and close them without getting any use out of them.
Michaelihc commentedon Apr 8, 2026
I just tell it that for waiting just run a sleep command to save tokens
ariccio commentedon Apr 11, 2026
Ah, yes, sorry, @etraut-openai, did not see your question.
Yes, I'm using the long context beta. It's quite good overall, but has a few quirks like this. Mainly a model behavior issue... But hey, if we had prompt type stop hooks, we could also work around them!