Windows: install/uninstall/doctor all fail with "active CBM sessions and operations could not be stopped safely" #1416

Activity

1. jayeshh-1

   added

   bugSomething isn't workingSomething isn't working

   on Aug 2, 2026
2. github-actions

   added

   editor/integrationEditor compatibility and CLI integrationEditor compatibility and CLI integration

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

   windowsWindows-specific issuesWindows-specific issues

   on Aug 2, 2026
3. DeusData

   added

   stability/performanceServer crashes, OOM, hangs, high CPU/memoryServer crashes, OOM, hangs, high CPU/memory

   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 Aug 3, 2026
4. DeusData

   added this to the 0.9.1-rc milestone on Aug 3, 2026
5. DeusData commented on Aug 3, 2026

   

   DeusData

   on Aug 3, 2026

   Owner

   More actions

   Thank you for capturing the install, uninstall, doctor, and cache-access symptoms together. Current main contains Windows private-DACL creation and repair paths, but the observed state shows that those protections are not sufficient across the RC install lifecycle. I have routed this as a high-priority Windows stability bug in 0.9.1-rc. It remains separate from #1351 for now because this report also covers session shutdown and installer recovery; the two can be consolidated later only if a shared red case proves one root cause.
6. patxisan commented on Aug 4, 2026

   

   patxisan

   on Aug 4, 2026

   More actions

   Independent reproduction on a second machine, plus a recovery procedure that works — which is the open question at the end of this report.

   Environment

   • codebase-memory-mcp 0.9.1-rc.1, binary variant ui, Windows 10 Pro x64 (19045), 64 GB RAM
   • Upgraded from a working 0.9.0 (ui) install
   • Downloaded asset codebase-memory-mcp-ui-windows-amd64.zip, SHA-256 verified against checksums.txt (d12602d2a6a75218aa020890d865ae033ffff4e51ced5bf4d79af9583ce5eaaa) — so this is not a corrupt download

   Same failure on install

   install fails exactly as reported:

   error: active CBM sessions and operations could not be stopped safely; no activation was committed.
   

   Both through install.ps1 and by invoking the binary's own install -y --force --dir=... directly. No codebase-memory-mcp processes were running — all were stopped beforehand and Get-Process returned zero.

   A different message on the paths that matter

   This report lists cli list_projects failing with the activation error. On this machine those paths fail with a different message:

   codebase-memory-mcp: CBM daemon could not start within 30000 ms
   

   and — the part that makes the RC unusable rather than merely un-installable — the MCP stdio server fails the same way. A bare initialize handshake never gets a response:

   $ echo '{"jsonrpc":"2.0","id":1,"method":"initialize",...}' | codebase-memory-mcp
   codebase-memory-mcp: CBM daemon could not start within 30000 ms
   

   So this is not confined to the install/uninstall/doctor lifecycle: on 0.9.1-rc.1 the product itself does not serve. Whether that is the same root cause under a second message or a separate defect is for you to judge, but it seemed worth separating in the report.

   Ruled out here

   • Binary present on disk, not quarantined
   • Get-MpThreatDetection returns nothing — no Defender action, despite the RC notes' AV history
   • A stale .cache/codebase-memory-mcp/.hook-daemon-absent-notice containing a dead PID (79540, from processes killed earlier) — removing it changed nothing
   • No *.lock, socket or daemon runtime files anywhere under the cache directory
   • No daemon logs written at all under .cache/codebase-memory-mcp/logs — the failure happens before any logging

   One environmental note that may or may not matter: this machine had two installations, ~/.local/bin (on PATH) and %LOCALAPPDATA%\Programs\codebase-memory-mcp. Both held 0.9.0 before the upgrade.

   Recovery that worked

   Answering "Is there an official recovery procedure or activation reset?" — unofficially, yes, and it costs nothing:

   1. Stop every codebase-memory-mcp process.
   2. Overwrite the binary in place with the 0.9.0 executable. No installer, no uninstall — both of those are exactly what fails. A plain file copy over codebase-memory-mcp.exe is enough.
   3. Start it.

   0.9.0 comes straight back up and the existing index survives untouched:

   level=info msg=server.start version=0.9.0
   level=info msg=autoindex.skip reason=already_indexed project=...
   

   The cache directory needs no cleaning, which matters given that this report notes it "cannot be cleaned because the activation transaction never completes" — it does not need to be. Keeping a copy of the outgoing binary before upgrading is the whole prerequisite, and install.ps1 does not leave one (it deletes its own .retired-* files at the end of the run).

   Why we were upgrading

   For #1083 — the RC notes list "WAL bounded via journal_size_limit with checkpoint-starvation warnings". We hit that bug hard: a 75.92 GB -wal against a 0.14 GB database (542×) with 8 concurrent MCP processes, which filled the system drive. So the fix in this RC is one we actively want, and the daemon failure is the only thing keeping us on 0.9.0.
