Windows: activation/CLI coordination fails when OpenAI Codex CLI sandbox group holds profile ACEs (v0.10.4) #1650

Activity

1. github-actions

   added

   editor/integrationEditor compatibility and CLI integrationEditor compatibility and CLI integration

   windowsWindows-specific issuesWindows-specific issues

   on Aug 15, 2026
2. DeusData commented on Aug 15, 2026

   

   DeusData

   on Aug 15, 2026

   Owner

   More actions

   Thank you for this — and I'm sorry you lost an evening to it. This is one of the most precise reports we have had on this failure: naming the SID, resolving it to MC\CodexSandboxUsers, tabulating the rights and inheritance per path, and ruling out elevation and Defender before filing. That saved us the two or three wrong guesses we have made on neighbouring issues.

   Your root-cause reading is correct, and I can be specific about why the fix landing tonight will not help you, so you don't upgrade expecting it to.

   Why the v0.10.5 change misses your case. We relaxed the ancestor walk to tolerate AppContainer identities — package SIDs (S-1-15-2-*) and capability SIDs (S-1-15-3-*), both under identifier authority 15. Those are unremovable by design: a process cannot choose which AppContainer it runs in. MC\CodexSandboxUsers is S-1-5-21-…-1005 — authority 5, an ordinary local group. That class is still refused deliberately, because unlike an AppContainer SID it names a principal that can actually be exercised, and a Modify grant on …\Temp is exactly the cross-account mutation the check exists to catch. So the check is doing its job; the problem is that on your machine it leaves nowhere to go.

   On your first suggestion — the error naming the path. Agreed, and that part is already fixed on main and ships in v0.10.5: the secure CLI coordination could not be created (endpoint) message now prints the validation detail, naming the directory and the rule that refused. A related fix corrects something worse: the ancestor walk was printing the name of the child it was about to enter rather than the directory that actually refused, so several reporters were sent to inspect a directory that was fine. If you upgrade and re-run, the message should finally tell us which path is failing your coordination attempt — I genuinely can't tell you from here, since AppData\Local carries only ReadAndExecute for that group, which is not a mutation grant.

   The workaround you were reaching for. Your attempt #2 was the right instinct and failed for a reason that is our fault: CBM_CACHE_DIR moves the cache, never the rendezvous directory — that is #1621. There has been no way to relocate the rendezvous in a shipped build at all; the only hook was compiled out unless test seams were enabled, so a test build would start where the product build would not.

   PR #1645 (open, in CI now) adds CBM_RUNTIME_DIR for exactly this. It does not relax the check — the directory you name goes through the same validation, and a value that fails is refused rather than silently ignored. But the isolated directory you already built in attempt #2 (inheritance disabled, SYSTEM / Administrators / your account only, no Codex group) is precisely an ancestry that should pass. If it lands in tonight's release I would be grateful if you tried pointing CBM_RUNTIME_DIR at that directory; if it does not land tonight it goes into the next one.

   On the escape hatch. You are the second person to ask for it — #1624 requests the same thing from a different angle. It is an open decision rather than a scheduled change, because a flag that lets a second account write to our coordination directory weakens a real boundary, and we would rather exhaust "give the operator a location that legitimately passes" first. CBM_RUNTIME_DIR is that attempt. If it turns out there are machines where no reachable location passes, that is the argument for the flag, and your report would be the evidence.

   Taking you up on the offer of diagnostics: after upgrading to v0.10.5, the output of a failing cli invocation with the new validation detail would be the single most useful thing — it will name the path we are refusing, which is the one fact none of us has yet.

   Apologies again for the state this is in. There has been a cluster of install and startup failures on Windows over the last few days and we are working through them as fast as we can verify each one.
3. DeusData

   added

   bugSomething isn't workingSomething isn't working

   on Aug 15, 2026
4. samartomar commented on Aug 15, 2026

   

   samartomar

   on Aug 15, 2026

   More actions

   Confirming 0.10.5 resolves this on a host matching the report.

   Environment: Windows amd64, OpenAI Codex CLI sandbox installed. The user-profile AppData directory carries two explicit ACEs granting an AppContainer capability SID (S-1-15-3-…) full control — one direct, one inherit-only with a raw GENERIC_ALL mask — alongside the Codex sandbox group holding (OI)(CI)(RX).

   0.10.4, launched via uvx --offline --no-python-downloads --no-env-file:

   exit 1, JSON-RPC -32001
   "secure daemon endpoint could not be created: <profile>\AppData:
    DACL entry 1 grants mutation rights 0x000d0152 to untrusted identity
    (other S-1-15-3-…)"
   

   Deterministic — reproduced on a warm runtime cache with no network. Unconditional: the MCP server path, cli index_status, and --ui=false all fail at the same gate. 0.9.0 starts cleanly (exit 0) on the identical host, flags, and cache.

   0.10.5, same host, same flags, capability ACE still present and the Codex sandbox still running: exit 0, full initialize response, serverInfo.version 0.10.5, provisioning reports checksum verified.

   One data point that may help anyone else hitting this: removing the ACEs locally is not a workaround. The removal succeeds (verified via RemoveAccessRuleAll — note that icacls /remove:g silently no-ops against the GENERIC_ALL-mask ACE, reporting Successfully processed 1 files while changing nothing), but the Codex sandbox restores the full prior ACL within the same session. The group self-describes as Codex sandbox internal group (managed). So on a Codex-equipped Windows host the fix in 0.10.5 is the only route — there is no durable local mitigation.

   Linux x86_64 control on the same versions: both start cleanly, the daemon does not detach, and the UI listener binds 127.0.0.1:9749.
5. DeusData commented on Aug 17, 2026

   

   DeusData

   on Aug 17, 2026

   Owner

   More actions

   Closing as fixed in v0.10.5 by #1623 (merge 076c8ae): ancestor directories tolerate the AppContainer package/capability ACEs (S-1-15-2-/S-1-15-3-) that ride along on Codex-sandbox-equipped profiles, while the runtime directory itself stays strict. Confirmed above on a matching host — same machine, same flags, sandbox still active: 0.10.4 fails the gate, 0.10.5 returns exit 0 with a full initialize. The added data point that the sandbox rewrites removed ACEs within the session (and that icacls silently no-ops on the GENERIC_ALL ACE) is exactly why we solved this by classifying identities rather than asking anyone to fight the ACL — thank you for documenting it so the next person does not burn a day on a mitigation that cannot stick. CBM_RUNTIME_DIR (#1645) also exists now as a general relocation lever if a future host needs one.
6. DeusData

   closed this as completedon Aug 17, 2026