Codex App on Windows: sandbox setup fails when project folder owner is BUILTIN\Administrators
What version of the Codex App are you using (From “About Codex” dialog)?
Version 26.623.141536 • Released 2026/07/07
What subscription do you have?
PLUS
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
On Windows 11 Pro 25H2, Codex App could not list files in a newly created project folder.
The visible error was:
windows sandbox: helper_unknown_error: setup refresh had errors
The sandbox log showed:
write ACE grant failed on G:\python\CodexP: SetNamedSecurityInfoW failed: 5
setup refresh completed with errors
setup error: setup refresh had errors
Codex CLI could read and write files in the same folder.
Normal applications could also read and write files.
However, Codex App failed before the PowerShell command itself was executed.
The project folder owner was:
BUILTIN\Administrators
After changing the owner to the current Windows user, Codex App could list files normally.
Command used:
takeown /F G:\python\CodexP /R /D Y
What steps can reproduce the bug?
see above
What is the expected behavior?
_No response_
Additional information
_No response_
4 Comments
I reproduced the same issue on an external NTFS drive.
The project folder was owned by an unresolved SID from another Windows PC. Explorer and IDEs could still read and write files normally, but Codex App failed with:
Running the following command as administrator fixed it:
After that, Codex could access the project normally.
This also affects folders owned by unresolved SIDs, not just BUILTIN\Administrators.
I can confirm this issue also affected Browser Use in the latest Codex Windows app, and changing the workspace owner fixed it.
Environment
iab)Symptoms
Browser Use failed before connecting because the Windows sandbox exited during initialization.
The visible error was:
The generated
setup_error.jsoncontained only:An older sandbox log also contained an
ERROR_ELEVATION_REQUIRED (740)error from a previous Codex version, but the current helper binary was different and appeared correctly updated:Therefore, the old error 740 did not appear to be the cause of the current failure.
Workspace permissions
The workspace root owner was:
The workspace already had Codex sandbox ACL entries, but Browser Use still failed during sandbox initialization.
I changed only the workspace root owner to the current Windows user from an elevated PowerShell session:
After the change:
Result
I restarted Codex normally, without running it as administrator, and executed Browser Use again.
It then started successfully:
I did not need to:
EnableInstallerDetectionunelevatedsandboxThis appears to confirm that an administrator-owned workspace root can cause the generic
helper_unknown_error: setup refresh had errors, including for Browser Use, even when the current sandbox helper is correctly signed and contains anasInvokermanifest.It would be useful if Codex detected this condition and displayed an actionable message such as:
Ideally, Codex could offer a UAC-assisted repair action instead of returning only the generic helper error.
I also ran into this after migrating to the new ChatGPT/Codex Windows app. Changing the workspace owner also fixed it in my case.
Confirmed on a newer Codex Desktop build with the same root cause.
Environment:
OpenAI.Codex_26.707.3748.0_x640.144.0-alpha.410.0.26100, x64D:volumeObserved user-facing failure when starting the bundled Browser / Node REPL:
The underlying sandbox log identifies the real failure:
ACL inspection confirms that the workspace root, repository, and
.gitdirectory are owned by:Additional diagnostics:
Status: Ok.codex doctor --jsonreports zero failures for installation, auth, state databases, network, and sandbox configuration.codex sandbox -- cmd.exe /c "echo sandbox-ok"smoke test succeeds.v24.14.0.This confirms the generic
helper_unknown_erroris masking an NTFSWRITE_DAC/ ACE update failure. It would help if the app surfaced the failed path, Win32 error 5, and an actionable ownership/ACL repair instead of recommending browser or app restarts.