7. DeusData commented on Aug 4, 2026

   

   DeusData

   on Aug 4, 2026

   Owner

   More actions

   Update: reproduced deterministically on our Windows test VM, and the root cause is now clear.

   What actually fails: the activation transaction's Windows ACL safety check refuses any directory tree carrying cross-account mutation grants — and that includes the stock NT AUTHORITY\Authenticated Users:(M) inheritance that every directory created directly under a drive root picks up (most secondary-drive paths, many custom install roots). The refusal was recorded internally but the surfaced error blamed active sessions — which is why killing processes, rebooting, and hunting handles (both here and in @patxisan's report) could never help. The --dry-run success is consistent: it doesn't run the transaction.

   Landed: #1449 makes the error name the real check, the flagged SID and path, and the remediation — no more phantom-session hunts. daemon start/MCP serve failures against such trees print the specific DACL-entry refusal too (that's @patxisan's "could not start within 30000 ms" path surfacing properly).

   Workaround until the next build: put both the install dir and CBM_CACHE_DIR under your user profile (e.g. %USERPROFILE%\.local\bin and %USERPROFILE%\.cache), or remove the inherited grant from the custom tree: icacls <dir> /inheritance:d then icacls <dir> /remove:g "Authenticated Users".

   Under consideration: whether the gate should tolerate ancestor-inherited grants when the final directory itself is owner-private with a protected DACL — that would make default secondary-drive installs work out of the box. It's a deliberate security-posture question, so it gets decided explicitly rather than slipped into a fix.

   And @patxisan — thank you for the exceptional report: the binary-overwrite recovery procedure, the ruled-out list, and the separation of the two failure messages saved real diagnosis time. The "keep a copy of the outgoing binary" gap in install.ps1 is noted as a follow-up too.
