Still persisting issues with running cmd/powershell commands with codex-cli on windows
What version of Codex is running?
codex-cli 0.23.0
Which model were you using?
gpt-5
What platform is your computer?
Microsoft Windows NT 10.0.26100.0 x64
What steps can reproduce the bug?
When I run codex cli on windows I can't get it to iterate through files. I followed this issue: https://github.com/openai/codex/issues/2068 and was glad to see that it should be resolved. But when I try it myself i still get issues with it not being allowed to run the commands in the sandbox environment.
I don't know if 'm feature-creeping this issue report, but the commands seems to work when I run codex --full-auto (event though I need to approve them still). I usually run codex --ask-for-approval never --sandbox workspace-write (which works like a charm when i do a VM with ubuntu, just not on windows)
Just let me know if I can give you any more context.
To test I just run a simple prompt in my repo: "How many solutions are there?"
What is the expected behavior?
To have it being able to run the shell commands so it can find files etc - without having to run --full-auto (which seems to require me to approve all commands anyway :( )
What do you see instead?
Output from codex --full-auto:
>_ You are using OpenAI Codex in D:\repo\tickster
To get started, describe a task or try one of these commands:
/init - create an AGENTS.md file with instructions for Codex
/status - show current session configuration and token usage
/diff - show git diff (including untracked files)
user
How many solutions are there?
codex
I’ll scan the repo for Visual Studio .sln files to count them.
✗ Failed (exit 1)
└ 🔎 *.sln
<3>WSL (8) ERROR: CreateProcessParseCommon:754: getpwuid(0) failed 2
<3>WSL (8) ERROR: CreateProcessEntryCommon:331: getpwuid(0) failed 2
<3>WSL (8) ERROR: CreateProcessEntryCommon:502: execvpe /bin/bash failed 2
<3>WSL (8) ERROR: CreateProcessEntryCommon:505: Create process not expected to return
codex
The previous attempt failed due to WSL. I’ll use Windows cmd to search for .sln files.
? Codex wants to run cmd /c 'dir /s /b *.sln 2>nul'
▌Allow command?
▌ Yes Always No
▌ Approve and run the commandAnd then when it runs the command
✓ Completed
└ ⌨️ cmd /c 'dir /s /b *.sln 2>nul'
codex
Now I’ll count them directly to avoid long listings.
✔ You approved codex to run cmd /c "for /f %A in ('dir /s /b *.sln "'^| find /c /v ""'"') do @echo %A" every time this session
✗ Failed (exit 1)
└ ⌨️ cmd /c "for /f %A in ('dir /s /b *.sln "'^| find /c /v ""'"') do @echo %A"
Access denied - \
codex
The previous count hit an access error. I’ll use PowerShell to count .sln files safely.
✔ You approved codex to run powershell -NoProfile -Command '(Get-ChildItem -LiteralPath . -Recurse -Filter *.sln -ErrorAction SilentlyContinue | Measure-Object).Count' every time this session
✓ Completed
└ ⌨️ powershell -NoProfile -Command '(Get-ChildItem -LiteralPath . -Recurse -Filter *.sln -ErrorAction SilentlyContinue | Measure-Object).Count'
codex
There are 265 Visual Studio solution files (.sln) in this repo.Output when I run codex --ask-for-approval never --sandbox workspace-write
user
How many solutions are there?
codex
I’ll scan the repo for .sln files to count solutions.
codex
I couldn’t scan the repo due to command restrictions. Please run one of these locally in D:\repo\xxx and share the result:
- PowerShell (count): (Get-ChildItem -Recurse -Filter *.sln).Count
- PowerShell (list): Get-ChildItem -Recurse -Filter *.sln | Select-Object -Expand FullName
- Git Bash: git ls-files "*.sln" | wc -lAdditional information
Log output from --full-auto:
^[[2m2025-08-21T06:55:12.775750Z^[[0m ^[[32m INFO^[[0m Shutting down Codex instance
^[[2m2025-08-21T06:55:12.775899Z^[[0m ^[[32m INFO^[[0m interrupt received: abort current task, if any
^[[2m2025-08-21T06:59:53.489435Z^[[0m ^[[32m INFO^[[0m FunctionCall: {"command":["bash","-lc","rg --files -g *.sln || true"]}
^[[2m2025-08-21T07:00:01.900104Z^[[0m ^[[32m INFO^[[0m FunctionCall: {"command":["cmd","/c","dir /s /b *.sln 2>nul"]}
^[[2m2025-08-21T07:00:39.708750Z^[[0m ^[[32m INFO^[[0m FunctionCall: {"command":["cmd","/c","for /f %A in ('dir /s /b *.sln ^| find /c /v \"\"') do @echo %A"]}
^[[2m2025-08-21T07:00:52.448114Z^[[0m ^[[32m INFO^[[0m FunctionCall: {"command":["powershell","-NoProfile","-Command","(Get-ChildItem -LiteralPath . -Recurse -Filter *.sln -ErrorAction SilentlyContinue | Measure-Object).Count"]}
Log output from --ask-for-approval never --sandbox workspace-write:
^[[2m2025-08-21T07:01:26.017449Z^[[0m ^[[32m INFO^[[0m Shutting down Codex instance
^[[2m2025-08-21T07:01:26.017581Z^[[0m ^[[32m INFO^[[0m interrupt received: abort current task, if any
^[[2m2025-08-21T07:01:51.221007Z^[[0m ^[[32m INFO^[[0m FunctionCall: {"command":["bash","-lc","rg --files -g \"*.sln\" -S || git ls-files \"*.sln\" || ls -1 **/*.sln 2>nul"]}
18 Comments
This is 100% happening to me as well.
One thing that helps me is the very first thing I say to it is "You're running on Windows. You can execute PowerShell commands"
Me too.
But started working with WSL instead. Works fine
same here
VS Code extension is always prompting to approve any PoweShell commandlets no matter what configuration! So annoying!
Same problem for me
Can someone give updates on this?
Using WSL seems to be the best solution atm
I mean I thought it was failing to read the file, but then I noticed it was reading the wrong file instead. So make sure it's reading the correct file. But I agree that codex's PowerShell file reading capabilities are quite bad in general though and it seems to take a lot of tries to read a file properly.
I've tried Codex on Windows. It ran a lot of PowerShell commands that failed consistently, and it tried to solve this issue and iterated for like 15 minutes without even starting to solve my prompt. After that, it started to run some Python script to test PowerShell. What's going on? Is it expected behavior that the tool starts solving PowerShell and Python issues instead of completing my prompt? After half an hour, I just stopped it.
As a quick fix to not have the agent try random Powershell non-sense -
And it seems to work fairily good, there's some stuff missing, but basic file reading and writing capabilities are there.
Even if Codex uses bash instead of powershell, it still tries to use python and face python script errors and solves python problems instead of thinking on problem from prompt.
The best fix for this is to use Codex CLI and run it inside WSL. It's fairly easy and the setup is worth it.
Using WSL is garbage compared to just running it in PowerShell/ Terminal directly in Windows. Claude Code used to require WSL, but it doesn't anymore. Guess which one I use? Answer = Claude Code.
How is it garbage?
Bash is objectively better for small file operations and reads - it's fast and agents heavily rely on it because it's extremely well documented.
Claude Code is filled with FS tools and abstractions, that's why it works out of the box better, but it consumes way more tokens.
It comes between installing WSL which takes 5 minutes at most, and it works with native performance, or using a tool bloated agent who consumes tokens like air.
For the past two weeks, we've been testing and refining a new Windows-native sandbox implementation for the Codex CLI and IDE extension. Today, we released new versions of the CLI (0.59.0) and extension (0.4.44, or pre-release 0.5.44) that 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.
Today we also announced a 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. Give it a try, and let us know what you think.
Out of the box, after a few demo tasks on a large codebase, there's almost no noticeable difference in output from using it inside WSL (gpt-5.1-max extra thinking)
The only noticeable difference is the verbosity of what it's doing-
WSL:
Windbox
This is very good progress for Windows users!
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.