Codex using Python to make edits to files

[GeorgeWingg]

I have found that instead of using the File Edit tool which it has, it runs python to make the changes.

This is quite interesting behavior, has anyone else seen this happen in their Codex Usage?

Could this because of a problem with the file edit tool, so codex prefers to script the changes with python?

[GeorgeWingg]

From a User Experience angle it's not great, as you can't see the immediate diff made like with the file edit tool.

I've also found the changes that codex makes using this approach is more sloppy than if it actually edits the file, and I think its indexing too hard on the feedback of print('patched move & removed guide') which it creates for itself as signal the change was successful.

[obmelvin]

I'm having this happen to me a lot. For some reason > 80% edits are achieved via Python and Bash rather than the built in tool. Occasionally telling it to please edit via built in file edit tools and not via Python or via direct Bash calls works.

But in this last case, I specifically asked at the start and it went ahead and changed ~250 lines over 7 files all outside of the expected workflow

Sure, I can review the work looking at the diff, but it's just odd that it consistency picks ways to edit files that don't align with the intended UX.

[bjspi]

I have the same problem in Windows, and it's pretty annoying because these changes require quite a few iterations before they actually work using a custom Python script.

Sometimes it also tries to do it using some strange PowerShell commands that don't work properly with line breaks or multi-line changes.

Why not simply use the built in EDIT Tool, or similarly the diff+merge tool like it is done when using from VSCode?

[Anyrainel]

I noticed that on Windows, codex would first attempt to use some commands such as cat, then that hit some syntax error, and after that codex starts to use pwsh or python for everything, including file edits. It wastes a lot of tokens trying to figure out the right syntax and char escaping. And even if it succeeds, the file could have incorrect indents.

My workaround is to add some of those Unix CLIs to the PATH, and remove the default PowerShell Alias. So when I'm lucky, codex would work as if it has a Linux/macOS environment.

• Install MSYS2 or other software that provide Unix CLIs. (The ones from Git or GitHub Desktop is not complete enough.)
• Add the following to the PowerShell profile you will run codex with: (notepad $PROFILE if you want to edit the default profile, remember to use your own install path)

# Add MSYS2 Unix bins to PATH
$msysPath = "C:\msys64\usr\bin"
if ($env:Path.Split(';') -notcontains $msysPath) {
    $env:Path += ";$msysPath"
}

# Remove PowerShell aliases that shadow common Unix commands
$unixCommands = @(
    'cat', 'cp', 'diff', 'echo', 'ls', 'mv', 'pwd', 'rm', 'rmdir', 'sort',
    'clear', 'dir', 'fc', 'ps', 'sort', 'start', 'tee', 'where'
)

foreach ($name in $unixCommands) {
    $alias = Get-Alias -Name $name -ErrorAction SilentlyContinue
    if ($alias) {
        $target = $alias.Definition
        if (Get-Command $target -CommandType Cmdlet -ErrorAction SilentlyContinue) {
            Remove-Item "Alias:$name" -ErrorAction SilentlyContinue
        }
    }
}

• Optionally write something in AGENTS.md to tell codex that this is a pwsh environment with many Unix commands, and you prefer it to use the Unix commands.

With this, codex will display its actions with much more readable UI and have better success rate.

[GeorgeWingg]

I personally think its a product of the RL environment that OpenAI is using to train gpt5, where it probably doesn't have access to the typical file edit tool, so it tries to use alternatives like trying to edit files with ephemeral scripts it makes.

So from my perspective its either the File Edit tool in codex is either not "ergonomic" enough for the model to use, or its a problem with the model itself that cant be fixed with codex.

[mickeyl]

Same here on macOS. Doesn't that make the already slow Codex even slower?

[bjspi]

It actually does make it very slow. Needs a lot of iterations for easy edits, because they don't always work first try....

[onkarrai06]

Do I have to give it permissions to use file edit? Because I'm having the same problem.

[hwo411]

Also was surprised by that. Some people told me using and MCP server for file editing could help, but didn't have a chance to try.

[jeanlucthumm]

Is there an open issue for this?

[mickeyl]

cough If so, a very strange one that's an incredible waste of resources, then.

[GeorgeWingg]

