Unusable on Windows due to permission ask for every shell command

Even writing output to the conversation requires permission!

✔ You approved codex to run powershell -NoProfile -Command 'Write-Output "Searching boardSlice for game over handling and list
refreshes."; rg -n -S -e "game over|gameover|gameState|over|time-expired|resign|timeout|end" src/stores/slices/boardSlice.ts;
Write-Output "Open file head"; Get-Content -TotalCount 200 src/stores/slices/boardSlice.ts' this time

...and the PowerShell invocations more often than not fail because vertical pipes or parentheses are not quoted or backslash-escaped correctly. Then you need to approve them twice!

✔ You approved codex to run powershell -NoProfile -Command "rg -n -S -e \"loadAllGameLists\\(\" src; rg -n -S -e
\"loadFinishedGames\\(\" src; rg -n -S -e \"loadOngoingGames\\(\" src; rg -n -S -e \"loadChallengeList\\(\" src" this time
  ✗ ⌨️ powershell -NoProfile -Command "rg -n -S -e \"loadAllGameLists\\(\" src; rg -n -S -e \"loadFinishedGames\\(\" src; rg -n
-S -e \"loadOngoingGames\\(\" src; rg -n -S -e \"loadChallengeList\\(\" src"
    Missing closing ')' in expression.
        + CategoryInfo          : ParserError: (:) [], ParentContainsErrorRecordException
        + FullyQualifiedErrorId : MissingEndParenthesisInExpression

@vthorsteinsson If you dare, then /approval and choose Full Auto then you are only asked about applying pacth code (which is a bug as it happen even if you run dangerous sandbox mode)... Making it better for now

Same problem with codex-cli 0.27.0.

There's not sense on confirming every shell command. Makes codex an useless extension because you still need a manual interaction.

Even if I set approvals to never, it still asking permission for each command, even if I choose "Run always".

BTW, I think prefix powershell -NoProfile -Command is very weird too.

I just set to Agent (full access) in VS Code and it works, but I dont think is the best option.

Same thing happens to me in windows and WSL. Even adding the commands to “safecommands” in the confit file does nothing. I have to approve every single command. 🙁

Made a PR to fix https://github.com/openai/codex/pull/2988

TL;DR "--yolo"

I had the same issue even using "--full-auto" and set "/approval" to "Full Access"

When using "--yolo" I don't get asked to allow a command. I just get asked to apply changes to e.g. a script file. Might help a bit. In Gemini CLI with "--yolo" I don't even have to approve changes to files.

https://www.reddit.com/r/OpenAI/comments/1n4gk3w/how_to_adjust_permissions_in_codex_so_i_can_stop/

same issue

Yeah same issue, basically useless, I can do research and write code by myself faster than this.

Also having this issue and it is totally useless to me right now.

someone please merge the PR

Same with the VS Code extension, need to approve every single tool call

I need to approve every shell command in the VSCode extension on macOS, even when I select “run every time”

I also have the same issue.
For me the extension also doesn't seem to load my configuration.

I have this in project specific settings.json and in global vs code settings.json:

{
"chatgpt.config": {
"approval_policy": "never",
"shell": "C:Program FilesGit\bin\bash.exe"
}
}


I also thried to configure it in settings.toml globally but still no effect.

But still when checking in the session files it always says the following. Even after reloading and restarting VS Code:
<approval_policy>on-request</approval_policy><shell>pwsh.exe</shell>

Same issue here

Please fix this. I'm liking the quality of this over Claude right now, but having to babysit it completely defeats the purpose. I have to approve every grep, every sed, every docker run.

Re: some of the workarounds, like turning on full access, I'd much rather it just do what it says on the tin:

We’ve chosen a powerful default for Codex works on your computer: Auto. In this approval mode, Codex can read files, make edits, and run commands in the working directory automatically. However, Codex will need your approval to work outside the working directory or access network.

This is sensible, but it isn't what it does.

Same issue, its kinda really annoying and unusable with all the handholding it needs. Even with full access or ANY workaround I've seen online, it keeps asking for approval for everything.

the same, please fix this asap! this is MAJOR BUG!

Workaround for now while waiting for mergre, in WSL for Windows it works, not perfect but well

Can confirm that even on the highest approval level codex is still asking me for permission for every mundane thing it wants to do.

I should be more precise. After testing it more today, it seemed to run commands without asking, but asked every time it wanted to change a file. If anything, I actually don't mind if it changes any file, since it's all in version control. Ideally I'd be able to allowlist commands and perhaps subcommands while allowing all file changes to the current directory, but either way, it's far from what even the most permissive mode is doing right now.

Same here, asking for confirmation for every file creation or file modification.

