Windows Desktop 26.721 repeats elevated sandbox setup; marker rewritten but unreadable/rejected

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

• #35349

Powered by Codex Action

Another affected Windows user here. The app was working normally before, then suddenly started showing Finish Windows setup / Windows setup didn't finish.

Observed behavior:

1. Launch ChatGPT/Codex Desktop.
2. Click Try Windows setup again.
3. Approve the genuine OpenAI LLC UAC prompt.
4. The app immediately returns to Windows setup didn't finish.

Troubleshooting already tried with no effect:

• Renamed/reset %USERPROFILE%\.codex\config.toml.
• Fully quit the app and retried as administrator.
• Moved the entire %USERPROFILE%\.codex directory aside so the app could recreate a clean state.
• Repeated the UAC-approved Windows setup flow.

The same failure persists even with a fresh .codex directory, so this does not appear to be caused only by a corrupt config or stale sandbox state. The user reports that the desktop app was previously working normally and then failed suddenly, likely after an automatic app update.

The only available older sandbox log is from a previously working session and shows setup binary completed, errors=[], and successful PowerShell commands. The current failed setup flow does not appear to append a useful new error to that old log.

Environment:

• ChatGPT Plus
• Windows x64
• Chinese UI locale
• Previously working package shown in old logs: OpenAI.Codex_26.513.4821.0
• Current package version not yet confirmed

This looks consistent with the Desktop setup-marker/setup-state loop described in this issue, except that resetting the entire .codex directory also did not recover the app.

Additional reproduction on a newer 26.721 build — marker is readable and ACLs are correct

I am seeing a closely related repeated-UAC/setup loop with a newer package, but in this reproduction the marker is readable and its ACL is not the problem.

Environment

• OpenAI.Codex package: 26.721.11231.0
• Bundled/staged CLI: codex-cli 0.146.0-alpha.3.1
• Windows x64
• Invocation context: fresh nested Codex reviewer/worker processes launched by a local automation controller. The controller stages the signed binaries from the installed Windows package under %LOCALAPPDATA%\ai-peer-review-harness\codex-runtime\<digest>.
• The UAC dialog identifies the genuine signed codex-windows-sandbox-setup.exe from that staged runtime.

Marker and account state

Both sandbox accounts exist and are enabled:

CodexSandboxOffline  Enabled=True
CodexSandboxOnline   Enabled=True

%USERPROFILE%\.codex\.sandbox\setup_marker.json is readable by the normal user, and the file ACL grants that user FullControl:

{
  "version": 5,
  "offline_username": "CodexSandboxOffline",
  "online_username": "CodexSandboxOnline",
  "proxy_ports": [],
  "allow_local_binding": false,
  "read_roots": [],
  "write_roots": []
}

NT AUTHORITY\SYSTEM     FullControl
BUILTIN\Administrators FullControl
<normal user>           FullControl

So this reproduction is not explained by the marker-read ACL failure described in the original report.

Installed and staged binaries are identical

The controller-staged files are byte-identical to the current installed package files:

codex.exe SHA-256
39E9E041EA33AC34AAD9578ADFE660C5C7A6DC8F82620B77623960F9352A6EF3

codex-windows-sandbox-setup.exe SHA-256
400CF60D47A8F865E33E43815ECADF3369FE71C4AB830C712AA9E949D6B06AE1

This rules out a stale staged runtime or mismatched setup helper in this case.

Repeated behavior

For the same staged runtime and the same canary worktree, ordinary Git commands repeatedly trigger the setup helper within seconds:

setup refresh: spawning ...\codex-windows-sandbox-setup.exe
setup refresh: processed 2 write roots (read roots delegated); errors=[]
setup binary completed

sandbox setup required: sandbox users missing or incompatible with marker version

setup refresh: spawning ...\codex-windows-sandbox-setup.exe
setup refresh: processed 2 write roots (read roots delegated); errors=[]
setup binary completed

The helper is then invoked again for subsequent commands in the same workspace, producing repeated UAC prompts. The log also repeatedly contains:

hide users: failed to hide current user profile dir (C:\Users\Default):
SetFileAttributesW failed for C:\Users\Default: 5 (Access is denied.)

That warning may be secondary, because the setup refresh is requested before it appears.

An additional notable detail is that the helper reports processing two write roots, while the marker read afterward still contains empty read_roots and write_roots arrays.

Operational impact

This prevents unattended nested reviewer/worker execution: approving the genuine OpenAI UAC prompt does not terminate the setup cycle, and multiple fresh agents can create a prompt storm. We are now failing the affected backend closed as manual_action_required rather than retrying or falling back to unsandboxed execution.

This appears to extend the issue in two ways:

1. It still occurs on package 26.721.11231.0 with CLI 0.146.0-alpha.3.1.
2. It can occur even when the marker is readable, the ACL is correct, both users exist, and the staged/installed binaries match exactly.

I can provide a longer sanitized log excerpt or open a separate issue for the nested-CLI/controller invocation path if that would be more useful.

I reproduced this on Codex 26.810.7004.0 and found an ACL issue with setup_marker.json.

The sandbox helper successfully created %USERPROFILE%\.codex\.sandbox\setup_marker.json and both CodexSandboxOffline / CodexSandboxOnline local users, but the normal Codex process received Access denied when reading the marker. The marker contents were valid (version: 5, correct sandbox usernames, etc.).

Granting the interactive Windows user explicit Full Control on the existing marker with:

icacls "%USERPROFILE%\.codex\.sandbox\setup_marker.json" /grant "USERNAME:F"

immediately fixed the problem and Codex completed setup normally.

This suggests the helper is successfully creating the sandbox but applying an ACL to setup_marker.json that prevents the non-elevated Codex process from reading/validating it. Worth investigating the marker security descriptor/interactive-user SID handling.