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

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.

6. Run another sandboxed command.

7. Observe:

   sandbox setup required: sandbox setup marker missing or incompatible
   

8. Observe that codex-windows-sandbox-setup.exe is launched again.

9. 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.
2. Why the normal Codex process can reject the marker immediately after the
   elevated helper reports completion.
3. Whether there is a known SID/account-resolution or ACL issue in the Windows
   sandbox setup path.
4. 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.

Start by tracing the VS Code app-server entry point that launches codex.exe and the codex-windows-sandbox-setup.exe helper. Compare the marker validation with the elevated helper's ACL work, using the reported setup_marker.json state and the direct CLI control tests. Done means setup is accepted after successful completion and subsequent sandboxed commands no longer relaunch the helper.