Oh my god, this tool is so useless. Confirming consent literally every 3 seconds?

Can also confirm this, no matter what parameters you set.

This fixed for me on Windows 10:

• Use the Terminal app on Windows
• Type /approval and set it to "Full Access"

edit: I still have to approve file edits with this

This fixed for me on Windows 10: Use the Terminal app on Windows Type /approval and set it to "Full Access"

And you don't have to approve file edits with this?

/approval = Full Access fix everything but approval of add/edit/delete files

Run in WSL instead of cmd/Powershell make everything work

Looks like a PR in this issue was merged. If that fixes the issue, maybe it'll be deployed soon?

> This fixed for me on Windows 10: > > Use the Terminal app on Windows > Type /approval and set it to "Full Access" And you don't have to approve file edits with this?

Oh, sorry, I still have to approve edits. But before this combination I had to approve everything. Will edit my comment to make it clear

New version 0.30 is semi-out (not yet reached npm servers) and according to the changelog, it should fix this, but when downloaded and installed, I hit this error instead #3224 ... Don't know if it is just me or a new, more serious bug

Yes, I hit https://github.com/openai/codex/issues/3224 too - both on Windows and Linux. Went back to 0.29.0, which nominally works.

With /approval set to _Full Access_, on version 0.29.0, Codex indeed does not ask permission for every operation - but it goes too far in the other direction. For instance, it is right now doing a pip install into my Python environment without having asked for permission! Also, it does not fully understand PowerShell syntax and has to repeat commands after removing or adjusting non-existent flags. Other spurious errors are also common, such as:

 out-file : FileStream was asked to open a device that was not a file. For support for devices like 'com1:' or 'lpt1:', call CreateFile, then use the FileStream constructors that take an OS handle as an IntPtr.

The issue with 0.30 is now fixed. Default /approval still does not work as expected, but /approval = Full Access can now work 100% without user interaction.... Now we just need it for Codex IDE for me to be happy (no issue running Full Access)

I'm glad we have a somewhat decent workaround, but I'd really like the default approval mode to work, since I'm really wary of giving it full access to my hard drive.

@dellis23 : Then go the WSL route. That work as intended on Windows it seems

shell caommand Made a PR to fix #3253

Completely useless since release for me. Approving every single command defeats the purpose of the whole thing. VSCode extension 0.5.4.

I would recommend installing the microsoft WSL extension, pressing ctrl + shift + P, WSL: Open current folder in WSL and execute everything from there until this gets fixed, there it works without confirmation. Also command execution within linux is 10 times more powerful than from cmd or powershell and results are much better. But the extension should be able to work right away with the wsl system without needing to open the whole workspace in WSL, it would be nice to be able to choose the default terminal type used.

Meanwhile, Claude Code and Google Gemini CLI work perfectly on Windows, so it's hard to understand why Codex should be so far behind.

Confirmed that 0.30.0 in Auto mode still asks for every single attempt to read or list files even when telling it to always approve.

I have a workaround that makes things work perfectly.

Select Agent (full access) after that ask codex to write some powershell script, to create update and delete file in the workspace. When it has to manage files, it has not to ask confirm but using this script to manage all the work without asking anything.

Now it work like charm.

Pro tip. When you start again vs code, it loses all the memory. Ask to create a folder ai with all the instruction to do the work you agreed with it and a prompt to insert every time you start the day of work to read how it has to deal with files.

Tried 0.30.0 in auto mode in a linux shell on windows. Still asks for approval for every read operation.

Actually, it's worse than that. It seems to try to use rg to search files and is able to find the command sometimes; other times it seems to think rg isn't available and resorts to running powershell commands from within the linux shell!

Still an issue in the pre-release VS Code extension 0.5.8. This is easily the worst thing about using Codex in Windows right now - the results are great, but having to approve every single file read (as far as I can tell, "Approve this session" vs. "Approve once" is meaningless) is insane.

This has to be intentional for reasons they won't explain. And this long for a fix?

Ahh, this still be an issue here, in previous versions this can be solved using auto clicker, now, the CTA's positions are always changing based on what the agent changes, this is very hard to deal with, I hope this can be fixed soon @bolinfest so I can play my games while vibing

Modifying the config.toml file resolved the constant permission prompts for me on Windows. I added the following settings to ~/.codex/config.toml under the [core] section:
[core]
full-auto = true
bypass-approvals = true
bypass-sandbox = true
trusted-workspace = true

Saved the file as UTF-8, restarted my terminal, and tested with codex --version. No more prompts for basic operations like file reading or directory searches. Note: Be cautious with these settings, as they reduce security checks. Thanks for the discussion in this thread!

I've done some testing with different parameters

codex-cli 0.34.0
windows 11

• Asks for approval:

