What feature would you like to see?
When interrupting tool calls, the context of the tool call is not included when "telling Codex what to do differently". For example, if you want to ask why it needs to run a command or to not run the command it just tried to run, it doesn't know what you're referring to, and if it submits a patch that you want to make changes to, it doesn't know what you're trying to change, making it much harder to adjust tool calls. This means you essentially have to duplicate the tool call in your own prompt, saying what it tried to as well as what you want changed (e.g. don't do that change, don't run that command etc.).
This works differently to some other tools like Codex and makes it much more cumbersome to use Codex outside of letting it do anything and then have it do changes afterwards (which can be slower and use more tokens). Ideally you can see it's going down the wrong path and immediately stop it and say what to do instead, but still with the rest of the context of what it was actually in the middle of doing (as opposed to just adding a new prompt to your list of messages).
A quick way to test for this is to ask Codex to create a file with a random string as contents and then interrupt it trying to edit the file and ask it to repeat the string it tried to write. If the string was only mentioned in the parameters of the tool call, it won't know the string it came up with.
Additional information
No response
What feature would you like to see?
When interrupting tool calls, the context of the tool call is not included when "telling Codex what to do differently". For example, if you want to ask why it needs to run a command or to not run the command it just tried to run, it doesn't know what you're referring to, and if it submits a patch that you want to make changes to, it doesn't know what you're trying to change, making it much harder to adjust tool calls. This means you essentially have to duplicate the tool call in your own prompt, saying what it tried to as well as what you want changed (e.g. don't do that change, don't run that command etc.).
This works differently to some other tools like Codex and makes it much more cumbersome to use Codex outside of letting it do anything and then have it do changes afterwards (which can be slower and use more tokens). Ideally you can see it's going down the wrong path and immediately stop it and say what to do instead, but still with the rest of the context of what it was actually in the middle of doing (as opposed to just adding a new prompt to your list of messages).
A quick way to test for this is to ask Codex to create a file with a random string as contents and then interrupt it trying to edit the file and ask it to repeat the string it tried to write. If the string was only mentioned in the parameters of the tool call, it won't know the string it came up with.
Additional information
No response