How to Fix Codex Windows Sandbox Errors Safely

If Codex on Windows reports CreateProcessAsUserW failed, spawn EPERM, repeated sandbox setup, or unusually slow tool calls, do not disable the sandbox first. Classify the failure by comparing the elevated and unelevated sandbox modes in a clean local folder, inspect the sandbox log, then repair the setup or isolate the path boundary that fails.

This guide gives you a reproducible diagnosis before you change permissions. It applies to the native Codex Windows sandbox, including the Codex app, CLI, and VS Code workflows that use it.

Symptoms this guide covers

Use this workflow when you see one or more of these symptoms:

• CreateProcessAsUserW failed or sandbox setup refresh failures

• EPERM when Codex calls Node.js, apply_patch, or another child process

• apply_patch can create a file but cannot update an existing file

• Every shell command takes 15 to 60 seconds even when the command is trivial

• Codex repeatedly runs codex-windows-sandbox-setup.exe

• The same task works with full access but fails in the Windows sandbox

These symptoms can have different causes. A single workaround will not safely fix all of them.

Prerequisites

Before testing, save any work in progress and open PowerShell as your normal Windows user. You need:

• A current Codex app or CLI installation

• A local NTFS folder under your user profile

• Permission to run the official Codex sandbox setup command if repair is needed

Record the installed command and version:

codex --version
Get-Command codex | Select-Object Source

If Get-Command points to an older installation than the one you expected, update or remove the duplicate before continuing. The current official Windows installer command is:

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

Step 1: Reproduce the error in a clean local folder

Synced folders, network shares, multiple drives, and inherited ACLs can obscure the real boundary. Create a small local test folder first:

$diag = Join-Path $env:USERPROFILE "CodexSandboxDiag"
New-Item -ItemType Directory -Force $diag | Out-Null
Set-Location $diag
"sandbox test" | Set-Content input.txt

Start a new Codex task in that folder and ask it to read input.txt, edit the text, and run Get-Content input.txt. Record which operation fails and the exact error.

Expected result: Codex reads, edits, and prints the file without requesting full access. If the clean folder works, reproduce the same operations in the original workspace and compare the paths, drives, and inherited permissions.

Step 2: Compare elevated and unelevated sandbox probes

Codex exposes a direct Windows sandbox probe. Run the same harmless command in each mode:

$cmd = "$env:WINDIR\System32\cmd.exe"
codex -c 'windows.sandbox="elevated"' sandbox windows $cmd /c echo CODEX_ELEVATED_OK
codex -c 'windows.sandbox="unelevated"' sandbox windows $cmd /c echo CODEX_UNELEVATED_OK

You should see CODEX_ELEVATED_OK and CODEX_UNELEVATED_OK. Time both probes if slowness is the problem.

The comparison is a diagnostic. It does not prove that one mode is universally safer or compatible with every project layout.

Step 3: Inspect the sandbox state without deleting it

Ask Codex for its diagnostic summary, then inspect the end of the sandbox log:

codex doctor --summary
Get-Content "$env:USERPROFILE\.codex\.sandbox\sandbox.log" -Tail 80

Look for the first failure, not only the final retry. Preserve:

• Codex version and installation path

• Whether elevated, unelevated, or both modes failed

• The command that failed and its exit code

• Whether the path was local, synced, networked, or on another drive

• Whether the failure happened before the shell started, during a child process, or during a file update

Sanitize usernames, repository names, and file contents before sharing a log publicly.

Step 4: Apply the smallest matching repair

Repair a failed or stale sandbox setup

Update Codex, close every Codex process, and run the signed setup path:

codex sandbox setup --elevated --current-user

Then restart Codex and repeat both marker probes. A successful setup command is not enough by itself; verify that the original read, edit, and child-process operations now work.

Isolate a split-root or path-specific apply_patch failure

If Codex can create files but cannot patch existing files, compare these locations one at a time:

1. A new folder under %USERPROFILE%

2. The repository root

3. The operating system temporary directory

4. Any additional writable root or second drive used by the task

Keep the test file content identical. If only a multi-root or nonlocal layout fails, reduce the issue to those two paths instead of changing ACLs across the machine. Current Codex issue reports show that split writable roots can produce failures that a single-root smoke test misses.

Isolate child-process EPERM

If PowerShell commands work but Node.js spawn, test runners, or patch helpers fail, record the smallest child process that reproduces it. For example, ask Codex to run node -e "console.log('child-ok')" in the clean folder and the original workspace.

If the clean local case succeeds, the problem is more likely the workspace boundary than the Node executable. If both fail, include the executable path and sandbox mode in the report.

Report a reproducible regression

Search the open Codex issues for the exact error before filing a new one. A useful report contains the version, mode comparison, timings, minimal paths, diagnostic output, and sanitized log excerpt. Link related issues rather than splitting the same reproduction across multiple reports.

Unsafe fixes to avoid

Avoid fixes that remove the protection without explaining the boundary:

• Leaving Codex in full-access mode for routine work

• Granting broad ACL access to a drive or user profile

• Deleting .codex\.sandbox before preserving diagnostics

• Using RUNASINVOKER or shell rewrites to bypass the runner

• Replacing apply_patch with an unrestricted shell write as a permanent workaround

• Pinning an old Codex version without checking release notes and retesting the current version

A one-off full-access comparison can confirm that the sandbox is involved, but it is not a safe repair.

Why this diagnosis works

The native Codex sandbox does more than start a subprocess. OpenAI's Windows sandbox design uses restricted security identities and filesystem access-control entries to limit what an agent command can read or change. A setup helper prepares those identities and permissions, while a command runner launches work inside the selected boundary.

That design explains why the failure stage matters. An error before the shell starts points toward setup or process creation. A delayed elevated launch can point toward permission preparation. A child-process or existing-file failure after a basic command succeeds can expose a narrower executable or writable-root boundary. Comparing controlled probes changes one variable at a time.

After the sandbox is healthy, connect one tool safely

Once the local read-edit-run test passes inside the sandbox, you can verify that Codex also reaches an external tool without copying a provider secret into the repository.

Give Codex this instruction:

Follow https://aident.ai/SETUP.md

Then ask it to search for one connected capability and run a harmless read-only action. The measurable success condition is one completed read-only action with no provider API key pasted into the task, shell history, or project files.

For a smaller tool context, see how to reduce MCP token usage in Claude Code and Codex. For deployment choices, compare local and remote MCP servers. To connect both coding agents to real services, use the Claude Code and Codex integration guide.

Sources

• Building the Codex Windows sandbox, OpenAI, May 13, 2026

• Codex repository and Windows installation instructions, OpenAI, accessed July 24, 2026

• Elevated sandbox adds about 20 seconds per command, OpenAI Codex issue, opened July 11, 2026

• Split writable roots can break apply_patch, OpenAI Codex issue, opened June 30, 2026

• apply_patch existing-file failure in the VS Code extension, OpenAI Codex issue, opened July 12, 2026

• CreateProcessAsUserW and setup refresh errors, OpenAI Codex issue, opened May 13, 2026

This article reflects the native Windows sandbox behavior and open reports available on July 24, 2026. Recheck the current Codex release and linked issues if the setup commands or sandbox modes change.