codex --full-auto "Please add a funny joke at the end of readme.md"
codex --ask-for-approval never --sandbox workspace-write "Please add a funny joke at the end of readme.md"

• Works:

codex --ask-for-approval never --sandbox danger-full-access "Please add a funny joke at the end of readme.md"
codex --dangerously-bypass-approvals-and-sandbox "Please add a funny joke at the end of readme.md"

Appears to be a problem with sandbox and workspace-write .

welp. this was a neat trial. back to claude code as this is absolutely worthless in current form

Same here, it uses pwsh.exe to read files, and ask permission to run pwsh.exe every time, no matter if I use --full-auto mode or choose "Always" when approving its requests. This is just totally unusable on Windows.

I'm trying the PRO subscription but really, how can this still be a problem, the Local VScode extension is unusable

<img width="503" height="1140" alt="Image" src="https://github.com/user-attachments/assets/011292f4-3e0c-4155-9ff4-b015d11ec8ab" />

Same here, it uses pwsh.exe to read files, and ask permission to run pwsh.exe every time, no matter if I use --full-auto mode or choose "Always" when approving its requests. This is just totally unusable on Windows.

I've been able to work around most of this, see below:

Been using/testing in windows platform - here are a some findings:

1. Command used:

> codex --ask-for-approval never --sandbox workspace-write -c model_reasoning_effort="high" -c model_reasoning_summary="detailed" -c model_verbosity="high" -c tools.web_search="true" --search

1. Prompting appears to be key, prepending below works a charm:

> For tool calling you are running inside a Windows machine with access to pwsh and cmd shells and I have made msbuild, sed, grep, rg, ls, jq, less, curl, and wget commands available. {rest of my prompt/request}

1. Providing Unix commands/binaries within powershell gets it to do most/all of the core tasks - find, search, read, patch.

• Removing and then shimming out specific windows powershell bastardizations, e.g. ls in powershell is key. E.g.:

Powershell profile:
> if (Test-Path Alias:\ls) {
> Remove-Item Alias:ls # Remove built-in ls alias, we replace it with a shim (ls.cmd) that automatically routes to correct command
> }
>
> if (Check-Command cmd) {
> if (Test-Path Alias:\dir) {
> Remove-Item Alias:dir # Remove built-in dir alias, use cmd dir function
> }
> Function dir { cmd /r dir $args }
> }
> if (betterWhereIs curl | Where-Object {$_.Type -eq "Executable"}) {
> if (Test-Path Alias:\curl) {
> Remove-Item Alias:curl # Remove built-in curl alias, prefer curl binary if available
> }
> }

1. About once out of every ~10 runs the model tries approach of using separate pwsh commands (which wants approval on every single one). Closing and starting the session over usually solves this for me,.

1. I have not seemingly been able to get non-approved commands to [consistently] work. Well, technically when it is running pwsh sequenced commands, all commands are available and msbuild does work/run (the downside being there being every single read/search etc prompts for approval). That aside, codex-cli keeps butting up against some kind of whitelisted allowlist but I can't find a config on how to set. Opened https://github.com/openai/codex/issues/3821 to see if can get more info/docs.

--

ls.cmd (shim for better ls)
<details>

@echo off
REM --- ls shim for cmd.exe / PowerShell-aware --------------------------------
REM Behavior:
REM - If running under PowerShell (parent or grandparent process is powershell.exe or pwsh.exe)
REM     * If args contain known Unix ls flags then call msls %*
REM     * Else if args contain known Get-ChildItem flags then call Get-ChildItem %*
REM     * Else with no flags call Get-ChildItem %*   default in PowerShell
REM - If running under cmd.exe
REM     * If msls exists then call msls --color=auto -alhpF %*
REM     * Else call dir %*
REM ---------------------------------------------------------------------------

setlocal EnableExtensions EnableDelayedExpansion

REM Detect msls
where msls >nul 2>nul
set "HAVE_MSLS=0"
if %ERRORLEVEL% EQU 0 set "HAVE_MSLS=1"

REM Compute whether this CMD was started with /c which indicates a one-shot trampoline call
REM Use string substitution instead of piping CMDCMDLINE to findstr to avoid noise from quotes and meta chars
set "IS_CMD_C=0"
set "CMDCMD=%CMDCMDLINE%"
set "CMDCMD=%CMDCMD:"=%"
REM strip quotes so /c" becomes /c
set "CMDCMD=%CMDCMD% "
REM pad trailing space so end-of-line matches become ' /c '
if not "%CMDCMD: /c =%"=="%CMDCMD%" set "IS_CMD_C=1"
if not "%CMDCMD: /C =%"=="%CMDCMD%" set "IS_CMD_C=1"

