Codex couldn't set up the sandbox

The admin and non-admin variants of Codex's Windows sandbox failure, the ownership corruption behind the worst of them, and the icacls fix that worked.

Last reviewed 2026-08-06 · verified against the pingdotgg/t3code repo

Couldn't set up admin sandbox
Couldn't set up non-admin sandbox
Couldn't set up your sandbox with administrator permissions
windows sandbox: setup refresh failed with status exit code: 1

All Windows, all the same subsystem. Codex sandboxes agent commands using Windows ACLs and a transient identity, and when that setup fails the app is unusable — in #26883 every project became inaccessible on launch.

First: does disabling the sandbox fix it?#

This is the fastest way to confirm the sandbox is the culprit, and it's the confirmed workaround from #21304.

Add to ~/.codex/config.toml (on Windows, %USERPROFILE%\.codex\config.toml):

experimental_windows_sandbox = false

Restart Codex. If everything works now, the sandbox was the problem and everything below applies.

The damaging variant: CodexSandboxOffline ownership#

If your project has started throwing access-denied errors that persist even after Codex is closed, check ownership before anything else.

#17179 documents what happens: in workspace-write mode, the sandbox rewrote ownership of project directories from the user account to CodexSandboxOffline, a transient sandbox identity. Ownership was left inconsistent down the tree:

<PROJECT_ROOT>            owner: your user
<PROJECT_ROOT>\src        owner: CodexSandboxOffline
<PROJECT_ROOT>\src\Core   owner: CodexSandboxOffline

Hundreds of items across temp, tests, runtime and tracked source files were affected. The symptoms that follow:

Access to the path '...AppConfig.ahk' is denied.
write ACE grant failed on <PROJECT_ROOT>\src\Core: SetNamedSecurityInfoW failed: 5
CreateProcessWithLogonW failed: 1056

Because the owning identity is transient, it no longer resolves — which also blocks Codex's own attempts to repair the ACLs. The reported trigger was a degraded state: a network interruption or an IDE update partway through a sandbox operation.

The fix that worked#

From an Administrator PowerShell session, with Codex closed:

takeown /F "<PROJECT_ROOT>" /R /D Y
icacls "<PROJECT_ROOT>" /setowner "<MACHINE>\<USER>" /T /C
icacls "<PROJECT_ROOT>" /inheritance:e /T /C

Reported to restore normal ownership and resolve the write failures permanently. Substitute your real project path, machine name and username.

What each does: takeown reclaims ownership recursively, /setowner sets it explicitly to your account, and /inheritance:e re-enables inheritance so children stop carrying the broken explicit entries.

Check the result before reopening Codex:

icacls "<PROJECT_ROOT>" /T /C | Select-String "CodexSandbox"

No matches means you're clean.

The git variant: orphan-SID Deny ACEs#

A narrower failure with the same root, from #21304:

error: cannot open '.git/FETCH_HEAD': Permission denied

The sandbox writes Deny ACEs onto .git using a machine SID that doesn't resolve on the host:

<orphan-SID>:(DENY)(W,D,Rc,DC)
<orphan-SID>:(OI)(CI)(IO)(DENY)(W,D,Rc,GW,DC)

The nasty detail is that this is invisible from where you'd look. To host PowerShell the SID throws IdentityNotMappedException and the Deny is effectively a no-op — so git works fine in your own terminal. Inside the Codex sandbox it resolves to the effective principal and blocks writes. The (OI)(CI)(IO) flags propagate the Deny to every child object, which is how FETCH_HEAD gets caught.

Inspect and clear:

icacls "<REPO>\.git"
icacls "<REPO>\.git" /remove:d "<orphan-SID>" /T /C

Reported environment: Codex Desktop 26.429.3425.0 from the Microsoft Store, Windows 11 Pro 26200, Codex CLI 0.128.0, standard non-Administrator user, repo at C:\Repos\<repo>\ outside OneDrive.

Admin vs non-admin sandbox#

Both variants of the message appear, and which one you get depends on your elevation and config. If one mode fails, try the other explicitly rather than assuming the install is broken — the relevant keys live in ~/.codex/config.toml:

sandbox = "workspace-write"      # or "elevated"
approval_policy = "on-request"   # or "never"

The configuration in #17179 that produced the ownership corruption was approval_policy = "never" with sandbox = "elevated". If you're running unattended with approvals off, that combination is worth reconsidering.

Microsoft Store installs, again#

#21304 is a Store/WindowsApps build, and the Store package is over-represented across Codex's Windows failures generally — see failed to start app-server and manifest entry is missing.

If you're on the Store build and hitting sandbox problems, switching install method removes a whole class of ACL issues at once:

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

Install options →

Related reports#

Same subsystem, different symptom — worth checking if yours doesn't match above:

FAQ#

What does "Couldn't set up admin sandbox" mean in Codex?#

Codex failed to create the Windows sandbox it uses to contain agent-run commands. The app is typically unusable when this happens. Setting experimental_windows_sandbox = false in ~/.codex/config.toml confirms whether the sandbox is the cause.

How do I disable the Codex sandbox on Windows?#

Add experimental_windows_sandbox = false to %USERPROFILE%\.codex\config.toml and restart Codex. This is a confirmed workaround, but it means agent commands run with your full user privileges.

What is CodexSandboxOffline and why does it own my files?#

It's a transient identity the Windows sandbox uses. A sandbox operation interrupted partway through can leave project files owned by it, and because the identity no longer resolves, access-denied errors persist even with Codex closed. takeown plus icacls /setowner restores your ownership.

Why does git fail inside Codex but work in my terminal?#

The sandbox can write Deny ACEs onto .git using a SID that doesn't resolve on the host. From your terminal that Deny is a no-op, so git works; inside the sandbox it resolves and blocks writes such as FETCH_HEAD.

Is the Codex Windows sandbox safe to leave disabled?#

It removes a containment layer, so agent commands run with your privileges — the same exposure as running them yourself. Reasonable on repositories you trust, less so in unfamiliar code.