Windows elevated sandbox setup helper hits os error 206 when Base64 setup payload exceeds CreateProcessW limit

What version of Codex is running?

codex-cli 0.144.1

What platform is your computer?

Microsoft Windows 11, 10.0.26200.0, x64.

What issue are you seeing?

With the elevated Windows sandbox, even a minimal sandboxed command such as Get-Location fails before the target command starts.

Sanitized error:

windows sandbox: orchestrator_helper_launch_failed: setup refresh failed to launch helper:
helper=codex-windows-sandbox-setup.exe
error=The filename or extension is too long. (os error 206)

The corresponding sanitized sandbox log entry is:

setup refresh: spawning <CODEX_INSTALL>\codex-windows-sandbox-setup.exe
(cwd=C:\Users\<USER>, payload_len=40616)

No complete sandbox log is attached because it contains private historical workspace paths. No secrets or .sandbox-secrets data are included here.

Why this appears to be an argv-size failure

Read-only local diagnostics found:

• Setup helper path length: approximately 176 characters.
• Process PATH length: approximately 3,201 characters.
• Total process environment block: approximately 6,475 characters.
• Logged Base64 setup payload length: 40,616 characters.
• The local capability ledger contained 669 path-scoped writable-root mappings. This is evidence of broad root expansion, but the ledger itself does not appear to be the direct payload input.

Microsoft documents a maximum CreateProcessW command-line length of 32,767 characters, including the terminating null:
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw

Windows error 206 is ERROR_FILENAME_EXCED_RANGE:
https://learn.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-

In the v0.144.1 source, setup refresh:

1. builds an ElevationPayload containing read/write/deny roots,
2. serializes it to JSON,
3. Base64-encodes the JSON,
4. passes the complete Base64 string as one process argument with cmd.arg(&b64).

Source:
https://github.com/openai/codex/blob/rust-v0.144.1/codex-rs/windows-sandbox-rs/src/setup.rs#L183-L250

The same source expands a user-profile root into individual top-level profile entries, which can make the setup payload very large on a long-lived development profile:
https://github.com/openai/codex/blob/rust-v0.144.1/codex-rs/windows-sandbox-rs/src/setup.rs#L383-L430

Because the logged payload alone is already 40,616 characters, this looks like a Windows command-line transport limit rather than a genuinely overlong executable or workspace path.

Steps to reproduce

1. Use Windows with an established user profile containing many top-level files/directories.
2. Configure the native Windows sandbox as elevated.
3. Start a session whose effective workspace/read-write permissions include the user-profile root (C:\Users\<USER>).
4. Run any minimal sandboxed command, such as Get-Location.
5. Observe that setup refresh fails while launching codex-windows-sandbox-setup.exe, before the requested command executes.
6. Inspect CODEX_HOME\.sandbox\sandbox.<date>.log; the failing entry reports a setup payload_len above 32,767.

Expected behavior

The setup helper payload should not depend on the Windows process command-line limit.

Possible fixes:

• transport the serialized payload through stdin, a temporary file, a named pipe, or another bounded IPC mechanism;
• reject oversized setup payloads before process creation with an actionable diagnostic;
• compact ancestor/descendant roots where that preserves the permission model;
• add a codex doctor smoke test that launches the same setup-refresh helper path used by actual sandboxed commands.

Workarounds observed

• A narrow repository CWD alone did not reduce the elevated setup payload in a controlled :workspace probe; it remained about 40.6 KB. A narrow repository root is still required with the unelevated workaround because using the complete user profile as that sandbox root produced SetTokenInformation(TokenDefaultDacl) failed: 1344.
• [windows] sandbox = "unelevated" avoids this elevated setup-helper launch path, with the documented reduction in isolation strength.

Related reports

• #31511 — false Windows error 206 under a restricted permission profile
• #17107 and #15003 — Windows argv transport causing error 206 for large patch payloads
• #24098 — elevated setup-refresh helper launch failures with a different Win32 error
• #31140 — broad user-profile workspace roots and persistent path-scoped capability mappings

I did not find an existing report combining orchestrator_helper_launch_failed, setup payload_len above 32,767, and Win32 error 206.