REM Detect if invoked from PowerShell. Prefer CIM via PowerShell or pwsh. Keep WMIC fallback.
set "IN_POWERSHELL=0"
set "SELF=%~f0"

REM Prefer pwsh, then Windows PowerShell
set "PSHOST="
where pwsh >nul 2>nul && set "PSHOST=pwsh"
if not defined PSHOST ( where powershell >nul 2>nul && set "PSHOST=powershell" )

if defined PSHOST (
  "%PSHOST%" -NoProfile -NoLogo -ExecutionPolicy Bypass -Command ^
    "$pp=(Get-CimInstance Win32_Process -Filter ('ProcessId={0}' -f $PID)).ParentProcessId;" ^
    "$me=Get-CimInstance Win32_Process -Filter ('ProcessId={0}' -f $pp);" ^
    "$p =Get-CimInstance Win32_Process -Filter ('ProcessId={0}' -f $me.ParentProcessId);" ^
    "if ($p.Name -eq 'conhost.exe') { $p=Get-CimInstance Win32_Process -Filter ('ProcessId={0}' -f $p.ParentProcessId) }" ^
    "if ($p.Name -match '^(pwsh|powershell)\.exe$') { exit 0 } else { exit 1 }" >nul

  REM Use delayed expansion and only treat as PowerShell when this CMD was started with /c
  if !ERRORLEVEL! EQU 0 if "!IS_CMD_C!"=="1" set "IN_POWERSHELL=1"
)

