Installation fails on v0.10.5: activation could not reserve exclusive access #1686

Activity

1. github-actions

   added

   editor/integrationEditor compatibility and CLI integrationEditor compatibility and CLI integration

   on Aug 17, 2026
2. yurefr commented on Aug 17, 2026

   

   yurefr

   on Aug 17, 2026

   More actions

   Same problem here on Windows.

   `PS C:\Windows\system32> .\install.ps1 --ui
   codebase-memory-mcp installer (Windows)
     arch:    amd64                                                                                                          target:  C:\Users\yure5\AppData\Local\Programs\codebase-memory-mcp\codebase-memory-mcp.exe                                                                                                                                                    Downloading codebase-memory-mcp-windows-amd64.zip...                                                                    Checksum verified.                                                                                                      Extracting...                                                                                                           Verified candidate: codebase-memory-mcp 0.10.5
   codebase-memory-mcp install 0.10.5
   
   Found 2 existing index(es). Keeping them. After install, re-index to pick up this version's improvements
   
   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.
   error: installation failed (exit code 1)
   PS C:\Windows\system32>`
   
3. DeusData

   added

   bugSomething isn't workingSomething isn't working

   ux/behaviorDisplay bugs, docs, adoption UXDisplay bugs, docs, adoption UX

   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.

   awaiting-reporterWaiting on the reporter for info/repro; stale bot will warn then closeWaiting on the reporter for info/repro; stale bot will warn then close

   on Aug 18, 2026
4. DeusData commented on Aug 18, 2026

   

   DeusData

   on Aug 18, 2026

   Owner

   More actions

   Thank you both for the install transcripts. v0.10.6 includes the install coordination cluster and Windows ACL repair changes, so the next useful discriminator is a retry on v0.10.6 rather than another v0.10.5 trace.

   Please report whether v0.10.6 succeeds. If it still fails, include the complete new activation error and the cache/runtime directory plus its immediate parent permissions, with user and machine names redacted. For the Linux report, please also say whether this is WSL or a mounted filesystem; the shown 0777 directory may connect it to #1687. I have marked this awaiting-reporter while we wait for that version-specific result. Thank you for helping distinguish one shared activation bug from two platform-specific permission failures.
5. github-actions commented on Aug 18, 2026

   

   github-actionsBot

   on Aug 18, 2026 – with GitHub Actions

   More actions

   Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:

   • the codebase-memory-mcp --version you're on
   • the exact steps or command you ran
   • a public repo (or a small dummy snippet) that shows the problem — please don't paste proprietary code

   Once that's here we'll pick it straight back up. Heads-up: issues left awaiting-reporter are automatically closed after a few weeks of silence, but a comment reopens the door anytime.
6. AlfonsoUritec commented on Aug 18, 2026

   

   AlfonsoUritec

   on Aug 18, 2026

   More actions

   Hit this on Windows 11 with 0.10.6. Root cause found and fixed on my side — the reservation check is behaving correctly, but nothing in the error output or the requested diagnostic can lead you to the cause.

   Cause: a stale cross-account ACE on the parent of the cache dir (~/.cache, not ~/.cache/codebase-memory-mcp), on a multi-user machine.

   Requested output

   $ ls -la "${CBM_CACHE_DIR:-$HOME/.cache/codebase-memory-mcp}"
   total 0
   drwxr-xr-x 1 <user> 197121 0 Aug 17 10:15 .
   drwxr-xr-x 1 <user> 197121 0 Aug 17 10:15 ..
   

   Empty, and looks perfectly healthy — that is the problem (see below).

   Error

   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.
   error: installation failed (exit code 1)
   

   Windows 11 Pro 10.0.26200, amd64, PowerShell 7.6.4, non-elevated, .\install.ps1, no CBM_* set. Clean machine: install dir absent, no cbm process, no cbm-install-* in %TEMP%. Failed identically every run.

   Root cause

   The cache dir itself was correctly hardened (protected, owner-only). Its parent was not:

   === C:\Users\<user>\.cache ===
   IdentityReference    FileSystemRights  IsInherited
   <HOST>\<user-a>      FullControl       True
   <HOST>\<user-b>      FullControl       True   <-- different local account
   protected: False
   

   <user-b> is a separate enabled local account, not the installing user. With FullControl on ~/.cache it can rename or replace the child directory regardless of the child's own DACL — so refusing the reservation is the right call.

   The ACE was orphaned: flagged IsInherited = True, but the profile root does not carry it — left behind when the grant was removed upstream without re-propagating. Same family as #1529 / #1614 / #1571, but on the cache path rather than %TEMP%, so the Set-Acl hardening in install.ps1 (~line 152) does not cover it.

   Fix

   icacls "$env:USERPROFILE\.cache" /inheritance:d
   icacls "$env:USERPROFILE\.cache" /remove:g "<HOST>\<user-b>" /t

   Install succeeded on the next run. No reboot, no elevation, nothing closed — removing the ACE was the only variable changed.

   Two suggestions

   1. The requested diagnostic cannot surface this on Windows. ls -la prints POSIX bits synthesized by MSYS; it says nothing about DACLs, and the ACE was on the parent anyway. This would have pointed straight at it:

   foreach ($p in @("$env:USERPROFILE", "$env:USERPROFILE\.cache", "$env:USERPROFILE\.cache\codebase-memory-mcp")) {
     "=== $p ==="; (Get-Acl $p).Access | Select-Object IdentityReference,FileSystemRights,IsInherited | Format-Table -AutoSize
   }

   2. The error names neither the path nor the SID. The acl-grants-cross-account-mutation to S-1-5-21-... message quoted in the install.ps1 comments is far more actionable. Also, "leftover state" reads as stale files — here it was a stale ACE.

   Optional third: extend the %TEMP% ACL hardening to ~/.cache, or validate the parent chain up front and report it.
7. DeusData

   removed

   awaiting-reporterWaiting on the reporter for info/repro; stale bot will warn then closeWaiting on the reporter for info/repro; stale bot will warn then close

   on Sep 5, 2026
8. 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
9. DeusData commented on Sep 12, 2026

   

   DeusData

   on Sep 12, 2026

   Owner

   More actions

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

   Activation no longer fails on the untrusted-owner path that produced the "could not reserve exclusive" error here; untrusted owners are named rather than causing an unconditional failure. Ships in v0.10.9.

   Thanks for the detailed v0.10.5 report.
10. DeusData

    closed this as completedon Sep 12, 2026
11. RockBanzai

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

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

    ...

    df57983
12. 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