Sandbox setup error on Windows

Hey @CAMB-dev! I saw your report regarding the sandbox setup failure on Windows.

I've been working on the Windows sandbox logic today and found that the current implementation was missing several standard Windows SIDs (like Everyone and Authenticated Users) in the restricted token, which can lead to silent setup failures when trying to access workspace roots or system files.

I've consolidated a fix for this in #10648 which enables better root directory access and improves the setup reliability. If you're able to test the changes, it would be great to know if it resolves the setup hang for you!

Found the issue - the sandbox setup helper was looking up SIDs by name ('Everyone', 'Authenticated Users'), which can fail on some system locales. I've switched it to use well-known SIDs so it should be robust now. Let me know if that helps!

I've also updated the sandbox lock to use well-known SIDs for SYSTEM and Administrators, ensuring it works across all localized Windows versions.

Sorry for the slow response — due to time zone differences and some recent time constraints on my side, I haven’t had a chance to test whether the issue is resolved yet. Thank you so much for investigating this and taking the time to look into it!

I’ll try to test it when I have some free time and will report back if I find anything useful.

Thanks again for your help

I've performed a root-cause analysis on the Windows sandbox setup refresh failure. Here's what I found:

Root Cause Analysis

1. Mutex Ownership Race: In 0.95.0, un_setup_refresh in src/setup_orchestrator.rs acquires the Local\CodexSandboxSetupRefresh mutex before spawning the setup helper. The helper process then attempts to acquire the same mutex, fails with ERROR_ALREADY_EXISTS, and skips its execution.
2. Brittle Exit Condition: In efresh_only mode, the setup helper bails with exit code 1 if any path in ead_roots (including system roots like C:\Windows) encounters a sharing violation or access denied during ACL inspection. Activity from tools like Bun often triggers these transient errors, causing the entire refresh to fail.
3. Incomplete Refresh Pass: The current logic excludes write_roots from the refresh cycle. If the workspace is in write-root mode, its permissions are never refreshed during standard command execution.

Proposed Solution

• Mutex Bypass: Allow the setup helper to skip the mutex check when launched by the orchestrator specifically for a refresh.
• Best-Effort Refresh: Change the refresh pass to log warnings for individual ACL inspection failures rather than bailing with a non-zero exit code. This ensures resilience against transient file locks.
• Refresh Write Roots: Include write_roots in the best-effort refresh pass.

I have a draft implementation that stabilizes this on my local Windows dev environment. Let me know if you'd like me to submit a PR for this!

i have this bug right this moment

folder path : D:\86 se courses youtube kanali\016 Automation of Applications Through CMD

i had to manually change permission to all

normally i use config

@FurkanGozukara Maybe you could ask Codex to try elevating privileges and then try again, rather than using the approval command to change it? I tried this earlier and it worked for me without modifying permissions via the approval command.

@FurkanGozukara Maybe you could ask Codex to try elevating privileges and then try again, rather than using the approval command to change it? I tried this earlier and it worked for me without modifying permissions via the approval command.

interesting will test

@Ashutosh0x Thanks again for being so proactive in helping investigate this. Since I haven’t seen the issue again in the newer version (0.98), further testing on my side likely isn’t very meaningful.

I got this working finally. I tried elevating and it didn't help with the sandbox refresh. Chatgpt told me to turn off the elevation and "RELY ON" the experimental sandbox. That is what fixed my problem. I can now work again after two days.
What caused this to change and break is a mystery but so is anything OpenAI does, isn't it?

For people with a multi-user setup, I've fixed this error by ensuring the workspace folder is owned by the current Windows user in the security properties.

In my case, the project folder was cloned by another Windows user on the same machine and the sandbox setup was failing because it can't change permissions for folders owned by other users.

For people with a multi-user setup, I've fixed this error by ensuring the workspace folder is owned by the current Windows user in the security properties. In my case, the project folder was cloned by another Windows user on the same machine and the sandbox setup was failing because it can't change permissions for folders owned by other users.

