Read/Write/Rg/etc should be internal tools, not a powershell operation in Windows.

I can not agree u more! suffer from everyday that codex using powershell to read code which degrade the performance. it is like a Ruble riding a pig. my last advice is : just adopt roo code or copy their work, haha.

Same problem here. It wastes lots of tokens to do simple file edits, sometimes even causing users to exceed weekly usage limits.

Sometimes it uses pwsh.exe, and sometimes it even tries to run Python scripts.

Regular file edit tools work perfectly when it uses them.

I have rg installed and for now added this to AGENTS.md:

## Tooling & Shell Usage
- Prefer the bundled bash helpers (`bash -lc`) when invoking shell commands; always set the `workdir` parameter.
- Use `rg`/`rg --files` for searches; fall back only if unavailable.
- Avoid PowerShell-specific commands.

Works fine for me.

It's frustrating that it stll uses python scripts to edit files and makes mistakes as well

I now understand why Codex can take seven hours to solve a problem.
My Codex spends 20 minutes editing a single file via PowerShell, simply because it doesn't understand the encoding. Then it moves on to another file and the cycle repeats. It's just an endless loop of attempts to edit the file.

I have rg installed and for now added this to AGENTS.md: ## Tooling & Shell Usage - Prefer the bundled bash helpers (bash -lc) when invoking shell commands; always set the workdir parameter. - Use rg/rg --files for searches; fall back only if unavailable. - Avoid PowerShell-specific commands. Works fine for me.

Thanks for this, I've added a few other tools and the speed has dramatically improved.

Tooling & Shell Usage

• Prefer the bundled bash helpers (bash -lc) when invoking shell commands; always set the workdir parameter.
• Use rg/rg --files for searches; fall back only if unavailable.
• use sed for in-place file edits.
• Use git & gh for version control operations.
• Use jq for JSON processing.
• Avoid PowerShell-specific commands. CRITICAL DO NOT USE PYTHON, PERL or OTHER SCRIPTS TO MANIPULATE FILES.

make sure you install the following using winget
winget install BurntSushi.ripgrep.GNU
winget install mbuilov.sed
winget install jqlang.jq

Yes - PLEASE fix this. Gemini CLI can read a 10,000 line codebase in about 8 seconds with Read_many_files and i am sat here for 10 minutes approving 40 different powershell commands before codex even has the project in context. These functions need to be internal tools that do not need approval (any read-only tool should not need approval)

The model is fantastic, GPT-5-high is incredibly capable and smart, but man using Codex is just a chore. I do not expect the most time-consuming task of editing some files to be simply approving Codex reading them in the first place

I though this was some sort of bug cause first release and I switched back to gpt-5
So gpt-5-codex is really supposed to use terminal commands to read and edit files? Doesn't make much sense cause you can't even undo. Is this a bug? Surely is not optimal and I saw it ending in loops for easy tasks.
Edit: I'm using with VSCode extension on MacOS, so gpt-5-codex uses commands like "cat" to edit files instead of editing in the chat like gpt-5

No, you run the same request in Linux and it is a blast. Not as capable as GPT-5 but it is fine for most usages. The problem is that GPT-5 can do more with less requests using Powershell so it is faster, but it is waaaaay slower than on Linux.

yeah the Windows experience is just outright terrible right now. Windows support exists in the sense that that codex runs on WIndows but since the native read and write tools don't exist on windows it is painfully slow and outright broken

Exactly in most of the time, my comments are from another language, not english. Under this case, the power shell cannot really understand things.

I now understand why Codex can take seven hours to solve a problem. My Codex spends 20 minutes editing a single file via PowerShell, simply because it doesn't understand the encoding. Then it moves on to another file and the cycle repeats. It's just an endless loop of attempts to edit the file.

That's also a problem for me, i cannot undo anything when the chat is finished.I think this is a bug. Maybe gp five is too smart, and they make less issues. That's why people are not really using the undo option.

I though this was some sort of bug cause first release and I switched back to gpt-5 So gpt-5-codex is really supposed to use terminal commands to read and edit files? Doesn't make much sense cause you can't even undo. Is this a bug? Surely is not optimal and I saw it ending in loops for easy tasks. Edit: I'm using with VSCode extension on MacOS, so gpt-5-codex uses commands like "cat" to edit files instead of editing in the chat like gpt-5

My rough guess is that the system prompt change has something to do with it as well. They made the system prompt a lot shorter over the last week. I need to dig in and compare but just pasting the older longer prompt into your agents.md does improve things somewhat. It doesn't totally address the issues on windows but it avoids codex writing PS, Python or perl scripts to read and edit files on windows.

Codex can be better than Sonnet or Opus but the tooling to use it on the CLI is absolutely horrible

Codex can be better than Sonnet or Opus but the tooling to use it on the CLI is absolutely horrible

Full ACK. I am currently faced with endless prompts like the following. Very tiring...

• Proposed Command
  └ nl -ba packages/generator/lib/src/generator.dart | sed -n '660,760p'

✔ You approved codex to run nl -ba packages/generator/lib/src/generator.dart | sed ... this time