REM Legacy WMIC fallback only if not already determined
if "!IN_POWERSHELL!"=="0" (
  set "PPID="
  set "PPNAME="
  set "GPPID="
  set "GPPNAME="

  where wmic >nul 2>nul
  if !ERRORLEVEL! EQU 0 (
    REM Find our current cmd.exe row by matching the command line with our script path
    for /f "skip=1 tokens=1,2,*" %%A in ('
      wmic process where "name='cmd.exe'" get ProcessId^,ParentProcessId^,CommandLine /format:table
    ') do (
      REM Columns: ProcessId  ParentProcessId  CommandLine
      echo(%%C | findstr /I /C:"%SELF%" >nul
      if not errorlevel 1 set "PPID=%%B"
    )
    if defined PPID (
      for /f "tokens=2 delims==" %%N in ('
        wmic process where "ProcessId=%PPID%" get Name /value ^| findstr "="
      ') do set "PPNAME=%%N"

      REM If parent is conhost.exe, walk up one more level to check its parent
      if /I "!PPNAME!"=="conhost.exe" (
        for /f "tokens=2 delims==" %%N in ('
          wmic process where "ProcessId=%PPID%" get ParentProcessId /value ^| findstr "="
        ') do set "GPPID=%%N"
        if defined GPPID (
          for /f "tokens=2 delims==" %%N in ('
            wmic process where "ProcessId=!GPPID!" get Name /value ^| findstr "="
          ') do set "GPPNAME=%%N"
        )
      )

      REM Only mark PowerShell when parent or grandparent is PS and this CMD was started with /c
      if /I "!PPNAME!"=="powershell.exe"  if "!IS_CMD_C!"=="1" set "IN_POWERSHELL=1"
      if /I "!PPNAME!"=="pwsh.exe"        if "!IS_CMD_C!"=="1" set "IN_POWERSHELL=1"
      if /I "!GPPNAME!"=="powershell.exe" if "!IS_CMD_C!"=="1" set "IN_POWERSHELL=1"
      if /I "!GPPNAME!"=="pwsh.exe"       if "!IS_CMD_C!"=="1" set "IN_POWERSHELL=1"
    )
  )
)

REM PowerShell-aware branch
if "!IN_POWERSHELL!"=="1" (
  REM Known GCI switches including common parameters
  set "GCI_LIST= Path LiteralPath Filter Include Exclude Recurse Force Depth Hidden Directory File Name Attributes System ReadOnly ErrorAction ErrorVariable OutVariable OutBuffer Verbose Debug WarningAction WarningVariable InformationAction InformationVariable WhatIf Confirm PipelineVariable "

  REM Known Unix long options to recognize
  set "UNIX_LONG= --color --all --long --human-readable --group-directories-first --classify --almost-all --time-style --quoting-style "

  set "HAS_UNIX=0"
  set "HAS_GCI=0"

  for %%A in (%*) do (
    set "arg=%%~A"
    if "!arg:~0,1!"=="-" (
      if "!arg:~0,2!"=="--" (
        for /f "tokens=1 delims==" %%K in ("!arg!") do set "opt=%%K"
        echo !UNIX_LONG! | findstr /I /C:" !opt! " >nul && set "HAS_UNIX=1"
      ) else (
        set "token=!arg:~1!"
        for /f "tokens=1 delims=:" %%K in ("!token!") do set "tname=%%K"
        echo !GCI_LIST! | findstr /I /C:" !tname! " >nul && set "HAS_GCI=1"
        if "!HAS_GCI!"=="0" (
          echo(!tname!| findstr /R "^[A-Za-z0-9][A-Za-z0-9]*$" >nul && set "HAS_UNIX=1"
        )
      )
    )
  )

  REM Choose runner for GCI
  set "PSRUN=!PSHOST!"
  if not defined PSRUN set "PSRUN=powershell"

  REM If Unix-style flags were used and msls exists, let msls handle them
  if "!HAVE_MSLS!"=="1" if "!HAS_UNIX!"=="1" (
    msls --color=auto -alhpF %*
    exit /b !ERRORLEVEL!
  )

  REM If GCI-style flags present, call Get-ChildItem
  if "!HAS_GCI!"=="1" (
    "!PSRUN!" -NoProfile -ExecutionPolicy Bypass -Command "Get-ChildItem @args" %*
    exit /b !ERRORLEVEL!
  )

  REM Default in PowerShell context is Get-ChildItem
  "!PSRUN!" -NoProfile -ExecutionPolicy Bypass -Command "Get-ChildItem @args" %*
  exit /b !ERRORLEVEL!
)

REM Plain cmd.exe branch
if "%HAVE_MSLS%"=="1" (
  msls --color=auto -alhpF %*
  exit /b !ERRORLEVEL!
)

dir %*
exit /b !ERRORLEVEL!

</details>

msbuild.cmd (shim for msbuild)
<details>

@echo off
rem ---------------------------------------------------------------------------
rem msbuild.cmd - file-based shim that locates and invokes the preferred MSBuild
rem Priority:
rem   (1) 64-bit (amd64) first, then 32-bit
rem   (2) Visual Studio (Community) before Build Tools
rem   (3) Newest installation (by year folder, e.g., 2025 > 2022 > 2019)
rem
rem Always verbose:
rem   - This shim unconditionally enables MSBUILD_SHIM_VERBOSE=1.
rem Optional toggle:
rem   - Set MSBUILD_ARCH=x86 to prefer 32-bit first (default is x64)
rem ---------------------------------------------------------------------------
setlocal
set "MSBUILD_SHIM_VERBOSE=1"

rem Choose architecture preference (default x64/amd64)
set "ARCHPAT=amd64"
if /i "%MSBUILD_ARCH%"=="x86" set "ARCHPAT="

rem Locate vswhere (installed with VS 2017+). If absent, we'll do manual search.
set "VSWHERE=%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe"
if not exist "%VSWHERE%" (
  for %%V in (vswhere.exe) do set "VSWHERE=%%~$PATH:V"
)

rem --- Try vswhere-based discovery first -----------------------------------------
if exist "%VSWHERE%" (
  rem Visual Studio (Community/Pro/Enterprise) first
  call :FIND_MSBUILD "Microsoft.VisualStudio.Product.Enterprise Microsoft.VisualStudio.Product.Professional Microsoft.VisualStudio.Product.Community" "%ARCHPAT%" MSBUILD
  if defined MSBUILD goto :RUN

  rem Build Tools next
  call :FIND_MSBUILD "Microsoft.VisualStudio.Product.BuildTools" "%ARCHPAT%" MSBUILD
  if defined MSBUILD goto :RUN

  rem If x64-first failed, retry allowing 32-bit under the same products
  if /i not "%MSBUILD_ARCH%"=="x86" (
    call :FIND_MSBUILD "Microsoft.VisualStudio.Product.Enterprise Microsoft.VisualStudio.Product.Professional Microsoft.VisualStudio.Product.Community" "" MSBUILD
    if defined MSBUILD goto :RUN

    call :FIND_MSBUILD "Microsoft.VisualStudio.Product.BuildTools" "" MSBUILD
    if defined MSBUILD goto :RUN
  )
)

rem --- Manual ("legacy") search by explicit path patterns, dynamic year ------------
rem Matches these types of paths (year is dynamic: 20*), newest year first:
rem   C:\Program Files\Microsoft Visual Studio\<YEAR>\Community\MSBuild\Current\Bin\amd64\MSBuild.exe
rem   C:\Program Files\Microsoft Visual Studio\<YEAR>\Community\MSBuild\Current\Bin\MSBuild.exe
rem   C:\Program Files (x86)\Microsoft Visual Studio\<YEAR>\BuildTools\MSBuild\Current\Bin\amd64\MSBuild.exe
rem   C:\Program Files (x86)\Microsoft Visual Studio\<YEAR>\BuildTools\MSBuild\Current\Bin\MSBuild.exe
call :FIND_MSBUILD_MANUAL "%ARCHPAT%" MSBUILD
if defined MSBUILD goto :RUN

rem If we preferred x64 and didn't find it, try 32-bit equivalents for the same patterns
if /i not "%MSBUILD_ARCH%"=="x86" (
  call :FIND_MSBUILD_MANUAL "" MSBUILD
  if defined MSBUILD goto :RUN
)

rem --- Final fallback to legacy .NET Framework MSBuild ----------------------------
:LEGACY
set "MSBUILD=%WINDIR%\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe"
if exist "%MSBUILD%" goto :RUN
set "MSBUILD=%WINDIR%\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe"
if exist "%MSBUILD%" goto :RUN

>&2 echo [msbuild.cmd] ERROR: Unable to locate MSBuild.exe.
exit /b 9009

:RUN
if defined MSBUILD_SHIM_VERBOSE echo [msbuild.cmd] Using: "%MSBUILD%"
"%MSBUILD%" %*
set "code=%errorlevel%"
exit /b %code%

rem ------------------------------------------------------------------------------
rem :FIND_MSBUILD <products> <archpat> <outvar>
rem Uses vswhere to find the newest instance with MSBuild, optionally preferring amd64.
rem ------------------------------------------------------------------------------
:FIND_MSBUILD
setlocal
set "PRODUCTS=%~1"
set "ARCHPAT=%~2"
set "OUTVAR=%~3"

if defined ARCHPAT (
  for /f "usebackq delims=" %%P in ( `
    "%VSWHERE%" -latest -products %PRODUCTS% -requires Microsoft.Component.MSBuild ^
      -find MSBuild\**\Bin\amd64\MSBuild.exe
  ` ) do (
    endlocal & set "%OUTVAR%=%%P" & goto :EOF
  )
)

for /f "usebackq delims=" %%P in ( `
  "%VSWHERE%" -latest -products %PRODUCTS% -requires Microsoft.Component.MSBuild ^
    -find MSBuild\**\Bin\MSBuild.exe
` ) do (
  endlocal & set "%OUTVAR%=%%P" & goto :EOF
)

endlocal & set "%OUTVAR%=" & goto :EOF

rem ------------------------------------------------------------------------------
rem :FIND_MSBUILD_MANUAL <archpat> <outvar>
rem Manual path search by the specific patterns requested, with dynamic year folder.
rem Checks Community (Program Files) first, then Build Tools (Program Files x86).
rem Within each, prefers amd64 (if ARCHPAT is set), then 32-bit, and years newest first.
rem ------------------------------------------------------------------------------
:FIND_MSBUILD_MANUAL
setlocal
set "ARCHPAT=%~1"
set "OUTVAR=%~2"

rem --- 1) Community under Program Files ------------------------------------------
for /f "usebackq delims=" %%Y in ( `
  dir /b /ad /o-n "%ProgramFiles%\Microsoft Visual Studio\20*" 2^>nul
` ) do (
  if defined ARCHPAT (
    if exist "%ProgramFiles%\Microsoft Visual Studio\%%Y\Community\MSBuild\Current\Bin\amd64\MSBuild.exe" (
      endlocal & set "%OUTVAR%=%ProgramFiles%\Microsoft Visual Studio\%%Y\Community\MSBuild\Current\Bin\amd64\MSBuild.exe" & goto :EOF
    )
  )
  if exist "%ProgramFiles%\Microsoft Visual Studio\%%Y\Community\MSBuild\Current\Bin\MSBuild.exe" (
    endlocal & set "%OUTVAR%=%ProgramFiles%\Microsoft Visual Studio\%%Y\Community\MSBuild\Current\Bin\MSBuild.exe" & goto :EOF
  )
)

rem --- 2) Build Tools under Program Files (x86) ----------------------------------
if defined ProgramFiles(x86) (
  for /f "usebackq delims=" %%Y in ( `
    dir /b /ad /o-n "%ProgramFiles(x86)%\Microsoft Visual Studio\20*" 2^>nul
  ` ) do (
    if defined ARCHPAT (
      if exist "%ProgramFiles(x86)%\Microsoft Visual Studio\%%Y\BuildTools\MSBuild\Current\Bin\amd64\MSBuild.exe" (
        endlocal & set "%OUTVAR%=%ProgramFiles(x86)%\Microsoft Visual Studio\%%Y\BuildTools\MSBuild\Current\Bin\amd64\MSBuild.exe" & goto :EOF
      )
    )
    if exist "%ProgramFiles(x86)%\Microsoft Visual Studio\%%Y\BuildTools\MSBuild\Current\Bin\MSBuild.exe" (
      endlocal & set "%OUTVAR%=%ProgramFiles(x86)%\Microsoft Visual Studio\%%Y\BuildTools\MSBuild\Current\Bin\MSBuild.exe" & goto :EOF
    )
  )
)

endlocal & set "%OUTVAR%=" & goto :EOF

On Windows + VS Code extension, this feels like installing a steering wheel on a bicycle; it looks cool, but you cant drive anywhere. the plugin is almost useless there.

This issue is not caused by sandbox restrictions. The problem of requiring authorization on Windows due to lack of complete sandbox mechanisms has been fixed by this PR: https://github.com/openai/codex/pull/2988. Thanks again to @Sing303.

The current issue is caused by Codex's preference for wrapping command execution on Windows by default. This prevents Codex's whitelist command recognition mechanism from identifying read-type commands that should be allowed to pass through.

My current solution is to add a prompt in AGENTS.md that prohibits wrapper execution:

Must be called directly (e.g `{"command":["sg", "-p", "'console.log($$$ARGS)'"]","timeout_ms":120000,"workdir":"C:\Users\username"}`)

Must use `workdir` to specify path instead of using `cd` in commands.

Prohibited from using `bash -lc` or `pwsh.exe -NoLogo -NoProfile -Command` or `powershell.exe -NoLogo -NoProfile -Command` wrapper calls for installed tools.

This forces Codex to directly call commands like ls, rg, or sed. I'm using scoop to install busybox and ripgrep to provide these commands:

scoop install busybox ripgrep

This way Codex can execute Unix-like commands and be properly recognized by Codex's whitelist command mechanism.

is there a sentence I can tell codex on windows that will cause it to read an entire file into its context window (in read-only mode)? It seems to be able to run 'rg' but it spends a suspicious amount of time doing things like analyzing truncation mode

Activating "Agent (full access)" made the trick here.

<img width="498" height="958" alt="Image" src="https://github.com/user-attachments/assets/f5f5eaa1-14fc-4a33-937e-02848051be04" />

Still have these issues even with the above merged fixes. Full access works but I don't want to give it access to everything like this.

Using the normal agent mode doesn't work and asks permission even to read a file in the same workspace.

Codex works great on my mac but I end up still using claude code as I need it running on windows too (game dev)

@xjjon

As I mentioned in my previous comment https://github.com/openai/codex/issues/2860#issuecomment-3313415968, I tested with the default permission settings and found that basic commands like ls, rg, etc. can execute without requiring approval:

╭────────────────────────────────────────────────────────╮
│ >_ OpenAI Codex (v0.39.0-alpha.1)                      │
╰────────────────────────────────────────────────────────╯

/status
📂 Workspace
  • Path: ~
  • Approval Mode: on-request
  • Sandbox: read-only
  • AGENTS files: (none)

🧠 Model
  • Name: gpt-5
  • Reasoning Effort: Minimal
  • Reasoning Summaries: Auto

💻 Client
  • CLI Version: 0.39.0-alpha.1

▌ just run ls, no more

> I'll list the files and folders in the current working directory to understand the environment.

• Explored
  └ List ls

> Listed the home directory contents. Do you need me to ls into any specific subdirectory?

With these default settings (Approval Mode: on-request, Sandbox: read-only), commands like ls and rg execute without needing explicit approval each time. This seems to work smoothly in v0.39.0-alpha.1.

Simpsons also predicted how to work with Codex in Windows

!Image

Selecting "Agent (full access)" obviously works for not getting those annoying permission requests but in Windows its doing those "Ran Powershell.exe -NoProfile -Command '...." EVERYTIME it needs to read a file or do an action like running a python script to modify files, it seems like a bug... which is also making it SUPER slow in comparison to run cursor + codex extension connecting via SSH to a Linux server.

I also have this problem on macOS.

I don't understand how almost every other CLI has this nailed but not Codex...

--yolo mode works but I don't like using it.

is it really difficult to always allow readonly commands and ask for write commands? currently it is always asking for everything... claude does it great. gemini does it great. codex asks me 250 times before it can read a project folder. (why i still have to use codex? because I only have company api key for openai/codex)

how to limit --yolo to current working directory and subdirectories only pls ? I did run codex --yolo in powershell 7.5 windows 10 and it started to discover upper folders too . I did run codex --yolo in maind1/subd1/subsubd1 and I saw it is reading/parsing maind1 root files beside files in maind1/subd1/someothersubd2 .. just changed few hrs ago from Claude CLI to Codex CLI.. I am scared ..

And yes I tried this because I was getting the same pwsh permission requests every second (even though I said do not ask , allow always option).. with --yolo I didnt get any question at all , but must figure out only workspace with --yolo )

I am on OpenAI Codex (v0.42.0) Thanks.

The workaround mentioned earlier by LaelLuo makes it tolerable.

I have installed ripgrep with winget install BurntSushi.ripgrep.GNU and the other GNU tools were already available on my system thanks to Git, in C:\Program Files\Git\usr\bin

This single instruction in AGENTS.md (or in the CODEX conversation) works so far:

Prohibited from using bash -lc or pwsh.exe -NoLogo -NoProfile -Command or powershell.exe -NoLogo -NoProfile -Command wrapper calls for installed tools. Use native linux tools (ls, rg, sed, cat, etc), they are available in your environment

To be fair, the documentation does state that Codex on Windows is best used on WSL, but IMO there should be a runtime check and warning, for discoverability. Otherwise it makes for a pitiful first time experience.

Same issue. My god its frustrating!

Wow yeah the difference between running Codex in a WSL terminal, versus running it as a VS Code extension in windows is STARK.

I'm honestly surprised the extension was released - when you compare the experience to Copilot or Claude, Codex comes away looking really really bad. Usually I roll my eyes at descriptions like "unusable" but in this case I actually completely agree with OP - it's like it's actively trying to discourage you from using the extension (or actively encouraging you to use full auto / yolo, which is terrifying)

@etraut-openai just to clarify, it's happening not only on windows, here I'm using MacOS

019a4551-4cc9-7ca2-9285-8f3ab6474375

@kidcuauh, this is a known issue on Windows. Because there is no sandbox on Windows, all tool calls require user approval. This isn't the case on MacOS, so if you're seeing an issue there, it's a different problem. Please search for other related issues, and if you'd find one, file a new bug report that includes details about the behavior you're seeing.

There has been new progress on this issue. I can see that the main branch now has an experimental option [features].enable_experimental_windows_sandbox. When enabled, using approval_policy = "on-request" with sandbox_mode = "workspace-write" means that at least when Codex uses apply_patch to edit files within the project, no authorization is required.

However, as I mentioned above in https://github.com/openai/codex/issues/2860#issuecomment-3313415968, the root cause of this issue is the failure of the command whitelist recognition mechanism.

But I now notice that there's code for a pwsh command whitelist mechanism at codex-rs/core/src/command_safety/windows_safe_commands.rs:142, so even without installing busybox-related executables, the experience should now be much more comfortable.

However, there's still a model-level issue: when the Codex model realizes it's running in a Windows environment, it has a strong tendency to use script-based file modification rather than prioritizing apply_patch. In these cases, you'll likely still need to authorize approval. Interestingly, this tendency is rarely seen on Unix platforms.

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've 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.

I have been using codex-cli with the Terminal app on Windows 11 and gpt-5.1-codex-max for the past hour and the difference compared to before is night and day. It now just works! Navigating folders, running commands, reading, creating and editing files. It just works! Thank you

@etraut-openai Did I got it right by the Windows sandbox mode you mean this one?
https://learn.microsoft.com/ru-ru/windows/security/application-security/application-isolation/windows-sandbox/

Looks like these are related #6521

@nos1609, no that's not the sandbox I'm referring to. The codex team has implemented a sandbox mechanism that leverages restricted tokens in the Windows kernel to provide write protections for file system locations outside of your working directory. You can read more about it here.

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

For what it's worth, while the update did help to significantly reduce the number of 'allows' you need to click through on windows, I feel like "Allow this session" can't be functioning as intended. As an example from today -

<img width="319" height="772" alt="Image" src="https://github.com/user-attachments/assets/320afa90-0e65-49b4-9385-d4930e5a74fa" />

each of these 'edited' entries marked in blue asked for confirmation, and each one I answered with 'Allow this session' - but what exactly am I allowing, given that the next request, often to edit the same file, just results in _another_ nag to grant permission?

this is using the codex plugin in vscode:

Identifier: openai.chatgpt
Version: 0.4.46
Last Updated: 1 day ago
Size: 125.90MB

is this still expected behavior? because it feels like it's checking in too often Claude might have asked once at the beginning of the process, or maybe even once per file, but would not have bugged me over and over again every time it wants to make an edit to the same file, especially not once I'd already granted it permission for the session.

I'm being asked for approval for file edits within the sandboxed workspace even though I am in the "Agent" mode. "Allow this session" also doesn't seem to work; It will continue to ask for permission for file edits, even after clicking that option. Hopefully I'm not misunderstanding either of these functionalities, but this was previously resolved and has only recently become an issue again.

As I mentioned above, if you see further issues with Windows tool permissions or sandboxing, please open new issues with repro steps and additional details. That will help us focus our attention on the most important issues. Thanks!

I'm going to lock this issue to prevent additional posts.