Windows sandboxed shell commands fail with CreateRestrictedToken failed: 87 even with [windows] sandbox = "unelevated"
What version of Codex CLI is running?
codex-cli 0.119.0-alpha.28
Also reproduced earlier on codex-cli 0.122.0-alpha.1 before downgrading the VS Code extension bundle.
What subscription do you have?
Using the Codex CLI bundled with the VS Code ChatGPT/Codex extension on a logged-in ChatGPT account. Exact subscription tier is not surfaced clearly in the CLI environment.
Which model were you using?
Default model from the current Codex setup; not explicitly overridden for this repro.
What platform is your computer?
Microsoft Windows NT 10.0.22631.0 x64
What terminal emulator and version are you using (if applicable)?
PowerShell 7.6.0, launched from a normal non-admin Windows session. No tmux/screen/zellij. The codex binary comes from the VS Code extension bundle.
What issue are you seeing?
Any nested codex exec run that tries to execute even a trivial PowerShell command inside the Windows sandbox fails with:
windows sandbox: CreateRestrictedToken failed: 87
This reproduces with both:
--sandbox workspace-write--sandbox read-only
It also reproduces when Windows sandbox mode is explicitly configured as:
[windows]
sandbox = "unelevated"
and also when that setting is passed explicitly via:
-c 'windows.sandbox="unelevated"'
The agent may still continue and produce a text answer, but any shell-backed local file reading/editing path is effectively broken because the command execution step fails first.
Example stderr / JSONL output from the repro:
{"type":"item.completed","item":{"id":"item_0","type":"command_execution","command":"\"C:\\Program Files\\PowerShell\\7\\pwsh.exe\" -Command Get-Location","aggregated_output":"execution error: Io(Custom { kind: Other, error: \"windows sandbox: CreateRestrictedToken failed: 87\" })","exit_code":-1,"status":"failed"}}
2026-04-18T02:36:55.597122Z ERROR codex_core::exec: exec error: windows sandbox: CreateRestrictedToken failed: 87
2026-04-18T02:36:55.600440Z ERROR codex_core::tools::router: error=execution error: Io(Custom { kind: Other, error: "windows sandbox: CreateRestrictedToken failed: 87" })
Related context:
- current
codexpath after downgrade: c:\Users\chenpeng\.vscode\extensions\openai.chatgpt-26.409.20454-win32-x64\bin\windows-x86_64\codex.exe- current session is not elevated / not running as Administrator
- the repro is repo-independent and does not rely on any project-specific scripts
What steps can reproduce the bug?
- On Windows 11, use the Codex CLI bundled with the VS Code extension.
- Ensure the session is a normal non-admin PowerShell session.
- Set Windows sandbox mode to
unelevatedin config:
``toml``
[windows]
sandbox = "unelevated"
- Run the following minimal repro:
``powershell``
@'
Run exactly one shell command: Get-Location
Then answer with only the resulting path.
'@ | codex -a never -c 'windows.sandbox="unelevated"' exec --sandbox workspace-write --skip-git-repo-check --ephemeral --color never --json -C D:\chenpeng\Documents\coding\skills-development -
- Observe that the nested shell command fails with:
``text``
windows sandbox: CreateRestrictedToken failed: 87
- Repeat with
--sandbox read-only; the same error still occurs.
Observed thread ids from minimal repros:
019d9e72-ae2e-7ca0-b017-92efdc5aace6on0.119.0-alpha.28019d9e73-2e64-7833-b1c9-9e13e47c82a0on0.119.0-alpha.28(read-only)019d9e6e-713c-7992-beb5-a260b049ea69on0.122.0-alpha.1
What is the expected behavior?
The nested shell command should run normally inside the selected sandbox, or fail with a more specific permission/policy message if the command is actually disallowed.
In particular, setting Windows sandbox mode to unelevated should not still fail at sandbox token creation for a trivial Get-Location command.
Additional information
- I searched existing
openai/codexissues forCreateRestrictedToken,windows sandbox, andunelevatedbefore filing. I found related Windows sandbox issues, but not one with this exactCreateRestrictedToken failed: 87repro. - This is blocking attempts to build a genuinely repo-aware automatic executor on Windows using safe settings like
-a neverplus--sandbox workspace-write, because the agent cannot reliably execute even basic local shell reads inside nestedcodex exec. - A higher-level symptom is that automation degrades into partial / patch-only behavior: the model may still answer, but it cannot reliably inspect local files through shell execution.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I’m seeing the same issue on Windows 11 with codex-cli 0.142.5.
Config:
approval_policy = "on-request"
sandbox_mode = "workspace-write"
[windows]
sandbox = "unelevated"
The shell session is a non-elevated / UAC-filtered admin token: medium integrity, with the Administrators group present as deny-only.
A trivial read-only local command fails before execution:
After installing Windows update KB5095093 and rebooting, Codex Desktop shell tool recovered when using windows.sandbox="unelevated". A minimal PowerShell command runs successfully in unelevated mode. However, windows.sandbox="elevated" does not appear to be reliable in this environment, so I cannot say that both sandbox modes are fixed. It is not yet clear whether KB5095093 fixed a Windows sandbox/token-related issue directly, or whether the reboot/sandbox reinitialization cleared stale state.