I’m not sure that the other users would consider this a fix as now they have the problem that you have.
I’m wondering if the problem is that what I had for several days until I updated codex and I had to turn on experimental sandbox and turn off high something . Then. Along came another update that that fixed the entire mess. Well, I had to remove my rules file as it was erroring on every entry.
You might have been better off screwing security add give permissions to everyone on the root sandbox folder, down.

Any update about this issues? I still got the errors, and the apply_patch is unusable in Windows without Full Access Permissions.

I'm currently using the latest version and haven't run into this issue again. Unfortunately, I'm unable to reproduce it or provide any additional information at this time.

Additional data point from 2026-03-10 (still reproducible on newer CLI):

• Codex CLI:

I'm getting this now, version 0.114

I'm getting this now, version 0.114

same
execution error: Io(Custom { kind: Other, error: "windows sandbox backend cannot enforce file_system=Restricted,
network=Restricted, legacy_policy=DangerFullAccess; refusing to run unsandboxed" })

I still see this issue on Windows.

• App: Codex Desktop app (not CLI)
• OS: Windows 11
• Shell: PowerShell
• Sandbox mode: workspace-write

Error:
execution error: Io(Custom { kind: Other, error: "windows sandbox: setup refresh failed with status exit code: 1" })

How to reproduce:

1. Open a project folder.
2. Start a dev server in that folder (for example bun run dev).
3. Ask Codex to run any PowerShell command (even Get-Location).

Actual result:

• Commands fail with the sandbox setup refresh error.

Expected result:

• Commands should run normally in workspace-write mode.

Notes:

• If I stop the dev server, commands often start working again.
• This looks related to sandbox refresh/concurrency on Windows.

I get this one
execution error: Io(Custom { kind: Other, error: "windows sandbox: CreateProcessWithLogonW failed: 1327" })

• Version (extension)

26.304.20706

Darn. Now my sandbox is screwed up. I installed the new windows app. I’m not using it as it didn’t appeal to me. Now, I’m getting failures left and right.

Darn. Now my sandbox is screwed up. I installed the new windows app. I’m not using it as it didn’t appeal to me. Now, I’m getting failures left and right.

I also did. Maybe that's a trigger

> Darn. Now my sandbox is screwed up. I installed the new windows app. I’m not using it as it didn’t appeal to me. Now, I’m getting failures left and right. I also did. Maybe that's a trigger

Indeed. Same for me - the problem appeared after installing codex app

Also hitting that issue today. Really annoying and wasteful, when the model has to rewrite everything because the patch tool won't work.

I'd suggest using using codex on WSL. Solved most of these problems.

I'd suggest using using codex on WSL. Solved most of these problems.

I’ll have to try this as it most likely avoids the fake sandbox user.
This approach of using a limited account such as how Linux works for many tools is a good idea but lumping all 3rd party apps under one user isn’t smart.

Months later and the service is still 100% bricked. Where do those bajillions in investments go? Sam's polycule in the bahamas?

Check your [sandbox_workspace_write] entries in your config.toml: 'Local\CodexSandboxOnline' for example also triggers that error when written as entry.
Then close Codex and delete in your Local\.codex:
.sandbox,
.sandbox-bin,
.sandbox-secrets,
cap_sid,
state_5.sqlite,
state_5.sqlite-shm and
state_5.sqlite-wal

After that open your PS and call 'Get-Location' and right after 'Get-ChildItem -Force'.
Then start Codex again and you should be fine. It is an overall ACL problem and related to Windows...

Downgrading to version 0.113. fixed the problem for me.

Check your [sandbox_workspace_write] entries in your config.toml: 'Local\CodexSandboxOnline' for example also triggers that error when written as entry. Then close Codex and delete in your Local.codex: .sandbox, .sandbox-bin, .sandbox-secrets, cap_sid, state_5.sqlite, state_5.sqlite-shm and state_5.sqlite-wal After that open your PS and call 'Get-Location' and right after 'Get-ChildItem -Force'. Then start Codex again and you should be fine. It is an overall ACL problem and related to Windows...

I tried this. It reinstalled the codex sandbox, but it didn’t resolve problems .

I tried this. It reinstalled the codex sandbox, but it didn’t resolve problems .

You might have to clean some artifacts out of your worktree. When it is an environmental/shell issue, you might have set some wrong environmentals/a wrong config in your workspace that overwrite the global config. You need to fix them too, then go into .codex\worktrees, fix the config/environmentals there aswell and then do the process above. The best you can do is just cutting the configs and environmentals folder out of there to a place outside of any workspace.

Sadly this issue is a symptom of many different origins. You could also try running handle64.exe over it and analyse the root cause/ pass it to codex via prompting to analyse.

No, it doesn't work even on a fresh repo. The only env var I messed with is elevated/unelevated trying to debug this bug. It works on wsl but then the code has to be transfered back to host to actually connect with windows program integrations.

Opencode is free and runs just fine. Codex is just an embarrassment.

I can’t say what fixed for me. I did the file deletion, let code. Reinstall its sandbox and it didn’t help. I the went back to 5.2 which I’m sure didn’t fix it but I also uninstalled windows sandbox feature. No more problems. Yet, codex is still logging into sandbox account according to my event log.
No idea but I’m ever so slightly happier.

Check your [sandbox_workspace_write] entries in your config.toml: 'Local\CodexSandboxOnline' for example also triggers that error when written as entry. Then close Codex and delete in your Local.codex: .sandbox, .sandbox-bin, .sandbox-secrets, cap_sid, state_5.sqlite, state_5.sqlite-shm and state_5.sqlite-wal After that open your PS and call 'Get-Location' and right after 'Get-ChildItem -Force'. Then start Codex again and you should be fine. It is an overall ACL problem and related to Windows...

it worked, thank you

Don't know why it reappears randomly after restarting. Have to delete the following from config.toml as well as folders .sandbox and .sandbox-secrets to be able to reinstall sandbox mode and then things run fine again.

[windows]
sandbox = "elevated"

Don't know why it reappears randomly after restarting. Have to delete the following from config.toml as well as folders .sandbox and .sandbox-secrets to be able to reinstall sandbox mode and then things run fine again. `` [windows] sandbox = "elevated" ``

Codex pulls memory from the worktree. If you have old artifacts in the worktree under .codex\worktrees\X (such as a local workspace\.codex\config.toml overwrite), it will pull that and work with it again. That can cause the error to reappear.
You can also put sandox to unelevated, that can fix it too. But keep in mind that local configs overwrite the global config and environments, same as rules and skills.

You want to clean up in your worktree and your repo/workspace, then you clean up your global .codex by closing it and deleting

• .sandbox,
• .sandbox-bin,
• .sandbox-secrets,
• cap_sid,
• state_5.sqlite,
• state_5.sqlite-shm and
• state_5.sqlite-wal

Then open your PS and call 'Get-Location' and right after 'Get-ChildItem -Force', then reopen Codex and it should be fine. It installs a new sandbox and can not pull old artifacts from worktrees or old repos.

Best thing you can do it putting your configs into the web-gpt and let it check if all [sandbox_workspace_write]-entries you have are working on codex as some trigger this error.

Still broken on Codex v0.116.0

✘ Failed to apply patch └ execution error: Io(Custom { kind: Other, error: "windows sandbox: setup refresh failed with status exit code: 1" }) ──────────────────────────────────── • apply_patch is still broken in the sandbox. I’m falling back to a one-line PowerShell edit to finish the popup change now.

And then the super-long and unreadable Powershell edit commands ALWAYS require approval...
Awful friction (and security risk, as I have to blindly approve the Powershell commands).

Still reproducing for me on Windows with a newer Codex build.

Environment:

• Codex CLI: 0.117.0-alpha.24
• OS: Windows
• Shell/session seen by Codex: PowerShell
• Workspace: local repo on F:/...
• Approval flow: escalated commands work, non-escalated sandbox path is the one failing

Observed behavior:

• apply_patch fails immediately with:

windows sandbox: setup refresh failed with status exit code: 1

• the failure happens before any patch logic runs
• simple non-escalated shell commands also fail in the same sandbox path
• the same operations succeed when run escalated

Still looks like a Windows Codex sandbox initialization/refresh failure in the non-escalated path

Not sure why nobody fixes this yet. I've implemented a minimal fix on my branch and you can just get the built files from GitHub workflow: https://github.com/Mygod/codex/commits/fix-windows/

Until this is officially fixed, I guess I will just occasionally merge upstream and have GitHub rebuild. (Current version is basically v0.118.0.)

For people wanting to use the Codex app on Windows, you can grab the rebuild and then drop the patched codex binaries from above into the resources folder.

@Mygod, if you have diagnosed the root cause, can you share your analysis here? That would be much more useful to us than a PR or branch. Thanks!

No, I haven't done that. I only tested that the branch that I built fixed the issue for my Windows machine. I can take a closer look tomorrow if you want.

@etraut-openai Root case diagnosed via Codex below.

Confirmed RCA for my repro in #10601 below. I am not claiming every report in this thread has the same cause, but for my machine this is now confirmed rather than inferred. 1. In elevated Windows sandbox mode, every sandboxed command first runs a non-elevated refresh before the real command starts (require_logon_sandbox_creds -> run_setup_refresh). 2. In that refresh, the helper walks write_roots and, if the required sandbox ACEs are missing, it tries to add them via ensure_allow_write_aces(...), which ends in SetNamedSecurityInfoW(DACL_SECURITY_INFORMATION). 3. On my workspace root (E:\myfolder), that exact ACL rewrite is what fails. With a diagnostic build, the helper consistently logged: write ACE grant failed on E:\myfolder: SetNamedSecurityInfoW(DACL_SECURITY_INFORMATION) failed for E:\myfolder (...): 5 5 is ERROR_ACCESS_DENIED. 4. I then checked the folder outside Codex in a normal PowerShell session: Get-Acl 'E:\myfolder' whoami /user icacls 'E:\myfolder' What I found: - normal inherited ACLs grant Authenticated Users: Modify, so ordinary shell reads/writes work - the folder owner SID does not match my current user SID - this folder lives on a secondary disk from before an OS reinstall, so the owner is effectively an account from the previous Windows installation - my current non-elevated user can write files there, but does not have permission to change that folder’s ACL (WRITE_DAC / “Change permissions”) 5. So for this repro, the failure is: - Codex refresh decides the workspace root needs sandbox write ACEs - the refresh helper tries to rewrite the DACL on the workspace root - Windows denies that ACL rewrite because the current user is not the effective owner / does not have WRITE_DAC - refresh then fails before the actual command runs, which surfaces as windows sandbox: setup refresh failed with status exit code: 1 Conclusion: for my repro, this is not an apply_patch bug and not primarily a mutex bug. It is a stale-owner / no-WRITE_DAC workspace root on a secondary disk, combined with Codex assuming it can repair write-root ACLs during refresh. One important distinction: my “best-effort refresh” patch is only a mitigation for the pre-command failure. It does not change the underlying Windows ACL fact that this workspace root cannot be re-ACL’d by the current user. What would help upstream: 1. Surface the failing path and Win32 code directly in the user-visible error. 2. Detect/report the specific case “workspace is writable for normal I/O but current user cannot change its ACL”. 3. Avoid making refresh fail the entire command path just because ACL repair on a write root failed.

Running the terminal as admin fixes large patch failures. Verified many times myself.

The issue for me was that the Windows sandbox setup could not add its required ACL entry on my repo directory because that folder tree was owned by Administrators instead of my user. I still had normal file write access, but not permission to change the directory ACL, so sandbox setup kept failing with SetNamedSecurityInfoW failed: 5 / access denied.

I fixed it by opening an elevated Command Prompt and granting my user full control on the repo root. For me, this was enough to make the sandbox work again:

takeown /f C:\path\to\your\repo
icacls C:\path\to\your\repo /grant %USERNAME%:F

If the problem is on a whole parent folder tree rather than just one repo, run the same commands on that parent directory instead.

Any update on this? Codex is literally unusable like this

Hey, what heleped on my side is ... setting all the accesses to the workspace in windows. Just rightclick on the folder, properties and then security. In my case i've had admin and user privileges separated and when I granted it to my user (which is also an admin) codex started working.

Hey, what heleped on my side is ... setting all the accesses to the workspace in windows. Just rightclick on the folder, properties and then security. In my case i've had admin and user privileges separated and when I granted it to my user (which is also an admin) codex started working.

which folder?