• Explored
  └ Read generator.dart

• Proposed Command
  └ nl -ba packages/generator/lib/src/generator.dart | sed -n '900,1030p'

✔ You approved codex to run nl -ba packages/generator/lib/src/generator.dart | sed ... this time

• Explored
  └ Read generator.dart

• Proposed Command
  └ nl -ba packages/generator/lib/src/generator.dart | sed -n '1030,1100p'

✔ You approved codex to run nl -ba packages/generator/lib/src/generator.dart | sed ... this time

• Explored
  └ Read generator.dart

• Proposed Command
  └ nl -ba packages/generator/lib/src/generator.dart | sed -n '1100,1180p'

✔ You approved codex to run nl -ba packages/generator/lib/src/generator.dart | sed ... this time

• Proposed Command
  └ nl -ba packages/generator/lib/src/generator.dart | sed -n '60,120p'

▌Allow command?
▌ Yes   Always   No, provide feedback
▌ Approve and run the command

For starters, I would love if I could just say, stop asking.... because I have accepted 127 prompts in the last hours.

I have rg installed and for now added this to AGENTS.md: ## Tooling & Shell Usage - Prefer the bundled bash helpers (bash -lc) when invoking shell commands; always set the workdir parameter. - Use rg/rg --files for searches; fall back only if unavailable. - Avoid PowerShell-specific commands. Works fine for me.

## Tooling & Shell Usage
- Prefer the bundled bash helpers (`bash -lc`) when invoking shell commands; always set the `workdir` parameter.
- Use `rg`/`rg --files` for searches; fall back only if unavailable.
- Use the `apply_patch` to edit files
- Avoid PowerShell-specific commands.

I added a prompt telling codex to use built-in apply_patch for editing files. From what I've seen, only the codex models don’t use apply_patch on my Windows. The file gpt_5_codex_prompt.md doesn’t mention apply_patch, and model_family.rs also does not apply any extra instructions for codex models. This could be the problem.

The current implementation on Windows is really quite bad. At the very, very least, users should get a warning if they launch Codex in a Windows environment (update: see below). I was initially very disappointed with Codex (coming from Claude Code) until I did some research and realized that it runs much better under Linux (or WSL). The default experience is so poor that I was honestly ready to write it off as useless and uninstall it before even trying to work around it. While the docs technically state that native Windows is not supported (here), this info is not nearly prominent enough and most users will definitely miss it, which should be unacceptable for the most widely used OS.

I would really like to see proper Windows support, for developers who can’t or don’t want to use WSL. Claude Code avoids this issue by supporting Git Bash, which is based on MSYS2 and includes the most important Linux command-line utilities by default. This is still a workaround, but definitely better than nothing. When running Codex through Git Bash, it works too (kind of), but not without some tinkering. I had to explicitly prompt for it in AGENTS.md, and MCPs don’t work without awkward workarounds. And even in Git Bash, Codex behaves strangely at times, preferring commands over native tools or trying to use commands that aren’t installed, such as ripgrep (which I then had to install separately through scoop). By comparison, the out-of-the-box experience for Claude Code on windows is miles better, and this is definitely an area where Codex needs to improve quickly.

Update: They have since added a warning when you launch codex on windows, suggesting that you use it through wsl2. I'm glad we have this at least, but I'd still really like to see proper support for non-wsl windows users too.

I got increasingly frustrated with Codex CLI experience on windows that I created an MCP to give it the tools that most other CLIs have. Please use it at your own risk but in my testing I've found Codex to be much faster with these tools on Windows rather than trying random PS and Python scripts for basic operations.

[mcp_servers.code-tools]
command = "{path to npm.cmd}"
args = [ "-y", "code-tools-mcp"]
env = { APPDATA = "C:\\Users\\{username}\\AppData\\Roaming", LOCALAPPDATA = "C:\\Users\\{username}\\AppData\\Local", HOME = "C:\\Users\\{username}", SystemRoot = "C:\\Windows", ComSpec = "C:\\Windows\\System32\\cmd.exe" }
startup_timeout_ms = 20_000

https://github.com/BumpyClock/code-tools-mcp

The current implementation on Windows is really quite bad. At the very, very least, users should get a warning if they launch Codex in a Windows environment (update: see below). I was initially very disappointed with Codex (coming from Claude Code) until I did some research and realized that it runs much better under Linux (or WSL). The default experience is so poor that I was honestly ready to write it off as useless and uninstall it before even trying to work around it. While the docs technically state that native Windows is not supported (here), this info is not nearly prominent enough and most users will definitely miss it, which should be unacceptable for the most widely used OS. I would really like to see proper Windows support, for developers who can’t or don’t want to use WSL. Claude Code avoids this issue by supporting Git Bash, which is based on MSYS2 and includes the most important Linux command-line utilities by default. This is still a workaround, but definitely better than nothing. When running Codex through Git Bash, it works too (kind of), but not without some tinkering. I had to explicitly prompt for it in AGENTS.md, and MCPs don’t work without awkward workarounds. And even in Git Bash, Codex behaves strangely at times, preferring commands over native tools or trying to use commands that aren’t installed, such as ripgrep (which I then had to install separately through scoop). By comparison, the out-of-the-box experience for Claude Code on windows is miles better, and this is definitely an area where Codex needs to improve quickly. Update: They have since added a warning when you launch codex on windows, suggesting that you use it through wsl2. I'm glad we have this at least, but I'd still really like to see proper support for non-wsl windows users too.

