Include tool calls and reasoning when "No, and tell Codex what to do differently"

Resolved 💬 5 comments Opened Oct 16, 2025 by nihaals Closed Mar 20, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

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_

View original on GitHub ↗

5 Comments

ts-klassen · 10 months ago

Yes, I think this is a problem too.

How to reproduce

Using version 0.46.0 codex-x86_64-unknown-linux-musl.

Open codex in readonly with this prompt:

Please create random.txt with a random integer as content. Only use apply_patch and no other commands. Do NOT use commands to get a random number. Keep that random number very secret. Do not write it anyware else. Do not tell me the number. Do not write the number in tool call summary. (You may include it in the diff of apply_patch)

Then, codex suggested:

  Would you like to make the following edits?
 
  ~/random.txt (+1 -0)
 
    1 +937520184
 
› 1. Yes, proceed
  2. No, and tell Codex what to do differently esc

I selected 2 with the following prompt:

I want you to add one (+1) to that number instead

The second attempt is:

  Would you like to make the following edits?
 
  ~/random.txt (+1 -0)
 
    1 +739402154
 
› 1. Yes, proceed
  2. No, and tell Codex what to do differently esc

---

So, clearly, I can't tell what to do differently from the original attempt.

nihaals · 10 months ago
Please create random.txt with a random integer as content. Only use apply_patch and no other commands. Do NOT use commands to get a random number. Keep that random number very secret. Do not write it anyware else. Do not tell me the number. Do not write the number in tool call summary. (You may include it in the diff of apply_patch)

Using a similar prompt I confirmed that reasoning is also reset which explains why asking for a small change to something it attempted is still slow and it feels like it's starting the step again. For example, after knowing I need to provide what it tried to do in my correct, I got an explanation and confirmed what it wanted was fine, but then it still took a long time to arrive at the same tool call it reached before. I would expect going on a small tangent to be quick and I can resume what was in progress before but instead it feels like everything between my last prompt and my correction is lost.

geokal · 9 months ago

same here!! using VS code codex extension (0.4.46) in VS Code : Version: 1.106.2 (Universal)
Commit: 1e3c50d64110be466c0b4a45222e81d2c9352888
Date: 2025-11-19T16:56:50.023Z (18 hrs ago)
Electron: 37.7.0
ElectronBuildId: 12781156
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Darwin arm64 22.6.0

ts-klassen · 7 months ago

I think this problem is resolved in the latest release.
codex-cli 0.80.0 has no problems.

etraut-openai contributor · 5 months ago

This feature request hasn't received any upvotes or new posts in a long time, so I'm going to close it.