8. DeusData commented on Aug 4, 2026

   

   DeusData

   on Aug 4, 2026

   Owner

   More actions

   Resolution on the open question from my last comment: the strict permission gate stays as-is by design. We looked hard at loosening it for ancestor-inherited grants, and decided against it for now — the gate is what stops another local account from tampering with the tree CBM executes and stores its graph in, and we would rather refuse loudly than relax that boundary in a release candidate.

   So what ships is the honest error (#1449): CBM now names the exact check that refused, the SID and path involved, and what to do about it — instead of blaming CBM sessions that were never running.

   What that means for you concretely. Directories created directly under a drive root (C:\, D:\, most secondary drives) inherit NT AUTHORITY\Authenticated Users:(M) from the root, and CBM will refuse those. Two supported layouts:

   1. Simplest — keep everything under your profile:

      codebase-memory-mcp install -y --dir="%USERPROFILE%\.local\bin"
      setx CBM_CACHE_DIR "%USERPROFILE%\.cache\codebase-memory-mcp"
      

   2. Keep your custom location, remove the inherited grant once:

      icacls "D:\your\dir" /inheritance:d
      icacls "D:\your\dir" /remove:g "Authenticated Users"
      

      (Note: if a corporate policy re-applies the inherited ACE, option 1 is the durable choice.)

   Thank you both — @jayeshh-1 for the original report with the full ruled-out list, and @patxisan for the independent reproduction, the checksum verification, and especially the working recovery procedure. That evidence is what let us pin this to the ACL check rather than the session machinery, and your "keep a copy of the outgoing binary" observation about install.ps1 is tracked as a separate follow-up.
9. patxisan commented on Aug 5, 2026

   

   patxisan

   on Aug 5, 2026

   More actions

   Thank you for turning this around so quickly — reproduced on a test VM, root-caused, and shipped an honest error inside two days is genuinely impressive, and the decision in the second comment is the right one. Refusing loudly beats relaxing a boundary that stops another local account from tampering with the tree CBM executes from, and saying so explicitly rather than quietly widening the gate is the part I'd have got wrong.

   The diagnosis also explains something that had bothered me: the recovery I posted worked by replacing the binary, never by clearing state. That fits a check refusing a tree, and not at all a session that needed stopping.

   One data point before the next build, because I think my case may not be the same as @jayeshh-1's.

   I checked for the inherited grant on this machine and every level of the chain is clean — no Authenticated Users and no Everyone with Modify/Write/FullControl on any of:

   C:\Users
   C:\Users\<me>
   C:\Users\<me>\.local            C:\Users\<me>\.cache
   C:\Users\<me>\.local\bin       C:\Users\<me>\.cache\codebase-memory-mcp
   %LOCALAPPDATA%\Programs\codebase-memory-mcp
   

   Both the install dir and the cache were already under the user profile — layout (1) of your workaround — before the failure, not moved there afterwards. So on this box the daemon refused with CBM daemon could not start within 30000 ms (CLI and MCP stdio) with no cross-account mutation grant anywhere for the gate to have found.

   That may mean a second path to the same symptom, or that the gate refuses on something else here. Either way it seemed worth saying rather than letting the ACL explanation be assumed to cover both reports.

   Happy to run whatever diagnostic helps once #1449 is in a build — the named check, SID and path should settle it immediately, which is exactly why that change is the useful one. Nothing to apply on my side yet: the latest release is still v0.9.1-rc.1 (2026-07-30), so #1449 is in the repo but not installable, and this machine stays on 0.9.0 via the binary-replacement recovery.

   No rush from us — 0.9.0 is serving fine, and the WAL growth of #1083 is held off meanwhile by an hourly wal_checkpoint(TRUNCATE) scheduled task. Thanks again for the speed and for the write-up quality; the two comments together are a better bug report than my original.
10. DeusData

    added a commit that references this issue on Aug 5, 2026

    Merge pull request #1449 from DeusData/fix/1416-activation-refusal-at…

    ...

    c9bbd88
11. JadeCong

    added a commit that references this issue on Aug 5, 2026

    fix(cli): attribute activation refusals to the recorded safety check (D…

    ...

    2044c5c
12. patxisan commented on Aug 6, 2026

    

    patxisan

    on Aug 6, 2026

    More actions

    Correction: my "every level of the chain is clean" was wrong, and I owe you an apology

    I need to retract a data point I gave you on 2026-08-05. It pointed your debugging away from an ACL cause, and it was based on an incomplete check.

    What I actually found, on this same machine, yesterday (running 0.9.0, not the RC):

    C:\Users\<me>\.cache\codebase-memory-mcp        inheritance DISABLED, 1 explicit ACE:
                                                    <me>: FullControl, InheritanceFlags: None
    C:\Users\<me>\.cache\codebase-memory-mcp\logs   inheritance ENABLED, 0 ACEs  ← empty DACL
    

    The parent has inheritance disabled and its single ACE carries no propagation flags, so it applies to that folder only. The child has inheritance enabled but there is nothing to inherit. The result is an empty DACL: nobody has access, including the owner. ls on it returned Permission denied, and icacls printed the path with no ACEs at all.

    Why my earlier report missed it. I enumerated the chain upwards — C:\Users, the profile, .local, .local\bin, .cache, %LOCALAPPDATA%\Programs\... — looking for the inherited Authenticated Users / Everyone grant your workaround describes. I checked for the presence of a wrong grant and never checked for the absence of any grant, and I never descended into logs/, which is where the index worker writes its response file. So "every level of the chain is clean" was true of the levels I looked at and false of the tree.

    That is my error, not an ambiguity in your instructions. Sorry — an ACL bug report that says "not ACLs here" is worse than no report.

    What I can and cannot claim.

    I can say the empty DACL was real and that it hid evidence: with logs/ unreadable I could not see worker output at all, which is why my earlier diagnosis had to be inferred rather than read. After granting inheritance (icacls ... /grant "<me>:(OI)(CI)F" /T) the directory became readable and the worker response files were there.

    I cannot say it caused the daemon failure in this issue. That failure was 0.9.1-rc.1, and I have been on 0.9.0 throughout the work where I found this. I have not reinstalled the RC since fixing the permissions, so I have no evidence either way.

    So please treat my "our case may be a second path to the same symptom" as withdrawn, rather than as evidence for a different root cause. It may still be a second path — I simply no longer have grounds to assert it.

    Happy to re-test the RC now that the chain is fixed, if that is useful to you. I saw #1449 is merged; whenever it lands in a build I can run it on a machine where the ACL state is known-good this time, and report the named check / SID / path output you added.
13. 1 remaining item

    Load more
14. DeusData

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

    fix(cli): stop blaming sessions for a failure that has none (#1537)

    ...

    ff853ac
15. samuelasu commented on Aug 12, 2026

    

    samuelasu

    on Aug 12, 2026

    More actions

    Same phantom-session error, but on Linux, on a fresh install (not an upgrade of a running daemon) — posting here rather than a new issue since the surfaced text is identical to the original report, but wanted to flag that the root cause explained above (Windows ACL inheritance / NT AUTHORITY\Authenticated Users:(M)) doesn't apply to this platform, so it may be a second code path hitting the same "blame the session machinery" fallback.

    Version

    codebase-memory-mcp 0.10.2 (release archive, codebase-memory-mcp-linux-amd64-portable.tar.gz)

    Platform

    Linux Mint 22.3 (zena), kernel 6.17.0-40-generic, x86_64. Not Windows, no ACLs involved — standard POSIX permissions throughout.

    Install channel

    install.sh from the release, and also the extracted binary's own install subcommand run directly (same result both ways).

    What happened

    install.sh --skip-config (and codebase-memory-mcp install -y --force --dir=<path> --skip-config run directly) fails every time with:

    error: active CBM sessions and operations could not be stopped safely; no activation was committed.
    error: run 'codebase-memory-mcp daemon status' to list the client processes still holding the daemon (MCP servers started by your editor or agent are the usual holders), close them, then retry.
    

    install --dry-run with the same args succeeds cleanly every time — consistent with what's described above (dry-run doesn't run the transaction).

    Ruled out

    • No codebase-memory-mcp process running (ps aux clean before every attempt).
    • No related Unix sockets (ss -x / ss -xlp, no match).
    • No lock/pid files anywhere on the filesystem (find / -xdev -iname "*codebase-memory*" from /, only the binary itself and its own cache DB turn up).
    • Target install dir (~/.local/bin) and source/staging dir both chmod 755, owner samuel:samuel, no group/world-writable bits, no unusual ACLs (this is stock ext4 with default POSIX permissions, no setfacl ever used on this box).
    • Moved the pre-existing ~/.cache/codebase-memory-mcp/ aside entirely (see below for why it existed) and retried on a completely clean cache dir — same error, so it isn't about stale content in that directory.
    • Retried with the sandboxing layer of the coding-agent shell I was working from disabled (i.e. as close to a plain unrestricted shell as I could get on this machine) — same error.

    A second, different internal error from the same binary

    Separately, codebase-memory-mcp daemon status (mentioned in the remediation text above) does not return the diagnostic info it's pointing users toward. It either hangs indefinitely (had to timeout it), or — once — returned before timing out with a completely different internal error:

    codebase-memory-mcp: exact executable identity could not be verified (cache-private) - /home/samuel/.cache/codebase-memory-mcp: ancestry component validation failed (errno 17)
    

    That's EEXIST, which is an odd errno for a validation failure, and I couldn't find any file/lock explaining an EEXIST anywhere in that tree (empty config table in _config.db, no logs/ dir yet, nothing hidden). This suggests daemon status itself is hitting a bug rather than actually reporting real session holders, which would explain why the remediation step in the original error message can't help here the way it's meant to.

    Context that might matter

    An older release (npm-distributed [email protected], presumably from testing this project a while back) was already present on this machine and had already written to the default cache path before I attempted the 0.10.2 install. I don't know if 0.6.1 ever registers itself anywhere that 0.10.2's pre-install check might be trying to reach (it predates the "session coordination daemon" architecture, as far as I can tell from its --help, which has no daemon subcommand at all). Worth checking whether the gate is trying to contact something that a pre-daemon-era install left behind, since — unlike the Windows ACL case — there's no permission boundary here for it to be legitimately refusing.

    Happy to run any diagnostic build or provide more info — this machine reproduces it reliably and isn't in active use for anything time-sensitive right now.
16. DeusData

    added a parent issue on Aug 12, 2026

    • task: UX, install, watcher, docs & small features (15 issues) #396
17. DeusData commented on Aug 13, 2026

    

    DeusData

    on Aug 13, 2026

    Owner

    More actions

    @samuelasu — this is an outstanding report, and your instinct is right on both counts: it is a second code path reaching the same "blame the session machinery" fallback, and the errno is meaningless.

    The errno is fabricated, and that is a bug we fixed in v0.10.3. That refusal branch set no error code, so the reporting fell back to printing whatever errno happened to hold from an earlier, successful call. 17 (EEXIST) is exactly what a normal mkdirat on an already-existing directory leaves behind — so the number told you a directory existed, not why anything was refused. @listepo hit the same path on macOS and was handed 2 (ENOENT) and went hunting a missing file that was there all along. In v0.10.3 that branch names the directory and the rule that refused it instead of inventing a number.

    So the single most useful thing now is a re-run on v0.10.3. Not because we think the upgrade fixes your refusal — your permissions (755, samuel:samuel, no ACLs) are not what the group-writable relaxation in that release addresses — but because the message will finally say which rule fired. That is the fact none of us has had, and it is why this issue has stayed open through several theories.

    codebase-memory-mcp install -y --force --dir=<path> --skip-config 2>&1 | tail -5

    Two other things your report surfaced, both now tracked:

    1. daemon status hanging is its own bug, and a nasty one: it is the remediation our own error message points at. An error that tells you to run a command that hangs is worse than no advice. The same class of mistake as the v0.10.2 message that told people to run a binary they had just uninstalled.

    2. Your 0.6.1 hypothesis is worth checking and I have not ruled it out. 0.6.1 predates the daemon architecture entirely, so it registers nothing the 0.10.x gate would contact — but it did write to the same default cache path, and "an old layout in a path a new validator walks" is exactly the shape that produces an unexplained refusal. Since you moved the cache aside and still reproduced, that points away from content and toward the walk itself.

    On the Windows half of this issue: we root-caused a Windows-specific cause today that fits the original report exactly — the ownership check compared against the token's user SID while Windows stamps newly created objects with the token's owner SID, which for any Administrators-group account is BUILTIN\Administrators. That made us refuse files we had just created ourselves, permanently, with a reboot changing nothing. Fix in PR #1583. That will not explain your Linux case, which is why yours needs the v0.10.3 message to progress.

    Thank you for the ruled-out list — ss -x, the filesystem-wide find, the clean-cache retry and the sandbox-disabled retry between them eliminated most of what we would have asked you to check first. This is now in our active fix batch.
18. DeusData commented on Aug 13, 2026

    

    DeusData

    on Aug 13, 2026

    Owner

    More actions

    The Windows half of this is fixed on main — commit 0215e9b4 (PR #1583).

    If your original failure was on an Administrators-group account, this is very likely your root cause: the ownership check compared against the token's user SID while Windows stamps newly-created objects with the token's owner SID (BUILTIN\\Administrators for admins). That made us permanently refuse files we had just created — which matches your report exactly, including the reboot changing nothing and Process Explorer showing no handles.

    @samuelasu's Linux case is a different path and stays open; the v0.10.3 message will name the rule that refuses there.
19. DeusData commented on Aug 13, 2026

    

    DeusData

    on Aug 13, 2026

    Owner

    More actions

    @samuelasu, thank you again for the Linux diagnostics. Could you open a separate Linux issue using the exact v0.10.3 refusal message and link back to #1416?

    This issue now has a concrete Windows root cause and fix: the owner check compared the token user SID with objects stamped using the token owner SID, fixed by 0215e9b4 in PR #1583. Your Linux permissions and refusal path are different, and keeping them in the same thread risks the Linux bug being closed with the Windows fix.

    The ruled-out list and command output you already posted can be copied directly; no new investigation is required before opening it. Thank you for helping us keep the two platform paths precise.
20. pull

    added a commit that references this issue on Aug 13, 2026

    fix(cli): show the check that refused, instead of pointing at nothing (…

    ...

    ab56859
21. DeusData commented on Aug 14, 2026

    

    DeusData

    on Aug 14, 2026

    Owner

    More actions

    @jayeshh-1, @patxisan, @samuelasu — thank you, all three of you. The original ruled-out list, the independent reproduction with a working binary-overwrite recovery, the retraction that most people would not have bothered to write, and the Linux ss -x / find -xdev sweep together turned a message blaming phantom sessions into something we could actually chase.

    Honest status. The Windows Administrators-group path is fixed on main (commit 0215e9b4, PR #1583), and the refusal no longer blames sessions that were never running. The non-Windows reservation failure @samuelasu hit is still open and not yet root-caused — I am not going to imply otherwise.

    Tonight's v0.10.5 is being cut for the issues that stop cbm being operable at all, and this is in that set. Sorry that "replace the binary and hope" has been the state of the art here for as long as it has.
22. DeusData commented on Aug 14, 2026

    

    DeusData

    on Aug 14, 2026

    Owner

    More actions

    @patxisan — your empty-DACL finding on .cache/codebase-memory-mcp/logs may be the most valuable thing anyone has reported this week, and it is bigger than this issue.

    You found the log directory's parent had inheritance disabled with a single non-propagating ACE, so children inherit nothing and not even the owner can read them. We have six separate reports — #1145, #1130, #1132, #1450, #1133, #1070 — where an indexing worker dies and the worker log is 0 KB. Every one of them has been unreproducible precisely because there is no log to read.

    If the log file is being created under a directory whose DACL grants nobody anything, then "the worker wrote nothing" and "the worker wrote something nobody can read" are indistinguishable from the outside — and we have been chasing the wrong one for a month.

    That is the same defect class as #1351/#1601: a protected DACL carrying a non-inheritable ACE, so every child is born unusable. The cause was fixed forward-only in v0.10.3, and a repair for already-damaged children is up as PR #1636.

    Thank you also for retracting your earlier "the chain is clean" data point rather than leaving it standing. Withdrawing your own evidence when you find it was wrong is genuinely rare and it saved us from building on it.

    Two follow-ups from your report that we are acting on:

    • @samuelasu reproduced the phantom-session error on Linux (v0.10.2, no ACLs involved), so the Linux half of this is a distinct mechanism from the Windows half that fix(windows): accept the owner Windows actually stamps on what we create (#1580, #1582) #1583 fixed in v0.10.4. We asked for a separate issue and never filed it ourselves — that was our omission, not his.
    • We are making the worker log flush a startup header and name each file as it is processed, so the next crash names the file that caused it instead of leaving an empty file.

    Sorry this has taken so long, and thank you for the persistence.
23. DeusData commented on Aug 17, 2026

    

    DeusData

    on Aug 17, 2026

    Owner

    More actions

    The last open piece of this landed on main in c1a5de3 (PR #1685), shipping in v0.10.6: children of the runtime/cache tree left unusable by the pre-v0.10.3 PROTECTED non-inheritable DACL — your empty-DACL logs directory finding — are now detected and repaired in place once the parent is verified secure (empty DACL or foreign owner ⇒ restamped to the canonical owner-only descriptor). That finding also explained a month of "0 KB worker log" reports (#1145 #1130 #1132 #1450 #1133 #1070): the workers wrote logs nobody could read. The install/uninstall/doctor stop-failures themselves were fixed in earlier 0.10.x releases; with the repair in place, machines damaged by the old regime self-heal on next start. Thank you for the ACL dump that turned six unreproducible reports into one root cause.
24. DeusData

    closed this as completedon Aug 17, 2026
25. pull

    added a commit that references this issue on Aug 17, 2026

    fix(windows): conditional DACL re-stamp + damaged-children repair

    ...

    47bd4b6
26. pull

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

    fix(cli): name the check that refused, and a remedy that can remove it

    ...

    7349063
27. daidaiJ

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

    fix(cli): name the check that refused, and a remedy that can remove it

    ...

    a1aed93

    fix(cli): name the check that refused, and a remedy that can remove it

    ...

    b741509