›_ Codex Issues
Codex Issues / #34928

Windows sandbox setup helper fails with 0xc0000142 only when launched by Codex

Open 💬 3 comments Opened Jul 23, 2026 by aimayu
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

Codex App 26.716.1735.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows 11 Pro

What issue are you seeing?

The UAC flow works, but codex-windows-sandbox-setup.exe fails immediately with:

0xc0000142

Windows Event Viewer confirms:

Source: Application Popup
Event ID: 26
Application: codex-windows-sandbox-setup.exe
Error: 0xc0000142

What steps can reproduce the bug?

  1. Install and launch the Codex/ChatGPT desktop app on Windows 11 Pro.
  2. Sign in normally.
  3. Proceed to "Finish Windows setup".
  4. Click the button to complete Windows setup.
  5. The UAC prompt appears normally.
  6. Enter/confirm administrator credentials.
  7. Immediately after elevation, Windows shows:

codex-windows-sandbox-setup.exe - Application Error

The application was unable to start correctly (0xc0000142).

  1. The Windows setup does not complete.

What is the expected behavior?

After approving the UAC prompt, codex-windows-sandbox-setup.exe should complete the Windows sandbox setup and the Codex desktop app should start normally.

Additional information

I performed additional diagnostics to isolate the problem.

Environment:

  • Windows 11 Pro
  • Domain-joined corporate PC
  • Normal user account: synergy\mrevunov
  • Administrator account used for UAC: synergy\esim

The helper exists at:

C:\Users\mrevunov\AppData\Local\OpenAI\Codex\bin\e2d6a5ee2cac801c\codex-windows-sandbox-setup.exe

Authenticode signature is valid and signed by OpenAI OpCo, LLC.

The helper itself works when launched manually.

Direct launch as the normal user:

codex-windows-sandbox-setup.exe

Result:

Error: helper_request_args_failed: expected payload argument
ExitCode = 1

This is expected because no setup payload was supplied.

The helper also works when elevated manually through UAC:

Start-Process -FilePath $helper -Verb RunAs -PassThru -Wait

Result:

ExitCode = 1

It also launches successfully from an elevated PowerShell session running under the same administrator account (synergy\esim) used during the Codex UAC flow.

Therefore:

  • helper executable itself launches correctly
  • Authenticode signature is valid
  • direct execution works
  • execution under the administrator account works
  • normal UAC / RunAs elevation works
  • AppLocker logs contain no relevant events
  • Code Integrity logs contain no relevant events

However, when Codex launches the same helper during the actual Windows sandbox setup flow, the process fails with 0xc0000142.

This suggests that the failure is specific to the way Codex invokes codex-windows-sandbox-setup.exe during windowsSandbox/setupStart — possibly the setup payload, process environment, working directory, or elevation launch mechanism.

Reinstalling the desktop application did not resolve the issue.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

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

  • #34329

Powered by Codex Action

mmandelberg · 5 days ago
  • Codex App 26.818.5229.0, Windows 11 Pro, Plus.
  • Normal account is non-admin; separate local admin credentials supplied at UAC.
  • Same 0xc0000142 immediately after UAC.
  • Setup works when actually logged into the admin account.
  • Unelevated setup-refresh helper runs successfully and logs errors=[], then reports sandbox users missing or incompatible with marker version.
  • Copying the packaged setup EXE to %TEMP% allows it to launch elevated and exit normally with code 1 because no payload was supplied.
  • Elevating the original packaged EXE directly from C:\Program Files\WindowsApps\... instead gives Access is denied.
  • icacls shows BUILTIN\Users already has read/execute rights.
  • Current Work UI is hard-blocked: “Update Agent sandbox to continue.”
  • OpenAI support case has already been escalated.

<img width="395" height="161" alt="Image" src="https://github.com/user-attachments/assets/9a054859-af77-4833-93e5-9114671f5fc3" />

Mr-B-1 · 3 days ago

I reproduced this on a newer Codex Desktop package, and a full Desktop restart did not make the recovery durable.

| Field | Local evidence |
|---|---|
| Codex Desktop package | OpenAI.Codex_26.818.5229.0_arm64__2p2nqsd0c76g0 |
| Host architecture | Windows ARM64 |
| Workspace | C:\workspace |
| Sandbox policy | workspace-write with Windows sandbox elevated |
| Root trust | No trusted C:\ project entry; C:\workspace remains trusted |
| Packaged setup helper SHA-256 | e9ba1707848c0f37a344792e2d0a8d48e2e138021b565de1549dd644c9178eb5 |
| Packaged helper signature | Valid OpenAI OpCo, LLC Authenticode signature |

| Observation | Result |
|---|---|
| Exact August 24 loader exits | 55 instances of ExitStatus(3221225794), equivalent to 0xC0000142 |
| Post-restart recurrence | Seven exact exits from 15:08:02.215 through 15:12:33.089 PST |
| First subsequent success | 15:13:49.595 PST, errors=[], without a configuration change |
| Failure boundary | The packaged codex-windows-sandbox-setup.exe exits before cmd.exe, Git Bash, or PowerShell launches |
| Intermittency | The same signed packaged helper later completed repeated setup refreshes |

After recovery, the normal Desktop task passed 25/25 serial and 12/12 concurrent command starts in elevated mode. A separate codex-cli 0.145.0 installation passed 25/25 serial and 12/12 concurrent direct sandbox starts in both elevated and unelevated modes, but it uses a different npm-installed setup helper with SHA-256 07c8db7ed5f036f8e70dc8dc10278283350ec6ffcf5849c86eb446097aec282e. That comparison therefore does not clear the Desktop package path. Unelevated mode is also not a complete workaround locally because Git Bash terminates with CreateFileMapping ... Win32 error 5, while the same Git Bash command passes in elevated mode.

I also see separate setup status 1 failures when applying a deny ACE to C:\workspace\D\.git. Those are classified separately and are not included in the 55 loader exits above.

Could you confirm whether the Desktop helper should be materialized outside the WindowsApps package directory before launch, whether additional loader telemetry can be enabled safely, and which fixed build should be used for an elevated-mode acceptance test?