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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   sandboxIssues related to permissions or sandboxingIssues related to permissions or sandboxing

   on Jul 25, 2026
2. github-actions commented on Jul 25, 2026

   

   github-actionsBot

   on Jul 25, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex Desktop stuck in "Windows Setup Incomplete" loop despite Windows Sandbox feature enabled #35349

   Powered by Codex Action
3. personalsovereignty888-hash commented on Jul 28, 2026

   

   personalsovereignty888-hash

   on Jul 28, 2026 – with ChatGPT Codex Connector

   More actions

   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.
4. richiejacob commented on Jul 31, 2026

   

   richiejacob

   on Jul 31, 2026 – with ChatGPT Codex Connector

   More actions

   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.
5. topgravy commented on Aug 16, 2026

   

   topgravy

   on Aug 16, 2026

   More actions

   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.
6. 4sj9wrhgbp commented on Aug 29, 2026

   

   4sj9wrhgbp

   on Aug 29, 2026

   More actions

   Adding fresh evidence from Desktop 26.825.4187.0 on Windows 11 (CLI side: 0.150.1, npm install):

   • sandbox.2026-08-29.log shows the setup loop in two distinct waves: 10× sandbox setup marker missing or incompatible between 16:34:34-16:38:21, then 14× more between 17:46:02-17:52:53 (local time). Each cycle logs WFP setup succeeded ... 12 installed filters → setup binary completed → next check still reports the marker missing/incompatible.
   • New artifact in %USERPROFILE%\.codex\.sandbox\: deny_read_acl_state.json (first observed on this machine 2026-08-29, {"principals":{}}). A non-elevated process now gets Permission denied reading setup_marker.json. With deny-read ACEs in play, the classic "grant the user (R)" workaround stops working (deny wins over allow).
   • Notably, the loop also fired while the config already said [windows] sandbox = "unelevated" — same behavior as described in Windows Desktop: unelevated sandbox still repeatedly launches elevated setup helper #23712.
   • The elevated value appeared in config.toml written by the Desktop app itself (it mirrors its internally-remembered sandbox mode on launch); deleting the key while Desktop is running gets rewritten. Recovery that worked: fully quit Desktop → set [windows] sandbox = "unelevated" → relaunch. Since 17:52 the log shows zero further setup-required lines, and TEMP write probes inside the sandbox succeed again.
   • Impact beyond the nag dialog: during the loop window, sandboxed test runs inside Codex misreported ~20 failures (no usable temp dir); the same tests pass 288/288 when run locally after the workaround.

   Hope the timeline + the new deny-read state file helps pin down the marker reconciliation logic.