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

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #31511

Powered by Codex Action

Follow-up: controlled elevated/unelevated comparison

I ran the same minimal Get-Location probe using the built-in :workspace permission profile.

Results:

• elevated, user-profile CWD: failed with error 206, payload_len=40640.
• elevated, process CWD changed to a narrow repository: still failed with error 206, payload_len=40668.
• unelevated, narrow repository A: succeeded, exit 0.
• unelevated, associated worktree B: succeeded, exit 0.
• The two successful unelevated probes created 0 new setup-helper spawns and 0 new error-206 entries.
• unelevated, complete user-profile root: failed with the distinct error SetTokenInformation(TokenDefaultDacl) failed: 1344.

Correction to the initial report: changing only the CWD to a narrow repository is not sufficient to shrink the elevated setup payload. Based on gather_full_read_roots_for_permissions, the :workspace full-disk-readable shape appears to continue adding top-level profile entries independently of the repository CWD.

The narrow repository root remains important for the unelevated workaround because applying the permission/token model to the entire user profile hits the separate 1344 boundary.

The local mitigation was therefore:

[windows]
sandbox = "unelevated"

plus reopening work from an exact repository/worktree root rather than the complete user profile. codex doctor --json remains overall OK, and both repository probes pass.

Reproduced on codex-cli 0.146.0 / windows-x86_64 on 2026-08-05.

Minimal direct repro:

codex sandbox -P :read-only -C C:\Users\<USER>\Documents\harbor -- bash -lc "command -v harbor"

Result:

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

The sandbox log records payload_len=38240. The same 38,240-byte payload failed with both the npm-distribution helper path and the shorter Codex app helper path, so shortening the helper path does not address this reproduction.

Additional diagnostics:

• [windows] sandbox = "elevated" (the documented recommended mode).
• codex doctor --summary --no-color --ascii reports 17 ok | 1 idle | 0 warn | 0 fail and says the sandbox is healthy, despite the direct sandbox command failing immediately.
• codex exec --ignore-user-config avoided this setup-helper failure, which suggests the expanded configured capability/read-root state contributes to the oversized payload.
• --dangerously-bypass-approvals-and-sandbox allowed the same read-only agent workload to complete, confirming the workload and target executable were otherwise healthy.
• The documented windows.sandbox="unelevated" fallback did not provide a viable workaround here: even direct whoami.exe and harbor.exe search-status probes exited 127 without output.

This supports the proposed fixes in the issue: transport setup state via stdin/temp file rather than argv, and make codex doctor execute the real setup-refresh path and fail when it cannot launch.

Reproduced on codex-cli 0.145.0 and 0.144.1, Windows 11 Pro 26100.

I think I can pin down the payload input, which the original report left open ("the ledger itself does not appear to be the direct payload input").

The payload scales with the number of top-level entries in the home directory

Decisive test — point USERPROFILE at an empty directory and re-run the same command:

| condition | payload_len |
|---|---|
| home with 725 top-level entries | 33,232 |
| USERPROFILE → empty directory | 756 |

A 32,476-byte difference attributable solely to home-directory contents. Empirically each top-level entry costs roughly 46 bytes of the fixed 32,767 CreateProcessW budget, so the ceiling is hit at roughly 700 entries regardless of what those entries are.

Ruled out

Each tested individually, none made a meaningful difference:

