Repository navigation
Windows sandbox repeatedly fails with helper_unknown_error: setup refresh had errors #42513
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.901.20858
What subscription do you have?
ChatGPT Plus
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
Codex repeatedly fails before it can read or edit repository files with:
windows sandbox failed:
helper_unknown_error: setup refresh had errors
This has happened at least 4 consecutive times.
The problem occurred both in a long-running Codex task and again after creating a completely new task with clean context.
A normal sandbox execution failed before reading the target files. I then explicitly authorized a single elevated apply_patch containing the complete patch payload and only the five approved paths, but that also failed before reading the first file with the same helper/setup refresh error.
No repository changes were applied.
What steps can reproduce the bug?
Feedback ID: 01a066fa-e20c-7c50-b66a-1c0f0bdbb9a9
What is the expected behavior?
Codex should initialize the Windows sandbox successfully, read the authorized local repository files, apply the requested scoped edits, and allow subsequent diff validation without failing during sandbox/helper setup.
Additional information
The failure appears to occur before repository command execution, not because of the repository contents.
Starting a new Codex task did not resolve it.
An explicitly authorized elevated apply_patch also failed before reading the first target file.
I avoided trying additional write mechanisms to prevent unintended repository modifications.
The ChatGPT feedback report above includes diagnostic/browser logs.
Reproduction details:
- Open Codex on Windows.
- Open a local repository task.
- Ask Codex to read/edit a small explicitly scoped set of files.
- Codex attempts to use the Windows sandbox.
- Execution fails with:
helper_unknown_error: setup refresh had errors - Retry in a brand-new Codex task.
- The same failure occurs again before the target file is read.
This has reproduced at least 4 consecutive times.
The issue occurred both in a long-running Codex task and in a newly created clean task.
An explicitly authorized elevated apply_patch also failed before reading the first target file.
No repository changes were applied.
The failure appears to occur during Windows sandbox/helper initialization, before repository command execution.
Activity
github-actions commentedon Sep 3, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
playdiplomatica commentedon Sep 4, 2026
@xxryze Is it failing in a git repo on your PC? If so, check if the Codex sandbox owns the
.gitdirectory. If it does, that could be the problem.You can run this since you're on Windows:
in the directory of the project.
If it returns something like:
then that's the issue. To fix it you would then just have to set the ownership back to you by running:
and then verify if it worked by running this again:
which should then return:
playdiplomatica commentedon Sep 4, 2026
If
icaclsortakedownfails, don't force the issue. You can then just paste the output of the terminal in ChatGPT and it'll diagnose the issue further.shapeh commentedon Sep 7, 2026
I have the same issue and codex sandbox does NOT own my .git - my local windows user does. I still have the error (ref #43416) and I am on 26.901.51231 and Pro.
acdole commentedon Sep 15, 2026
I’m seeing a very similar issue on Codex Desktop / Windows 11 with a WSL2 Ubuntu 24.04 workspace.
Feedback ID: 01a08f14-28f3-7410-a847-e543c75d34bd
Environment:
Symptoms include:
Local WSL itself is healthy. Commands such as id and docker ps work when they actually reach WSL, and the repository/Docker environment is otherwise functional.
One readiness sequence demonstrated the problem clearly:
This appears to be a Codex Desktop/Work execution or sandbox/command-dispatch issue rather than a repository, Git, Docker, WSL, or account-usage issue.
I’ve submitted diagnostics/screenshots under the Feedback ID above and can provide additional examples if useful.
Related WSL-specific behavior appears similar to #35380 and #25280.
Freemlen commentedon Sep 19, 2026
Related investigation: #43373.
A controlled Windows reproduction reached the same pre-command
setup refresh had errorsboundary. The key practical result was that sandbox initialization could fail on the normal user Temp path before any requested tool logic executed; using a process-scoped dedicated TEMP/TMP restored the trusted runtime on that machine.The later RCA also showed that
SetNamedSecurityInfoW(...)=5is an aggregate recursive ACL result and does not necessarily mean a root security write itself failed. This may be useful when interpreting sandbox logs for this issue.kakabanga commentedon Sep 28, 2026
Same error here, with a variant that may help isolate the cause: the failure is intermittent and self-clearing on retry, not persistent.
Environment: Codex CLI 0.155.1, Windows 11 (10.0.26200.9457),
sandbox_mode = "workspace-write",[windows] sandbox = "elevated", workspace on D: drive (not under user profile).What happens:
The first shell command of a session sometimes fails with:
Retrying the same command succeeds, and later commands in the session work normally.
Sandbox log observations (
%USERPROFILE%\.codex\.sandbox\):setup refreshruns reportprocessed 3 write roots (read roots delegated); errors=[].codex-command-runner-0.153.4.exe) differs from the CLI version (0.155.1) - a helper-vs-CLI version mismatch.Why this might matter:
The top-level error gives no underlying Win32 error, so it is hard to tell whether the transient failure is caused by the
C:\Users\Defaultaccess denial, a race in setup refresh, or something else. TheC:\Users\Defaultdirectory requires elevated permissions to modify attributes; if the hide-users step is sometimes fatal to the refresh and sometimes not, that could explain the intermittency.Ask:
helper_unknown_errorso transient vs persistent failures can be distinguished.C:\Users\Defaulthide-users access denial as non-fatal if it is currently contributing to the refresh failure.