Steering broken - codex stops ongoing work and steers off completely
What issue are you seeing?
This is a serious issue in how steering works (for comparison, this is exactly the opposite of how it works in Claude Code).
What steps can reproduce the bug?
- You give Codex some complicated work to perform, such as a bug fix. It's in the middle - half way through.
- Codex is working and producing thinking tokens
- You notice it pointing out something you did not expect to find in your code, such as a dependency in a
Gemfilefor a rails app, and so you say: I don't think we even use gem xyz in code- Codex COMPLETELY steers off - it should take my comment as an addendum to current work, not a 'Oh - I've been asked to do something COMPLETELY different'
- Codex then begins to discover and answer your question - it then ends with
Yes you're right, we don't use this...and nothing. It just stops.- I then have to say
Continue finishing the work and remove this gem then
What is the expected behavior?
I expect codex to take my commentary as extra information, additional work, hints, suggestions etc - not as a new thread of work. It should infer that we want to remove this gem as _part of the current work_.
It wasn't like this earlier as far as I can tell when it was in beta. I think in a recent commit I saw this behavior change into 'separating threads for steering' and that may have broken intended behavior.
Additional information
Claude Code for instance will always take your steer as a 'by the way' or 'check this too..' and you can see it at times responding back as You're absolutely right, I'll look into this. Let me first finish XYZ and I'll look into this.... In the above example, it would infer that we should also remove this gem as part of the bug fix.
11 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Maybe it's this: 0d8b2b74c46aeb7c691fcaf96156ed7927ee1d16
Are you using the CLI? Which version?
You mentioned that you think this might be a regression? Do you know which version you saw the change? Are you able to verify that it's a regression by downgrading?
@etraut-openai sorry -
codex-cli 0.99.0-alpha.9@etraut-openai I believe before that commit - a few days ago, at least when it was in _beta_. It was quirky then too - it wasn't always obvious it's _registered_ my commentary (or would miss the entry between token output / conversation seams - exactly as the commit points out). But the intended fix here potentially broke this.
This looks potentially related to my issue if this is present in 0.98, steering/interruption feels like a major regression as of current. Super latent on 5.3 pragmatic xhigh, roughly 4 minutes to process the steer/interruption.
Steer default on is not a good idea. Steer should let the task complete or to integrate the current task, not to break it and not to don't give any feedback about the ongoing task.
That doesn't work, because that's what it's already doing. I tell it to stop, and it ignores the message for four minutes. I want it to have the message immediately. Especially when I hit escape. The current implementation is broken, especially at xhigh which generates a massive amount of reasoning tokens.
<img width="1085" height="558" alt="Image" src="https://github.com/user-attachments/assets/552f6f9e-1a2d-49ef-a0f7-37a7fe6d0039" />
facing issue where next message sent stop current flow instead of message going to the queue . This seems be broken in last few releases . Issue is with cli. please suggest. this kind of breaks the whole workflow while coding.
@Chetansuri7 might be due to this bug: https://github.com/openai/codex/issues/11008
I think the issue is that Codex has no metadata that a comment is a steer vs a "regular instruction".
I've discussed with codex in detail, with me giving steers vs regular information. It does not see a difference between the two. They both look like identical user instructions, as a result, it doesn't have a cue whether to "hand control back to me" or "keep working". I believe a very simple fix would just be to add metadata to a steer message that its a steer, and an instruction to not stop working when it receives a steer.
I can consistently (80%) avoid the issue by typing at the end of every steer "keep working on your task", but its annoying to do so, and sometimes the interruption actually changes and messes up work.