• config.toml — removed the file entirely; payload_len unchanged at 33,232.
• Process PATH — trimmed 2,048 → 110 chars; unchanged.
• Registry environment — HKCU\Environment + system env total ~3.4 KB.
• Elevation — elevated gives the same 206, and the log then reads failed to launch setup helper (non-elevated), i.e. the elevated path falls through to the same oversized spawn. (Matches @Faust7777777's elevated/unelevated comparison.)
• CLI version — 0.144.1 → 33,092, 0.145.0 → 33,232. ~140 bytes apart, both over. Not a regression between releases; it is a function of the user's filesystem.
• setup_marker.json — moving it aside changes the failure to ShellExecuteExW ... 1223 (UAC auto-declined under automation) but never resolves the 206.

Workaround that actually works

Reduce the top-level entry count in the home directory. I deleted 61 empty leftover directories (abandoned git worktree stubs), taking the count 725 → 664, and Codex recovered immediately on the same CLI version that had been failing seconds earlier. No reinstall, no config change, no elevation.

This also explains the "worked yesterday, broken today" pattern: the home directory silently crosses the threshold and every invocation fails at once, in every repo.

Two suggestions

1. Move the payload off the command line — a temp file, pipe, or stdin removes the ceiling entirely.
2. If it must stay, check its length before spawning and say so. Something like "sandbox setup payload is 33,232 bytes, exceeding the Windows 32,767 command-line limit; home directory has 725 top-level entries" would turn this into a one-line fix for the user. As it stands the message names the helper's path (172 chars, perfectly valid), so it points at the wrong thing entirely — I ruled out four unrelated causes before finding the real one.

I can independently reproduce this issue on a Windows development workstation, and in my case the setup payload is significantly larger than the original report.

Independent reproduction: ~347K setup payload

Environment:

• Windows native Codex environment
• Elevated Windows sandbox
• Long-lived development workstation/user profile
• Failure occurs during sandbox setup, before the requested command is executed

Observed failure:

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

The important part is the measured payload size:

Observed formal setup payload_len:

:read-only   ~347,152 characters
:workspace   ~347,168 characters

This is not marginally above the Windows CreateProcessW command-line limit. It is approximately 10× the 32,767-character limit.

Local root-cause evidence

I investigated what was expanding the payload.

The Windows user profile contained approximately:

C:\Users\<USER> top-level entries: ~2,728

Of those, approximately:

~2,666 entries were SQL Server test database MDF/LDF files

Read-only diagnostics showed approximately:

profile JSON path data:       ~251,440 bytes
Base64 contribution:          ~335,256 characters
simulated setup payload:      ~346,892 characters

observed actual payload_len:
  :read-only                  ~347,152
  :workspace                  ~347,168

The simulated size and the actual Codex sandbox log payload size are therefore extremely close.

This strongly supports the analysis in this issue: expansion of the user-profile root into many top-level entries can massively amplify ElevationPayload, after which JSON + Base64 encoding makes the payload too large to transport through a single process argument.

This is not a repository path-length problem

In this environment:

• Shortening the repository path does not solve the underlying issue.
• Enabling Windows Long Paths does not solve it.
• git core.longpaths is unrelated.
• Reinstalling Codex does not address the payload transport mechanism.
• Running as Administrator does not remove the CreateProcessW command-line limit.

The failure occurs while launching:

codex-windows-sandbox-setup.exe

before the requested PowerShell/process command actually executes.

Operational impact

This is more than an unusual path-length edge case.

On a long-lived Windows development workstation, the user profile can naturally accumulate a large number of top-level entries. If Codex expands those entries into the sandbox setup payload, payload size becomes dependent on unrelated contents of the developer's Windows profile.

In our case, this makes the elevated Windows sandbox effectively unusable, including for automated AI coding/orchestration workflows that require strong filesystem/network isolation.

The available workaround of moving away from the elevated sandbox means accepting weaker isolation, which is not an acceptable long-term solution for security-sensitive automated development workflows.

Suggested architectural fix

I agree with the proposed fixes in the original report.

The serialized ElevationPayload should ideally not be transported as a single argv value.

For example:

1. stdin — likely the simplest option;
2. temporary file with restricted ACL and lifecycle cleanup;
3. named pipe / other IPC mechanism;
4. additionally compact redundant ancestor/descendant root entries before serialization.

I would also recommend adding a deterministic regression test where the serialized setup payload is deliberately larger than 32,767 characters.

For example:

ElevationPayload
    -> JSON
    -> payload > 32,767 chars
    -> launch setup helper
    -> helper successfully receives payload

That would prevent this class of Windows argv-size regression from returning.

Why I think this deserves priority

The original report demonstrated failure at:

payload_len = 40,616

This independent reproduction reaches approximately:

payload_len = 347,168

So this does not appear to be a narrow boundary condition.

The current architecture allows the setup payload to grow far beyond the Windows process command-line limit based on the contents of an established developer profile.

For teams using Codex on native Windows with elevated sandboxing as part of automated coding workflows, this can become a complete blocker rather than an intermittent failure.

I can provide additional sanitized diagnostics or run a targeted test against a candidate fix if that would help.

I can independently reproduce this issue on a Windows development workstation, and in my case the setup payload is significantly larger than the original report.

Independent reproduction: ~347K setup payload

Environment:

• Windows native Codex environment
• Elevated Windows sandbox
• Long-lived development workstation/user profile
• Failure occurs during sandbox setup, before the requested command is executed

Observed failure:

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

The important part is the measured payload size:

Observed formal setup payload_len:

:read-only   ~347,152 characters
:workspace   ~347,168 characters

This is not marginally above the Windows CreateProcessW command-line limit. It is approximately 10× the 32,767-character limit.

Local root-cause evidence

I investigated what was expanding the payload.

The Windows user profile contained approximately:

C:\Users\<USER> top-level entries: ~2,728

Of those, approximately:

~2,666 entries were SQL Server test database MDF/LDF files

Read-only diagnostics showed approximately:

profile JSON path data:       ~251,440 bytes
Base64 contribution:          ~335,256 characters
simulated setup payload:      ~346,892 characters

observed actual payload_len:
  :read-only                  ~347,152
  :workspace                  ~347,168

The simulated size and the actual Codex sandbox log payload size are therefore extremely close.

This strongly supports the analysis in this issue: expansion of the user-profile root into many top-level entries can massively amplify ElevationPayload, after which JSON + Base64 encoding makes the payload too large to transport through a single process argument.

This is not a repository path-length problem

In this environment:

• Shortening the repository path does not solve the underlying issue.
• Enabling Windows Long Paths does not solve it.
• git core.longpaths is unrelated.
• Reinstalling Codex does not address the payload transport mechanism.
• Running as Administrator does not remove the CreateProcessW command-line limit.

The failure occurs while launching:

codex-windows-sandbox-setup.exe

before the requested PowerShell/process command actually executes.

Operational impact

This is more than an unusual path-length edge case.

On a long-lived Windows development workstation, the user profile can naturally accumulate a large number of top-level entries. If Codex expands those entries into the sandbox setup payload, payload size becomes dependent on unrelated contents of the developer's Windows profile.

In our case, this makes the elevated Windows sandbox effectively unusable, including for automated AI coding/orchestration workflows that require strong filesystem/network isolation.

The available workaround of moving away from the elevated sandbox means accepting weaker isolation, which is not an acceptable long-term solution for security-sensitive automated development workflows.

Suggested architectural fix

I agree with the proposed fixes in the original report.

The serialized ElevationPayload should ideally not be transported as a single argv value.

For example:

1. stdin — likely the simplest option;
2. temporary file with restricted ACL and lifecycle cleanup;
3. named pipe / other IPC mechanism;
4. additionally compact redundant ancestor/descendant root entries before serialization.

I would also recommend adding a deterministic regression test where the serialized setup payload is deliberately larger than 32,767 characters.

For example:

ElevationPayload
    -> JSON
    -> payload > 32,767 chars
    -> launch setup helper
    -> helper successfully receives payload

That would prevent this class of Windows argv-size regression from returning.

Why I think this deserves priority

The original report demonstrated failure at:

payload_len = 40,616

This independent reproduction reaches approximately:

payload_len = 347,168

So this does not appear to be a narrow boundary condition.

The current architecture allows the setup payload to grow far beyond the Windows process command-line limit based on the contents of an established developer profile.

For teams using Codex on native Windows with elevated sandboxing as part of automated coding workflows, this can become a complete blocker rather than an intermittent failure.

I can provide additional sanitized diagnostics or run a targeted test against a candidate fix if that would help.

Additional real-world impact from the same machine:

This issue now blocks even basic Git maintenance workflows in Codex.

I asked Codex to fast-forward a completed feature branch into local main. Before it could execute git status, git merge-base, or git merge --ff-only, the Windows sandbox helper failed with:

orchestrator_helper_launch_failed
os error 206

I restarted/retried the Codex workflow and received the same failure again, still before PowerShell launched.

So this is not limited to unusual sandbox setup operations. Once the payload reaches this size, Codex cannot execute even trivial shell commands required for normal repository operations.

The practical result is that native Windows Codex becomes unable to complete ordinary development tasks such as status checks, commit verification, or local fast-forward merges, unless the user manually leaves Codex and runs the commands outside the sandbox.

This significantly increases the priority from my perspective because the bug can completely disable normal Codex CLI/App workflows on an established Windows development workstation.