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

[Mc-kndll]

Summary

On Windows 10 Pro (19045), install and every cli invocation fail with:

error: activation could not reserve exclusive access; no activation was committed.

codebase-memory-mcp: secure CLI coordination could not be created (endpoint)

The first failure I hit (running from a directory with a third-party ACL) named the cause explicitly:

error: failed to stage install candidate: activation transaction I/O failed:
acl-grants-cross-account-mutation to S-1-5-21-...-1005 (os 0)

That SID resolves to a local group created by OpenAI Codex CLI's sandbox: MC\CodexSandboxUsers.

Root cause (as far as I can tell)

That group holds ACEs across the user profile:

Path	Rights	Inherited
C:\Users\<user>\.cache	ReadAndExecute	No
C:\Users\<user>\AppData\Local	ReadAndExecute	Yes
C:\Users\<user>\AppData\Local\Temp	Modify	No

CBM's admission/coordination layer appears to refuse any location a second account can write to — which is correct behaviour, but on a machine that also has Codex CLI installed there is no reachable location left, so CBM cannot start at all.

What I tried (all still fail identically)

1. Elevation — ran install --skip-config -y from an elevated PowerShell; script confirmed IsInRole(Administrator) = True. Same error, so this is not a privilege problem.
2. Isolated cache dir — created a directory with inheritance disabled and only SYSTEM, Administrators, <user> (no Codex group), pointed CBM_CACHE_DIR at it.
3. Clean TEMP — additionally redirected TEMP and TMP into that protected directory.
4. Windows Defender — Get-MpThreat / Get-MpThreatDetection are both empty; nothing was quarantined.
5. Ran from a plain user-owned directory (C:\Users\<user>\cbm-kurulum) rather than a temp path.

No log file is ever written — ${CBM_CACHE_DIR}/logs stays empty, so the failure happens before logging is initialised.

Environment

• Windows 10 Pro 19045 (amd64)
• codebase-memory-mcp v0.10.4, codebase-memory-mcp-windows-amd64.zip
• SHA-256 verified against checksums.txt: 54176ed9f7b69a862b3b5c4a9fec31e14639f85f1e48a4f895fca9799c2cd000
• --version and --help work fine; only coordination/activation fails
• Binary at C:\Users\<user>\.local\bin\codebase-memory-mcp.exe (ACL clean: SYSTEM / Administrators / user only)

Suggestions

• The error text would be much more actionable if it named which path failed the cross-account check — right now (endpoint) gives nothing to fix.
• Consider an opt-in escape hatch (e.g. --allow-foreign-acl or an explicit acknowledged-risk flag) for machines where another agent sandbox has already claimed profile-wide ACEs. Codex CLI is common enough that this combination will likely be hit by others.

Happy to run any diagnostic build or extra command you want.

[DeusData]

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.

[samartomar]

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.

[DeusData]

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.