You're not kidding. This is what happens when it tries to update a single line in a file.

<img width="1367" height="1219" alt="Image" src="https://github.com/user-attachments/assets/6d839087-a3a3-41b6-9382-f3be96697820" />

This issue should be pinned, I had a hard time finding it and I almost wrote off Codex as an inefficient tool. Now I know that it is only the Windows experience that is bad for now, so I may try again later.

For the past two weeks, we've been testing and refining a new Windows-native sandbox implementation for the Codex CLI and IDE extension. The latest versions of the CLI and extension incorporate the latest bug fixes for this feature. The new Windows sandbox is still considered "experimental", but we think it's ready for broader use, and we welcome you to give it a try. For more details, refer to this documentation. With the new sandbox enabled, you should see far fewer approval requests. We also released new model: GPT-5.1-Codex-Max. In addition to being more token efficient and able to solve longer-horizon problems, it also has improved support for Windows code generation and tool usage.

With the new Windows sandbox now ready for broad use, I'm going to mark this issue as closed. There are many additional improvements that we need to make for codex on Windows. Many of these are already reported as open bugs, and we are fixing them in priority order. If you see further issues with Windows tool permissions or sandboxing that are not already captured in an open bug report, please open new issues with repro steps and additional details. That will help us focus our attention on the most important issues.

For the past two weeks, we've been testing and refining a new Windows-native sandbox implementation for the Codex CLI and IDE extension. The latest versions of the CLI and extension incorporate the latest bug fixes for this feature. The new Windows sandbox is still considered "experimental", but we think it's ready for broader use, and we welcome you to give it a try. For more details, refer to this documentation. With the new sandbox enabled, you should see far fewer approval requests. We also released new model: GPT-5.1-Codex-Max. In addition to being more token efficient and able to solve longer-horizon problems, it also has improved support for Windows code generation and tool usage. With the new Windows sandbox now ready for broad use, I'm going to mark this issue as closed. There are many additional improvements that we need to make for codex on Windows. Many of these are already reported as open bugs, and we are fixing them in priority order. If you see further issues with Windows tool permissions or sandboxing that are not already captured in an open bug report, please open new issues with repro steps and additional details. That will help us focus our attention on the most important issues.

I already use it for 2 days and use new version did a big project(for me), i can already tell you that the new Windows-native sandbox implementation works better, I can feel it, now the reading code speed is much faster and the response is more accurate. I am keep testing it with my real project and of course will report any other issues.
just want to congrat u in the first moment, good job!

@etraut-openai

For the past two weeks, we've been testing and refining a new Windows-native sandbox implementation for the Codex CLI and IDE extension. The latest versions of the CLI and extension incorporate the latest bug fixes for this feature. The new Windows sandbox is still considered "experimental", but we think it's ready for broader use, and we welcome you to give it a try. For more details, refer to this documentation. With the new sandbox enabled, you should see far fewer approval requests. We also released new model: GPT-5.1-Codex-Max. In addition to being more token efficient and able to solve longer-horizon problems, it also has improved support for Windows code generation and tool usage. With the new Windows sandbox now ready for broad use, I'm going to mark this issue as closed. There are many additional improvements that we need to make for codex on Windows. Many of these are already reported as open bugs, and we are fixing them in priority order. If you see further issues with Windows tool permissions or sandboxing that are not already captured in an open bug report, please open new issues with repro steps and additional details. That will help us focus our attention on the most important issues.

This is still a problem honestly. It should not be sending approval requests for every single operation. It's clearly not working as intended when it asks super niche requests like:

  Would you like to run the following command?

  $ Select-String -Path js\app.js -Pattern "searchUrl" -Context 1,1

  1. Yes, proceed (y)
› 2. Yes, and don't ask again for commands that start with `Select-String -Path js\app.js -Pattern "searchUrl"
     -Context 1,1` (p)
  3. No, and tell Codex what to do differently (esc)

That "Yes and" option is too specific. I read the thread when this choice was defended by the example of saying that some commands that start with shorter inputs may mean completely different things. This is fine, in those cases the user need to take responsibility and reject vague commands.

I suggest adding a fourth option that shows the root command and lets you always approve that if you desire.
As mentioned in that thread though, it would be ideal if the agent itself determined what level of command should be "always approved", and suggest this to the user.

Related topic:
https://github.com/openai/codex/pull/8451

And also, why must it ask for permission to edit EVERY SINGLE FILE in the directory I am working in? I understand for external directories, or the first time it tries to edit a file in the working directory. But do I really have to give permission to do it for every single code file it tries to edit? This defeats the point of an agent don't you think?