Why Codex Windows Sandboxes Break (and How to Fix Them)

Ethan Park

So if you're on Windows and Codex sandboxed commands have been dying before they even start, this one's for you. And thanks to Jellypod for helping make this daily show a reality. Last time we covered 0.162.1 and the Linux sandbox fixes in 0.162.0. Today is the Windows side of that same release line, and it's a case where the fix exists but stable users can't get it.

Maya

Right. The symptom is that sandboxed execution fails completely before running a single command. Codex desktop, package 26.1002.7124.0 for example, and CLI 0.162.0 and 0.162.1 all show it. The error says helper_unknown_error: setup refresh had errors. Dig into the logs and the underlying cause is os error 32, a sharing violation. That's Windows saying the process cannot access the file because it is being used by another process.

Ethan Park

The mechanism lives in the Windows sandbox crate, in a file called acl.rs. The setup helper runs a runtime read and execute validation step. Before PR #51822, it opened every root only ACL target with the same options: access mode MAXIMUM_ALLOWED, share mode read, write and delete, and the backup semantics flag. Files and directories alike.

Maya

And that's the problem, because by the time sandbox setup runs, Codex has already started its own background runtime helpers. The reports name node_repl.exe, node.exe, and codex computer use swift.exe, living under your AppData Local OpenAI Codex runtimes folder, in cua_node, then a hash, then bin. Those processes hold their executables open with only read sharing. Windows won't let you open an actively executing image with MAXIMUM_ALLOWED in that situation. One of the issue threads quotes it directly: Windows does not allow modifying the security descriptor of a file that is currently mapped as an image. So Codex's own helpers block Codex's own sandbox setup.

Ethan Park

PR #51822 is titled Avoid sharing violations when repairing Windows runtime ACLs. The change is narrow. MAXIMUM_ALLOWED is now used only on directories, behind an is_dir guard, because directories are the ones that need it to suppress child ACL inheritance. For files, it requests just READ_CONTROL and WRITE_DAC, and only when an ACL update is actually necessary. So a running executable never gets the broad open that triggers the violation.

Maya

Now the trap. That PR merged into main on October 7 at 20:47 UTC. The 0.162.0 stable line had branched from main roughly 20 hours earlier, October 7 at 00:51 UTC. So 0.162.0, tagged October 8, doesn't contain the fix. Then 0.162.1 was tagged October 9, cut from the release 0.162 maintenance branch, and it did not backport #51822. Its two fixes were the multiline TUI crash and the background server feature settings startup failure. Neither touches this.

Ethan Park

The practical result: as of the research we have, no stable release includes the fix. It's only in prerelease tags. 0.162.0 alpha 19 and alpha 20, and 0.163.0 alpha 1 through alpha 5, with alpha 5 released October 10. That's from the issue tracker, so check the releases page for anything newer before you act.

Maya

Here's how to tell whether your build has the fix, because version numbers alone won't do it. Open the sandbox log, at tilde slash dot codex slash dot sandbox, a file named sandbox, then the date, dot log. PR #51822 renamed the error string. Builds before the fix log: open ACL target for root only update, with a colon after it. Builds with the fix log: open ACL target for root only update, followed by MAXIMUM_ALLOWED in parentheses. If you don't see that parenthesized suffix, your build lacks #51822, whether it says 0.162.0 or 0.162.1.

Ethan Park

Now workarounds, in order of how much they cost you. First, switch from sandboxed mode, the ask for approval setup, to Full Access in the app. Full Access skips sandbox provisioning, so the setup helper never runs and commands go through. But understand what you're trading. You've turned off sandbox isolation, so only do that in a repo and on a machine where you're comfortable with it.

Maya

Second, if you need the sandbox, run a prerelease that has the fix. Install it globally with npm, the package is openai slash codex at the alpha tag, or pin 0.163.0 alpha 5 specifically. One thing that does not work: killing node_repl.exe. Codex respawns those processes as soon as you run a task, so you'll clear the lock for a moment and it will come right back.

Ethan Park

And a caveat on the prerelease path. If you land on 0.163.0 alpha 1, there's issue #52313. PR #52195 added per content source attribution, which sends content_item_metadata in request payloads. With GPT 6.1 Sol, where use_responses_lite is true, the Responses Lite backend rejects that parameter with an HTTP 400 invalid_request_error. The reported workaround is to pass the disable flag for the content_item_kinds feature. Alphas are alphas, so test before you roll one out to a team.

Maya

A couple of smaller things from 0.162.0 worth knowing while you're in there. In Code Mode, there are now JavaScript helpers for streaming promise results as they settle, so you aren't waiting on the slowest call before you see the rest. There's also opt in ranked tool search in Code Mode, from PRs #51126 and #51209.

Ethan Park

And for custom model providers, PR #50459 adds capability overrides in config. You can now configure live web access and remote context compaction for custom Responses compatible endpoints, rather than having those assumed off.

Maya

So the takeaway: if your Windows sandbox is failing, check the log string before blaming your setup. No parenthesized MAXIMUM_ALLOWED means no fix. Use Full Access if you must, move to an alpha if you need isolation, and watch for a 0.162.2 or a 0.163 stable that actually carries #51822.