I'm not sure what resource would be wasted here.

The main thing that matters is its ability to make successful file edits, if it is able to do that by running ephemeral python scripts then I don't see much of an issue.

[bjspi]

I'm not sure what resource would be wasted here.

The main thing that matters is its ability to make successful file edits, if it is able to do that by running ephemeral python scripts then I don't see much of an issue.

For me it keeps iterating until it finds a solution to finally make the smallest type of edits successfully. So it definitely is an issue for me

[johnyfernandes]

I'm not sure what resource would be wasted here.
The main thing that matters is its ability to make successful file edits, if it is able to do that by running ephemeral python scripts then I don't see much of an issue.

For me it keeps iterating until it finds a solution to finally make the smallest type of edits successfully. So it definitely is an issue for me

Yes, 100%. It uses Python 90% of the times to edit files, and most times, it isn't able to make the change using Python for the 1st time, so, it keeps running Python scripts, sometimes 3/4x for just 1 change, so, this spends way more tokens than supposed I presume.

[olliepro]

It also doesn't show those changes in the "Files Edited" section, but they've definitely been edited. It also makes reverting changes impossible...

[JakkuSakura]

Sometimes it's using git diff tool to edit files. Weird but works fine most of the time

[walesdata]

Changing the model from gpt-5-codex / medium to gpt-5 / medium fixed this for me.

[cau1k]

I personally think this is really cool. There’s something beautiful about AI made with code using code to write more code. Full circle moment if you ask me.

I was hesitant at first, telling it to “stop using python to edit files” in my AGENTS.md, but, low and behold, Codex started using Ruby to edit files. Honestly, just let it do its thing. It’s an incredible model.

[GeorgeWingg]

Haha this is awesome, I'm gonna bring this up at DevDay.

I second this view

[EnvyGithub]

#如果您尝试在不支持其本机沙盒机制的环境（例如较旧的 Linux 内核或 Windows）中使用 Codex，则可能还需要使用此选项。
sandbox_mode = "danger-full-access"

在配置文件中添加这个,一切都好使了.

[EnvyGithub]

仅针对windows 系统.

[stronk-dev]

Yeah this is really frustrating me as well. It will go through Python, Node and others before making 'normal' file edits, sometimes even (trying to) use git commands to revert entire files...

Maybe it's a way to make the context window fill less quickly? It seems to be reading less file contents (but that might just be me). Anyway it's VERY annoying as it basically strips immediate verifyability. 'What happened here?', 'When did this function get edited' are questions I find myself asking frequently lately, due to the opaque mass editing being done.

[affaan-m]

the fact that this still isn't fixed yet - maybe AI has led me to lose my patience, but simple stuff takes forever for it to do as it starts spamming python to read using a for loop

python - <<'PY'
import pathlib
for path in pathlib.Path('website/src').rglob('*.tsx'):
text = path.read_text()
if 'isSearching=' in text:
print(path)

this has been running forever it may be stuck in an inf loop

[bjspi]

Yes, exactly the same for me. Super annoying. Every little micro-change really takes forever.

[rvdavid-rbi]

Did this ever get addressed guys?

[bjspi]

Yes, it should be like that. At least I installed the latest update, and the file edits now go so smoothly and effortlessly, without me having changed anything else.

[shanepadgett]

I've had it use everything from cat to node to do file edits recently Everything except the built in tool. Crazy. Opencode does not have this problem when using the codex model. Baked in tool prompt issue?

[etraut-openai]

@stronk-dev, getting to a correct solution is the primary goal, but token efficiency and time to completion are important secondary goals. What other metrics do you think should be optimized for?

[stronk-dev]

yeah good question, what do you optimize for...

seeing as my previous comment was so blunt and short, i've been giving this a lot of thought. So far I came to the conclusion that it really depends on what persona you're targeting:

• the 'vibe coder', or someone who wants their agent to be a colleague. It doesn't matter how they get to the solution, as long as it's as quick & with as little input as possible. You review after the fact, or just run it and report back any issues that pop up.
• SWE assistants, where the agent allows them to iterate much quicker than writing code by hand. The engineer wants to stay in control and steer the agent continuously.

