Codex App on Windows: sandbox setup fails when project folder owner is BUILTIN\Administrators

Open 💬 4 comments Opened Jul 7, 2026 by inakanoko

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_

View original on GitHub ↗

4 Comments

niboshi-konbu · 1 month ago

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:

SetNamedSecurityInfoW failed: 5

Running the following command as administrator fixed it:

takeown /F "G:\path\to\project" /R /D Y

After that, Codex could access the project normally.

This also affects folders owned by unresolved SIDs, not just BUILTIN\Administrators.

ChonabayashiKatsuya · 1 month ago

I can confirm this issue also affected Browser Use in the latest Codex Windows app, and changing the workspace owner fixed it.

Environment

  • Windows 11 Pro 25H2
  • OS build: 26200.8457
  • Codex version: 26.707.31428
  • Released: 2026-07-10
  • Sandbox mode: elevated
  • Browser: Codex In-app Browser (iab)

Symptoms

Browser Use failed before connecting because the Windows sandbox exited during initialization.

The visible error was:

windows sandbox failed:
helper_unknown_error: setup refresh had errors
reason: stdout_eof

The generated setup_error.json contained only:

{
  "code": "helper_unknown_error",
  "message": "setup refresh had errors"
}

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:

Signature                  : Valid
HasRequestedExecutionLevel : True
HasAsInvoker               : True

Therefore, the old error 740 did not appear to be the cause of the current failure.

Workspace permissions

The workspace root owner was:

BUILTIN\Administrators

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:

$workspace = "D:\path\to\workspace"
$currentUser = (whoami).Trim()

takeown /F $workspace
icacls $workspace /setowner $currentUser /C

After the change:

Owner: <current Windows user>

Result

I restarted Codex normally, without running it as administrator, and executed Browser Use again.

It then started successfully:

Browser: Codex In-app Browser
Type: iab
Sandbox initialization error: none
ERROR_ELEVATION_REQUIRED (740): not reproduced

I did not need to:

  • disable Smart App Control
  • disable UAC
  • change EnableInstallerDetection
  • switch to the weaker unelevated sandbox
  • remove the Codex sandbox users or firewall rules
  • reset the workspace ACLs

This 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 an asInvoker manifest.

It would be useful if Codex detected this condition and displayed an actionable message such as:

Codex cannot prepare sandbox permissions because the current user
does not own the workspace root or lacks permission to modify its ACL.

Ideally, Codex could offer a UAC-assisted repair action instead of returning only the generic helper error.

ron77950 · 1 month ago

I also ran into this after migrating to the new ChatGPT/Codex Windows app. Changing the workspace owner also fixed it in my case.

alexyakunin · 1 month ago

Confirmed on a newer Codex Desktop build with the same root cause.

Environment:

  • Codex/ChatGPT Desktop AppX: OpenAI.Codex_26.707.3748.0_x64
  • Bundled Codex CLI: 0.144.0-alpha.4
  • Windows 11 Pro 10.0.26100, x64
  • Workspace on an NTFS D: volume

Observed user-facing failure when starting the bundled Browser / Node REPL:

node_repl kernel exited unexpectedly
windows sandbox failed: helper_unknown_error: setup refresh had errors
reason: stdout_eof

The underlying sandbox log identifies the real failure:

write ACE grant failed on D:\Projects\<repo>: SetNamedSecurityInfoW failed: 5
setup refresh: processed 3 write roots; errors=["write ACE failed ..."]
setup refresh completed with errors
setup error: setup refresh had errors

ACL inspection confirms that the workspace root, repository, and .git directory are owned by:

BUILTIN\Administrators

Additional diagnostics:

  • The AppX package reports Status: Ok.
  • codex doctor --json reports zero failures for installation, auth, state databases, network, and sandbox configuration.
  • A direct codex sandbox -- cmd.exe /c "echo sandbox-ok" smoke test succeeds.
  • Browser runtime discovery succeeds and finds bundled Node v24.14.0.
  • The failure occurs before any JavaScript or browser navigation runs.
  • Restarting the app and recreating tasks/browser tabs does not help.

This confirms the generic helper_unknown_error is masking an NTFS WRITE_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.