[Windows][VS Code] Windows sandbox setup repeatedly fails after helper completion; setup_marker.json ACL workaround

Open 💬 1 comment Opened Aug 23, 2026 by Edward-Lucas
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the IDE extension are you using?

26.818.41705

What subscription do you have?

Free

Which IDE are you using?

VS Code

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

On Windows, the OpenAI Codex VS Code extension repeatedly fails to complete
Windows sandbox setup.

The VS Code UI reports the sandbox setup as failed.

When a sandboxed command is executed, Codex reports:

sandbox setup required: sandbox setup marker missing or incompatible

The setup helper is then launched:

codex-windows-sandbox-setup.exe

The helper log reports that the helper's own setup work completes:

WFP setup succeeded for CodexSandboxOffline with 12 installed filters
codex-windows-sandbox-setup.exe] setup binary completed
read-acl-only mode: applying read ACLs
read ACL run completed

However, the overall setup is still reported as failed by Codex/the VS Code UI,
and the next sandboxed command immediately reports the same
sandbox setup required message and starts the setup helper again.

For example:

16:57:22.233 codex.exe
sandbox setup required: sandbox setup marker missing or incompatible

16:57:25.090 codex-windows-sandbox-setup.exe
setup binary completed

16:57:25.115
read ACL run completed

16:57:26.282 codex.exe
sandbox setup required: sandbox setup marker missing or incompatible

A higher-level error also appeared:

orchestrator_helper_incomplete:
setup helper exited successfully before setup completed

This appears to be a failure in the overall setup validation/orchestration rather
than an obvious crash of the elevated helper itself.

What steps can reproduce the bug?

  1. Install the OpenAI Codex VS Code extension on Windows.
  2. Open a local workspace.
  3. Run a command that requires the Windows sandbox.
  4. Approve the UAC prompt for codex-windows-sandbox-setup.exe.
  5. Observe that the helper reaches setup binary completed and

read ACL run completed.

  1. Run another sandboxed command.
  2. Observe:

sandbox setup required: sandbox setup marker missing or incompatible

  1. Observe that codex-windows-sandbox-setup.exe is launched again.
  2. Repeat the command and observe the same cycle.

The VS Code extension launches the bundled Codex CLI as:

codex.exe -c features.code_mode_host=true app-server --analytics-default-enabled

The bundled codex.exe works normally when executed directly from the extension
directory.

An independently installed Codex CLI also works normally.

This makes the VS Code Extension/app-server sandbox setup path the main
distinguishing factor in this reproduction.

What is the expected behavior?

After the elevated sandbox setup completes, Codex should accept the resulting
sandbox state as valid and reuse it for subsequent sandboxed commands.

The user should not receive repeated UAC/setup requests for every command.

If validation fails because the marker cannot be accessed, Codex should report a
specific ACL/permission error rather than treating the marker as simply
"missing or incompatible".

Additional information

Sandbox state

The following files exist:

%USERPROFILE%\.codex\.sandbox\setup_marker.json
%USERPROFILE%\.codex\.sandbox-secrets\sandbox_users.json

Both contain version: 5.

The sandbox users exist and are enabled:

CodexSandboxOffline
CodexSandboxOnline

Both are members of:

CodexSandboxUsers

The setup log also reports successful WFP configuration.

Workaround

In my environment, explicitly granting the current Windows user's SID
Full Control on setup_marker.json stopped the repeated setup cycle:

$marker = "$env:USERPROFILE\.codex\.sandbox\setup_marker.json"
$sid = (Get-LocalUser -Name $env:USERNAME).SID.Value

icacls $marker /grant "*${sid}:F"

The current user's SID was:

S-1-5-21-4260286667-2968846849-2356761996-1001

After this change, sandboxed commands began working normally without repeatedly
launching codex-windows-sandbox-setup.exe.

I am reporting this as a confirmed workaround in my environment, not as a
definitive determination of the underlying root cause.

Control tests

  • Independently installed Codex CLI: works normally.
  • Bundled codex.exe executed directly from the VS Code extension directory:

works normally.

  • VS Code Codex extension using its app-server path:

reproduces the sandbox setup loop.

Questions

Could you confirm:

  1. Whether setup_marker.json is expected to grant access to the interactive

Windows user's SID during sandbox setup.

  1. Why the normal Codex process can reject the marker immediately after the

elevated helper reports completion.

  1. Whether there is a known SID/account-resolution or ACL issue in the Windows

sandbox setup path.

  1. Whether the VS Code app-server path has any additional sandbox setup

behavior compared with direct CLI execution.

Related issues

This appears related to:

  • #30445 — Windows sandbox setup marker ACL prevents Codex from starting

sandbox after UAC setup

  • #35407 — Windows Desktop repeatedly runs elevated sandbox setup

The present report is specifically reproduced with the VS Code extension and
its app-server execution path.

AI-assisted disclosure

This issue report was prepared with assistance from an AI language model.
All logs, reproduction steps, system information, and the reported workaround
were personally observed and verified on my system. The AI was used to help
organize and summarize the findings.
Please independently verify the technical conclusions against the provided
evidence.

View original on GitHub ↗

1 Comment

github-actions[bot] contributor · 5 days ago

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

  • #39543

Powered by Codex Action