Usually I use Codex/Claude for the latter. From my experience, humans take a long time to 'work in', but after a couple of years they've gotten a good understanding of the codebase and what's been tried. They don't lose context. The agent has limited capabilities for truly 'understanding' a project. They start from scratch (besides any embeddings being stored and what they can infer from training).

Because of this, the way I can save even more tokens is by ensuring my agents write the right implementation in the first place. Part of this is proper planning, but even then you sometimes have to halt an agent and give it some more context.
To those ends, transparency is important. And yeah for any large scale mechanical changes, sure use a script or some sed command to replace blocks...

But what made me follow this issue, is that (at least back then) i found my agent trying to use destructive (git) commands or defaulting to using node/python/bash for edits that aren't complicated/expensive to do via 'normal tool calls'. I'd lose immediate auditability for a marginal savings in tokens.

So tl;dr: the un-tangible metric of being 'auditable' or 'collaborative'. You're losing direct feedback when edits are abstracted behind some scripts.

[etraut-openai]

Thanks, those are good insights.

I previously worked in the way you're describing — where I interacted with the agent and steered it as it worked. I largely stopped doing this a few months ago, and I think that's true for most of the members of the Codex team. The models are now good enough with planning and coding that it's possible for them to write high-quality solutions without supervision most of the time. That allows me to parallelize my work and increase productivity. Codex is often working on two to five parallel tasks for me. That wouldn't work if I needed to watch and steer each instance.

Even in cases where I want to check in on an agent's progress, I tend to look at the live diffs rather than the conversation stream and individual tool calls. Watching the live diff is easy in the Codex app, which is now where I do the majority of my work.

[stronk-dev]

I've been using Codex a lot for thorough code reviews (cloud, not the CLI), triggered by an agent using the CLI to spawn audit tasks, but honestly the app has been abysmal for me with it's Github integration, to the point where I am currently using a OpenClaw based agent to pull any Codex (cloud) stuff over the finish line...

[etraut-openai]

What about the app's GitHub integration has been problematic for you? Feel free to file bug reports if you're seeing specific problems.

[GeorgeWingg]

Thanks all, and thanks @etraut-openai for confirming the behavior

In my experience this is not having a negative impact on my user experience anymore and haven't observed this problem, so I am closing the discussion

[snailwei]

The latest codex v0.141.0 always instruct the LLM to use Python script to edit the Rust files, I am curious of this design. The user did not see what the code diff it changed.

• Ran cd /home/swei/ai/shark && python3 << 'PYEOF'
  │ with open("src/report.rs", "r") as f:
  │     content = f.read()
  │ … +31 lines
  └ OK: JSON write added to generate()
...
• Ran cd /home/swei/ai/shark && python3 << 'PYEOF'
  │ with open("src/report.rs", "r") as f:
  │     content = f.read()
  │ … +49 lines
  └ OK: fixed block

[ash-hashtag]

guys we've achieved AGI, but can't fix codex, to edit files like normal intelligent being

[soul-sol]

The user did not see what the code diff it changed.

That's the part with real consequences, separate from the aesthetics of the choice.

When edits go through a scripted path rather than the edit tool, two things stop being
observable: what was changed, and whether the change the agent intended is the change
that landed. A Python edit that half-applied and then raised still leaves a modified
file, and from outside it looks the same as one that completed.

Whatever the tool ends up doing, the property worth insisting on is that the run leaves
behind something only the real outcome could produce:

• the diff, or at minimum the file list, attributable to that run
• a recorded terminal status, written when the run ends rather than inferred later
• and the rule that a clean exit is a candidate, not a verdict — a script can exit 0
  after writing nothing, and an agent can exit 0 having only asked a question

Concretely as a user-side check right now: after a Codex run, git status --short
against a pre-dispatch commit tells you what actually landed, which is the thing the
scripted path is currently hiding. It doesn't fix the behaviour, but it means an
unnoticed partial edit doesn't survive into the next task.

Related: the review side of the same problem is that "the agent said it edited the file"
and "the file is correct" are different claims —
https://github.com/soul-sol/ai-code-review-prompts (MIT) is the prompt set I use to make
a reviewer produce a failure scenario per finding instead of "looks good".