›_ Codex Issues
Codex Issues / #39251

Windows sandbox recovery fails: codex-windows-sandbox-setup.exe exits with 0xc0000142 after DPAPI error

Open 💬 2 comments Opened Aug 18, 2026 by Abreuzin05

What version of the Codex App are you using (From “About Codex” dialog)?

Versão atual: 26.813.12317

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The Codex Windows native sandbox can no longer start any local command.

Every command fails before PowerShell or any child process starts:

windows sandbox: CryptUnprotectData failed: 2148073483

The error corresponds to 0x8009000B (NTE_BAD_KEY_STATE).

Current-user DPAPI encryption and decryption work correctly. The failure appears to be specific to the Codex sandbox credentials.

As a recovery test, with Codex completely closed, I renamed:

%USERPROFILE%\.codex\.sandbox-secrets

to .sandbox-secrets-backup.

After reopening Codex, sandbox recreation also failed with:

codex-windows-sandbox-setup.exe - Application Error
The application was unable to start correctly (0xc0000142).

Restoring the original directory returns Codex to the original CryptUnprotectData failure.

Related issue: #35841

What steps can reproduce the bug?

  1. Open Codex on Windows using the native Windows sandbox.
  2. Open any local project.
  3. Ask Codex to run Get-Location.
  4. Observe CryptUnprotectData failed: 2148073483.
  5. Close Codex completely.
  6. Rename %USERPROFILE%\.codex\.sandbox-secrets to .sandbox-secrets-backup.
  7. Reopen Codex.
  8. Observe that codex-windows-sandbox-setup.exe fails with 0xc0000142.

<img width="1105" height="764" alt="Image" src="https://github.com/user-attachments/assets/24aee865-1244-4882-8449-8e814d846732" />

What is the expected behavior?

If the stored sandbox credentials cannot be decrypted, Codex should safely regenerate its sandbox credentials. The sandbox setup executable should start successfully, and local commands should execute normally.

Additional information

I can reproduce the same CryptUnprotectData failed: 2148073483 error.

I also observed a failure in the recovery path. With Codex completely closed, I temporarily renamed:

%USERPROFILE%\.codex\.sandbox-secrets

After reopening Codex, sandbox recreation failed with:

codex-windows-sandbox-setup.exe - Application Error
The application was unable to start correctly (0xc0000142).

Restoring the original .sandbox-secrets directory returns Codex to the original DPAPI failure.

Troubleshooting performed:

  • Restarted Windows
  • Reset and reinstalled the app
  • Recreated the runtime cache
  • Restored an older config.toml
  • Confirmed that current-user DPAPI encryption/decryption works

View original on GitHub ↗

2 Comments

rocky2005 · 8 days ago

please fix

krukovis-spec · 2 days ago

Reproduced on codex-cli 0.149.1 (fresh download of codex-x86_64-pc-windows-msvc.exe from the rust-v0.149.1 GitHub release, replacing a 0.144.1 install). This confirms the root DPAPI failure is not version-specific:

  • codex sandbox windows --permissions-profile ":read-only" --cd $env:TEMP -- C:\Windows\System32\whoami.exe fails with the same CryptUnprotectData failed: 2148073483 both before and after updating the CLI.
  • Verified general machine-scope DPAPI is healthy independent of Codex: an in-memory [System.Security.Cryptography.ProtectedData]::Protect(...,LocalMachine) → Unprotect(...,LocalMachine) round-trip via PowerShell succeeds fine on the same machine. So this isn't a broken DPAPI/CNG install — the stored sandbox credential blob specifically can't be decrypted anymore.
  • Verified the recovery attempt was run from a genuinely elevated shell (window title Administrator:, (New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent())).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator) returned True) — so it isn't a missing-elevation issue either.
  • Reproduced the same secondary failure as OP when attempting recovery: renaming .sandbox, .sandbox-secrets, and .sandbox-bin (not just .sandbox-secrets) and re-running codex sandbox windows ... does not self-heal — it fails differently, with orchestrator_helper_launch_failed: failed to launch setup helper (non-elevated): program not found. Restoring the renamed directories from backup returns to the original CryptUnprotectData error, confirming the recovery path itself is broken rather than the credential being simply corrupted in a way a fresh setup could fix.

Environment: Windows 11 Pro 10.0.26200, single portable-binary install at ~/.codex/bin/codex.exe (not the multi-release packages/standalone layout).

Would be good to know whether the team has a repro for the orchestrator_helper_launch_failed recovery-path failure specifically — it currently blocks the only documented recovery path for this bug.