Codex CLI may be nerd-sniped handling an interruption instead of resuming prior work
What version of Codex CLI is running?
codex-cli 0.128.0
What subscription do you have?
ChatGPT Pro
Which model were you using?
_No response_
What platform is your computer?
_No response_
What terminal emulator and version are you using (if applicable)?
_No response_
What issue are you seeing?
When I interrupt Codex mid-task with a separate request, it may handle the interruption and then stop, rather than returning to the work it was doing before the interruption.
Expected behavior: Codex should preserve the active task stack. If the interruption is additive and does not supersede the prior task, Codex should handle it inline or acknowledge it, then resume the previous task from the last safe point.
The agent should only abandon the prior task if I explicitly cancel it, the interruption clearly replaces the prior goal, or the interruption changes the prior work enough that clarification is needed.
---
Importantly, Codex cli is very good at incorporating additional detail on a large request over consecutive prompts that ~interrupt its thinking on an original prompt.
It is when a competing problem to be solved (a side quest) is introduced that it will fail to ~exit ~the recursion.
What steps can reproduce the bug?
- Ask Codex to perform a multi-step task, such as drafting or editing a technical brief.
- While Codex is partway through that work, interrupt with a smaller request, such as creating an issue, checking a command, or answering a quick question.
- After Codex handles the interruption, observe whether it returns to the prior task.
- Often, Codex treats the interruption as the only active task and stops instead of resuming the original work.
Example expected handling:
User: Create a v3 version of this briefing and make the remaining revisions.
Codex: Starts editing the v3 briefing.
User: Create a child issue for this work, then continue with your edit.
Codex: Creates the child issue, explicitly resumes the v3 briefing edits, finishes them, and reports both outcomes.The desired behavior is that interruptions are additive by default unless explicitly superseding.
What is the expected behavior?
_No response_
Additional information
_No response_
2 Comments
It is also acceptable--or even encouraged to simply acknowledge the competing task and delay handling it until it has finished the prior mainline task.
The user goal is often to "get something off my chest" rather than "do this now" but model must use its own judgement.
Thanks for the bug report. This appears to be model behavior, not a Codex harness issue. We'll share the feedback with the team responsible for training our codex models. If you see other model behavior that you'd like to report, please use the
/feedbackcommand. That will provide us with additional details including logs and conversation text.