Skip to content

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

Open
Open
Windows sandboxed shell commands fail with CreateRestrictedToken failed: 87 even with [windows] sandbox = "unelevated"#18451
Labels
bugSomething isn't workingsandboxIssues related to permissions or sandboxingwindows-osIssues related to Codex on Windows systems

Description

@ccstudentcc
ccstudentcc
opened on Apr 18, 2026

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:

    [windows]
sandbox = "unelevated"

  4. Run the following minimal repro:

    @'
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 -

  5. Observe that the nested shell command fails with:

    windows sandbox: CreateRestrictedToken failed: 87

  6. 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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    CLIIssues related to the Codex CLI
    windows-osIssues related to Codex on Windows systems
    sandboxIssues related to permissions or sandboxing
    execIssues related to the `codex exec` subcommand
    on Apr 18, 2026

  2. github-actions commented on Apr 18, 2026

    @github-actions
    github-actionsBot
    on Apr 18, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. etraut-openai
    removed
    CLIIssues related to the Codex CLI
    execIssues related to the `codex exec` subcommand
    on Apr 18, 2026

  4. Teknes-admin commented on Jul 3, 2026

    @Teknes-admin
    Teknes-admin
    on Jul 3, 2026

    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.

  5. thxSakura commented on Jul 8, 2026

    @thxSakura
    thxSakura
    on Jul 8, 2026

    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.

  6. yuukitachi commented on Oct 2, 2026

    @yuukitachi
    yuukitachi
    on Oct 2, 2026

    Adding a related observation with [windows] sandbox = "elevated" in a separate environment. These details describe an earlier failed attempt; I have not performed a new reproduction for this comment.

    • Windows build: 26200.
    • Codex CLI version recorded during the investigation: 0.159.2.
    • Execution context: a Codex desktop agent session, with the caller already running under the Codex offline sandbox account.
    • Launching a benign check through codex sandbox against a synthetic workspace failed with CreateRestrictedToken failed: 87, blocking the integration check.
    • The sandbox log inspected for that day did not contain an entry directly explaining this error.
    • In-app /feedback was accepted, but the UI reported that some diagnostic files could not be uploaded.

    Nested token restrictions may be relevant, but the root cause has not been established. Is invoking codex sandbox or non-interactive Codex from an already restricted Codex desktop process supported? If so, what supported repair or execution arrangement preserves the elevated sandbox, filesystem access restrictions, and network restrictions?

    The integration attempt remains stopped. No sandbox weakening or sandbox removal was used to retry it. No raw logs, credentials, private project files, or session identifiers are attached to this public comment.

  7. seesomething99-tech commented on Oct 13, 2026

    @seesomething99-tech
    seesomething99-tech
    on Oct 13, 2026 – with ChatGPT Codex Connector

    Additional reproduction / diagnostic evidence from Codex CLI 0.162.1 on Windows build 26200.9550 (normal, non-elevated user session):

    • Effective session recorded sandbox_mode=workspace-write, approval_policy=on-request, and [windows] sandbox = "unelevated"; network restricted.
    • Nested Codex Windows sandbox command failed with windows sandbox failed: CreateRestrictedToken failed: 87.
    • Separately, a Codex temporary argument-alias directory creation under the user profile failed with access denied. A read-only Windows access check showed directory listing allowed but subdirectory creation denied for the current restricted token. This may be a distinct problem rather than the root cause of error 87.
    • Token diagnostics of the current shell: restricted token present, non-elevated. Launching a local Python stdio subprocess directly from that restricted shell preserved the restricted, non-elevated token and exited normally on EOF.
    • This does not establish that an MCP server launched by the Codex host after registration would inherit the same sandbox. We did not register the MCP server or change ACLs, sandbox settings, execution policy, or privilege level.
    • We have not isolated the exact invalid argument to CreateRestrictedToken, so we cannot conclude that nesting restricted tokens is inherently unsupported.

    Could maintainers clarify (1) whether the Windows sandbox launcher is expected to work when invoked from an already restricted Codex shell, (2) a supported way to run local stdio MCP servers with guaranteed unelevated sandbox restrictions, and (3) whether the temporary alias-directory failure is a separate known issue?

    No project names, private paths, credentials, tokens, or full local logs included.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingsandboxIssues related to permissions or sandboxingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions