Windows workspace-write sandbox still broken in 0.116.0 after state reset; bypass mode works
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, andstate_5.sqlite - retrying with and without
experimental_windows_sandbox = true
The same machine can:
- run plain
codex execsuccessfully - run
codex exec --dangerously-bypass-approvals-and-sandboxsuccessfully 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?
- On native Windows 11, create a fresh scratch repo:
mkdir <scratch> && cd <scratch> && git init
- Confirm plain exec works:
codex exec --json --color never "Reply with one word: ok"
- 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"
- Observe failure / no file created
- 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"
- 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.txtwas not created. - Bypass write succeeded;
bypass.txtwas created with exact bytes. - Removing
[windows] sandbox = "elevated"and clearing Codex sandbox state did not fix it. - Enabling
experimental_windows_sandbox = truedid 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.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