Windows sandboxed shell commands fail with CreateRestrictedToken failed: 87 even with [windows] sandbox = "unelevated"

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

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 codex path 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?

  1. On Windows 11, use the Codex CLI bundled with the VS Code extension.
  2. Ensure the session is a normal non-admin PowerShell session.
  3. Set Windows sandbox mode to unelevated in config:

``toml
[windows]
sandbox = "unelevated"
``

  1. 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 -
``

  1. Observe that the nested shell command fails with:

``text
windows sandbox: CreateRestrictedToken failed: 87
``

  1. Repeat with --sandbox read-only; the same error still occurs.

Observed thread ids from minimal repros:

  • 019d9e72-ae2e-7ca0-b017-92efdc5aace6 on 0.119.0-alpha.28
  • 019d9e73-2e64-7833-b1c9-9e13e47c82a0 on 0.119.0-alpha.28 (read-only)
  • 019d9e6e-713c-7992-beb5-a260b049ea69 on 0.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/codex issues for CreateRestrictedToken, windows sandbox, and unelevated before filing. I found related Windows sandbox issues, but not one with this exact CreateRestrictedToken failed: 87 repro.
  • This is blocking attempts to build a genuinely repo-aware automatic executor on Windows using safe settings like -a never plus --sandbox workspace-write, because the agent cannot reliably execute even basic local shell reads inside nested codex 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.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 4 months ago

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

  • #17094
  • #17325
  • #17847
  • #16780

Powered by Codex Action

Teknes-admin · 1 month ago

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:

git remote -v
Codex log line:

Code
· text
execution error: Io(Custom { kind: Other, error: "windows sandbox: CreateRestrictedToken failed: 87" })
Retrying the same command with visible escalation / outside the sandbox works:

Code
· json
"sandbox_permissions": "require_escalated"
So this does not look Git/network/repo-specific. It appears to fail in the Windows sandbox token creation path before the command is executed. Subscribing here because this matches my local repro.
thxSakura · 1 month ago

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.