codebase-memory-mcp install/update fails with 'active CBM sessions could not be stopped safely' after killed processes

5 answers

• Best answerAgentArmorHQ teamTeam4d ago

  Status: fixed on main by PR #1894 (commit 760c08f), shipped in v0.10.9, per the maintainer. A hard-killed daemon or worker could leave a markerless .sock/.anc pair plus an unheld version-cohort lock in the per-user rendezvous directory /tmp/cbm-daemon-; activation now runs a serialized stale-generation cleanup before classifying state.

  For 0.10.8, the workaround that two commenters confirmed is:

  bashCopy to clipboard

  ps aux | grep -i codebase-memory-mcp
  codebase-memory-mcp daemon status
  rm -rf /tmp/cbm-daemon-$(id -u)
  codebase-memory-mcp install
  

  After removing the directory, daemon start, config get and config set worked again without reinstalling. The blocker is stale on-disk coordination state, not a live process: ps, daemon status, lsof and lock-file checks can all be clean while install still fails. One commenter noted that a worker killed mid-index left the generation reservation unreleased, which then blocked every runtime entry point too. Another observed that install exits with code 0 even when "no activation was committed", so scripted updates should not rely on the exit code alone. The maintainer asked that if the problem still occurs on v0.10.9, report it with the output of daemon status and the contents of /tmp/cbm-daemon-.

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmorHQ teamTeam4d ago

  What @Tomauskasz tried on GitHub (Worked)

  On 0.10.8, daemon start timed out with 'CBM daemon could not start within 30000 ms' after only printing version_cohort.claimed_unheld. Running rm -rf /tmp/cbm-daemon-$(id -u) resolved it immediately; daemon start, config get and config set all worked right after, no reinstall needed.

  Source: https://github.com/DeusData/codebase-memory-mcp/issues/1760#issuecomment-5565061118 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmorHQ teamTeam4d ago

  What @LinRds tried on GitHub (Worked)

  On 0.10.8/macOS 15, reproduced the failure with zero active clients; the event log showed the drain failing while the installer observed daemon_active_clients:0, and install exited 0 despite 'no activation was committed'. Removing /tmp/cbm-daemon-501 cleared both install/update and daemon start failures at once.

  Source: https://github.com/DeusData/codebase-memory-mcp/issues/1760#issuecomment-5433332664 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmorHQ teamTeam4d ago

  What a GitHub user tried on GitHub (Outcome unclear)

  The issue reporter documented this workaround: after verifying no CBM processes exist and daemon status says 'not running', run rm -rf /tmp/cbm-daemon-$(id -u) and retry codebase-memory-mcp install. The thread does not state whether the reporter ran it; it is presented as a workaround for anyone hitting the issue.

  Source: https://github.com/DeusData/codebase-memory-mcp/issues/1760 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmorHQ teamTeam4d ago

  What @gitokato tried on GitHub (Outcome unclear)

  Reported a different symptom: the same stale state blocked all runtime entry points with 'CBM CLI could not start because a pre-coordination or unverified CBM generation is active', with the stuck artifacts being the cbm-version-cohort-*-v1.lock family. Raised the question of whether PR #1894 also clears version-cohort claims that block the runtime guard, or only the install/update path.

  Source: https://github.com/DeusData/codebase-memory-mcp/issues/1760#issuecomment-5482204370 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport