Windows workspace-write sandbox still broken in 0.116.0 after state reset; bypass mode works

Resolved 💬 1 comment Opened Mar 26, 2026 by kirkbensemann Closed Mar 26, 2026

What version of Codex CLI is running?

codex-cli 0.116.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.4

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What terminal emulator and version are you using (if applicable)?

PowerShell 5.1 via local shell / OpenClaw exec host

What issue are you seeing?

On native Windows, codex exec --sandbox workspace-write is still broken on a fresh scratch repo even after:

  • upgrading Codex CLI from 0.111.0 to 0.116.0
  • removing [windows] sandbox = "elevated" from ~/.codex/config.toml
  • deleting ~/.codex/.sandbox, .sandbox-bin, .sandbox-secrets, cap_sid, and state_5.sqlite
  • retrying with and without experimental_windows_sandbox = true

The same machine can:

  • run plain codex exec successfully
  • run codex exec --dangerously-bypass-approvals-and-sandbox successfully and create files

But sandboxed workspace-write runs fail before usable work completes. I observed both:

  • windows sandbox: CreateProcessWithLogonW failed: 1056
  • command executions exiting -1073741502 / 0xC0000142

This reproduces in a fresh git repo under OneDrive-backed user workspace.

What steps can reproduce the bug?

  1. On native Windows 11, create a fresh scratch repo:
  • mkdir <scratch> && cd <scratch> && git init
  1. Confirm plain exec works:
  • codex exec --json --color never "Reply with one word: ok"
  1. Run sandboxed write:
  • codex exec --json --color never --sandbox workspace-write --skip-git-repo-check "Create a file named fixed.txt containing exactly: sandbox ok"
  1. Observe failure / no file created
  2. Run bypassed write in same repo:
  • codex exec --json --color never --dangerously-bypass-approvals-and-sandbox "Create a file named bypass.txt containing exactly: bypass ok"
  1. Observe success / file created

What is the expected behavior?

--sandbox workspace-write should be able to create files in a fresh scratch repo on Windows, especially when bypass mode succeeds in the same repo.

Additional information

Direct evidence from this machine:

  • Plain exec succeeded.
  • Sandboxed write failed; fixed.txt was not created.
  • Bypass write succeeded; bypass.txt was created with exact bytes.
  • Removing [windows] sandbox = "elevated" and clearing Codex sandbox state did not fix it.
  • Enabling experimental_windows_sandbox = true did not fix it.

This looks like the Windows sandbox/runtime path is still unstable in 0.116.0, separate from OpenClaw. OpenClaw was already updated and its old built-in read-only sandbox bug is not involved.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