Windows: v0.10.8 still rejects CodexSandboxUsers profile ACL during secure coordination #2023

Activity

1. zjh02249

   added

   bugSomething isn't workingSomething isn't working

   on Sep 3, 2026
2. github-actions

   added

   editor/integrationEditor compatibility and CLI integrationEditor compatibility and CLI integration

   windowsWindows-specific issuesWindows-specific issues

   on Sep 3, 2026
3. DeusData

   added

   securitySecurity vulnerabilities, hardeningSecurity vulnerabilities, hardening

   priority/highNeeds near-term maintainer attention; high-impact bug, regression, safety issue, or release blocker.Needs near-term maintainer attention; high-impact bug, regression, safety issue, or release blocker.

   on Sep 3, 2026
4. DeusData commented on Sep 3, 2026

   

   DeusData

   on Sep 3, 2026

   Owner

   More actions

   Thank you for the precise A/B report and for resolving the reported SID to CodexSandboxUsers.

   Current main confirms the compatibility boundary you describe: win_file_acl_secure() rejects a mutation-capable ACE when its SID is outside the trusted set, and there is no Codex sandbox-group exception. This is therefore a real Windows/Codex integration problem, not a generic startup report.

   Accepting an additional principal here changes the local coordination security model, so we need more time to review the safe rule rather than promise a broad exception. I have routed this as a high-priority security and integration issue. No more diagnostics are requested from you right now; thank you again for the clean reproduction.
5. XIYBHK commented on Sep 5, 2026

   

   XIYBHK

   on Sep 5, 2026

   Contributor

   More actions

   Additional reproduction from the same Windows/Codex integration path.

   Environment

   • codebase-memory-mcp 0.10.8 (Windows amd64)
   • Windows 11 x64
   • Codex Desktop installed
   • Existing binary: C:\Users\<user>\cbm-bin\codebase-memory-mcp.exe

   Reproduction

   The official Codex-only dry run succeeds and reports the expected targets:

   codebase-memory-mcp install --clients=codex --dry-run
   
   Codex CLI:
     mcp: C:/Users/<user>/.codex/config.toml
     instructions: C:/Users/<user>/.codex/AGENTS.md
     skill: C:/Users/<user>/.codex/skills/codebase-memory/SKILL.md
     agent: ...codebase-memory-scout.toml
     agent: ...codebase-memory.toml
     agent: ...codebase-memory-auditor.toml
     hooks: SessionStart + SubagentStart
   EXIT=0
   

   The real install fails before any Codex configuration is written:

   codebase-memory-mcp install --clients=codex
   
   error: failed to stage install candidate: activation transaction I/O failed: acl-grants-cross-account-mutation to S-1-5-21-1115800554-604511426-2492648926-1002 (os 0) at C:/Users/<user>/.local/bin
   EXIT=1
   

   The default target directory has cross-account Modify ACEs:

   C:\Users\<user>\.local\bin
     <machine>\CodexSandboxUsers:(I)(OI)(CI)(M,DC)
     S-1-5-21-3357418771-1090083677-4082722951-2668499490:(I)(OI)(CI)(M,DC)
   

   I then retried with an existing directory whose ACL grants Full Control only to the invoking user and inherited read access to the Codex sandbox group:

   codebase-memory-mcp install --clients=codex --dir=C:\Users\<user>\cbm-bin
   

   This passed candidate staging but still failed during activation reservation:

   error: activation could not reserve exclusive access; no activation was committed.
   error: this is NOT a running-session problem - the reservation itself failed (coordination lock, leftover state, or permissions).
   EXIT=1
   

   After both attempts, C:\Users\<user>\.codex\config.toml was unchanged and still contained no codebase-memory-mcp MCP server entry.

   Expected behavior

   A Codex-only install should either complete using a supported private install/runtime location, or identify the exact rejecting path, SID, and ACL/coordination check. Changing the binary install directory did not make the activation path usable on this host.

   This appears to extend the CodexSandboxUsers/profile ACL case in this issue from daemon startup to the official Codex installation flow.
6. iBen-creator commented on Sep 10, 2026

   

   iBen-creator

   on Sep 10, 2026

   More actions

   Confirming this on v0.10.8 / Windows 11 Pro x64 (10.0.26200), with two details that may widen the scope slightly.

   It is not only CodexSandboxUsers

   On this machine C:\Users\<user>\AppData carries three distinct mutation grants, all of which inherit down into %LOCALAPPDATA% — the default rendezvous parent:

   Principal	Rights	Inherited
   S-1-15-3-3557520199-3666692283-…-3692855932 (AppContainer / capability SID)	FullControl	no (set on AppData)
   <machine>\CodexSandboxUsers	Modify	yes
   S-1-5-21-… (orphaned SID, no resolvable account)	Modify	yes

   So even if the Codex sandbox group were special-cased, the AppContainer SID with FullControl and the orphaned S-1-5-21 SID would each independently fail the ancestor walk. The profile root C:\Users\<user> itself is clean here — everything problematic is introduced at the AppData level. That seems to support the issue's suggested direction (a configurable runtime/coordination parent) over enumerating trusted groups, since the set of principals that legitimately hold write ACEs on AppData is open-ended.

   The refusal note was not surfaced for the reservation failure

   The user-visible output was only the generic message, with nothing above it:

   error: activation could not reserve exclusive access; no activation was committed.
   error: this is NOT a running-session problem — the reservation itself failed (coordination lock,
   leftover state, or permissions). Nothing needs to be closed. Check the errors above, and report
   this with the output of 'ls -la "${CBM_CACHE_DIR:-$HOME/.cache/codebase-memory-mcp}"' if it persists.
   

   $HOME/.cache/codebase-memory-mcp was empty at that point (nothing had been written yet), so the requested diagnostic yields nothing either — which is the exact "check the errors above, and nothing was above" situation #1537/#1416 set out to remove. Neither cbm_activation_transaction_refusal_note() nor cbm_daemon_ipc_validation_detail() produced text on this path.

   Worth noting the note plumbing does work for staging. When I ran the extracted binary from a directory that inherited Authenticated Users: Modify from C:\, I got a precise, actionable message:

   error: failed to stage install candidate: activation transaction I/O failed:
   acl-grants-cross-account-mutation to S-1-5-11 (os 0) at C:/cbm-dl
   

   That message named the principal and the directory. Hardening that staging directory to an owner-only protected DACL cleared it, and the failure then moved to the reservation step — where the detail went silent again. So the gap looks specific to the reservation/ancestor-walk path rather than to the refusal-note mechanism as a whole.

   CBM_RUNTIME_DIR is a working workaround

   For anyone hitting this before a fix lands: pointing the rendezvous at an owner-private directory outside AppData resolves it completely.

   $rt = 'C:\cbmrt'
   New-Item -ItemType Directory -Force $rt | Out-Null
   $acl = New-Object System.Security.AccessControl.DirectorySecurity
   $acl.SetAccessRuleProtection($true, $false)          # break inheritance
   $me = ([System.Security.Principal.WindowsIdentity]::GetCurrent()).User
   $acl.SetOwner($me)
   $acl.AddAccessRule((New-Object System.Security.AccessControl.FileSystemAccessRule(
       $me, 'FullControl', 'ContainerInherit,ObjectInherit', 'None', 'Allow')))
   Set-Acl -Path $rt -AclObject $acl
   
   $env:CBM_RUNTIME_DIR = $rt

   With that set, install, the daemon, the CLI and the MCP server all start normally. It has to be present for every cbm process, so it is worth setting as a persistent user environment variable and adding to the env block of the MCP entry in the client config — the installer does not write one.

   Two things confirmed while narrowing this down, both matching the comments in src/daemon/bootstrap.c:

   • CBM_CACHE_DIR does not help — it moves the cache, never the rendezvous.
   • A directory directly under C:\ passes the ancestor walk once its own DACL is protected, even though C:\ grants Authenticated Users: AppendData.
7. DeusData

   added a commit that references this issue on Sep 12, 2026

   Merge pull request #2139 from DeusData/fix/decision-b-win-sid-trust

   ...

   1b067e3
8. DeusData commented on Sep 12, 2026

   

   DeusData

   on Sep 12, 2026

   Owner

   More actions

   Fixed on main by #2139 (merge commit 1b067e3b042da824edb27bb173df41afb2d27beb).

   The CodexSandboxUsers sandbox group is still (correctly) not trusted, but the activation error now names the exact path and SID it rejected instead of failing opaquely, so the situation is diagnosable. Ships in v0.10.9.

   Thanks for staying on this through v0.10.8 — the actionable error message is a direct result of your reports.
9. DeusData

   closed this as completedon Sep 12, 2026
10. RockBanzai

    added a commit that references this issue on Sep 12, 2026

    fix(install): trust the local machine's built-in Administrator; name …

    ...

    df57983
11. rtellez91 commented on Sep 15, 2026

    

    rtellez91

    on Sep 15, 2026

    More actions

    Thanks for sharing the workaround.

    Is there an ETA for the release?
12. DeusData commented on Sep 19, 2026

    

    DeusData

    on Sep 19, 2026

    Owner

    More actions

    Thank you for following up, and apologies: our earlier closure was too broad. Commit 1b067e3 improved the diagnostic by naming the rejected path and SID; that does not by itself resolve the original Windows/Codex compatibility request. I am reopening this to keep that remaining problem visible.

    The diagnostic improvement has now shipped in v0.11.0: https://github.com/DeusData/codebase-memory-mcp/releases/tag/v0.11.0. The earlier v0.10.9 forecast was superseded. We still need to review a supported solution that preserves the local coordination security boundary; we are not recommending broadly trusting extra accounts or weakening ACL checks. Thank you for the precise reports and for sharing the runtime-directory workaround.
13. DeusData

    reopened this on Sep 19, 2026
14. daidaiJ

    added 2 commits that reference this issue on Sep 29, 2026

    fix(install): trust the local machine's built-in Administrator; name …

    ...

    95cff51

    fix(install): trust the local machine's built-in Administrator; name …

    ...

    2929339