Stale rendezvous directory (`/tmp/cbm-daemon-<uid>`) permanently blocks `install`/`update` with "active CBM sessions ... could not be stopped safely" after hard-killed CBM processes

[hansinator85]

Version

codebase-memory-mcp 0.10.8

Platform

macOS (Apple Silicon)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

Title

Stale rendezvous directory (/tmp/cbm-daemon-<uid>) permanently blocks install/update with "active CBM sessions ... could not be stopped safely" after hard-killed CBM processes

Summary

After several long-lived codebase-memory-mcp MCP server processes were terminated non-gracefully (pkill, no clean shutdown), every subsequent codebase-memory-mcp install and codebase-memory-mcp update call failed permanently with:

Stopping active CBM sessions and operations for install...
error: active CBM sessions and operations could not be stopped safely; no activation was committed.
error: something is still using CBM. If an editor or agent is running an MCP server, close it and retry; 'codebase-memory-mcp daemon status' lists the holders when a cbm binary is still installed.

This happened even though every process-level and file-lock check came back completely clean:

• ps aux | grep codebase-memory-mcp → no matches
• codebase-memory-mcp daemon status → daemon: not running
• lsof +D ~/.cache/codebase-memory-mcp → no open handles
• No *.lock, *.pid, or *.sock files under ~/.cache/codebase-memory-mcp
• No matching launchctl list entries / no LaunchAgent plist
• No stray files under $TMPDIR (the per-user /var/folders/.../T/ directory)

The installer's own diagnostics (daemon status, the error message itself) only ever point at "an editor or agent running an MCP server" — i.e. a process-level explanation — which sent us down the wrong debugging path for a long time. The actual blocker is stale on-disk coordination state, not a live process.

Environment

• OS: macOS (Apple Silicon / arm64)
• Shell: zsh
• Install method: official install.sh (curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash), binary at ~/.local/bin/codebase-memory-mcp
• Affected versions: reproduced going from 0.10.1 → 0.10.8, and again fresh on 0.10.8 → 0.10.8 (re-running install to repair a corrupted agent config, see "related issue" below)
• ~25 indexed repositories, several coding-agent integrations detected (Claude Code, Codex CLI, VS Code, Junie, OpenHands, GitLab Duo CLI)

Suggested fixes

1. Self-heal stale/unverified version-cohort claims. If a claim in cbm-version-cohort-*-v1.lock has no live process associated with it (e.g. via flock/holder-PID liveness check), it should be treated as abandoned and cleared automatically, rather than blocking indefinitely.
2. Improve the error message to name the actual rendezvous directory and file(s) it's stuck on (similar to what v0.10.5's release notes describe doing for the Windows "directory that actually refused" case), instead of only suggesting "an editor or agent is running an MCP server."
3. Document the rendezvous directory and CBM_RUNTIME_DIR in docs/CONFIGURATION.md — currently CBM_RUNTIME_DIR is only mentioned in one release's changelog.
4. Provide a supported reset command, e.g. codebase-memory-mcp daemon reset-coordination or similar, instead of requiring users to manually locate and rm -rf an undocumented /tmp directory.
5. Consider whether daemon status (which correctly reported "not running") should also inspect this rendezvous directory and warn about orphaned/unverified cohort claims even when no daemon process exists.

Workaround (for anyone hitting this)

# 1. Make sure nothing is actually running:
ps aux | grep -i codebase-memory-mcp
codebase-memory-mcp daemon status

# 2. If truly nothing is running but install/update still fails with
#    "active CBM sessions and operations could not be stopped safely":
rm -rf /tmp/cbm-daemon-$(id -u)

# 3. Retry:
codebase-memory-mcp install

Related

• Installer/updater scope and safety: no per-client selector, destructive update step before an interactive prompt, hidden ui_enabled, brittle legacy-marker cleanup #1558 covers a different but adjacent installer-robustness gap in the same install/update pipeline (brittle legacy hook-marker cleanup causing agent_config ... op=legacy_hook_cleanup / ambiguous_hook_ownership failures on Codex CLI's config.toml). We hit that one too, in the same troubleshooting session, right before hitting this one — the two are independent bugs but both erode trust in install/update being safe to just "run again."

Reproduction

Steps to reproduce

1. Have several coding-agent sessions running that each spawn their own codebase-memory-mcp MCP server subprocess over stdio (no shared daemon — daemon status reports "not running" the whole time).
2. Let those parent editor/agent windows terminate abnormally (in our case, likely closed without the MCP child process being reaped — we found 15 orphaned codebase-memory-mcp processes, several days old, each with hundreds of CPU-minutes accumulated).
3. Terminate them non-gracefully:

   pkill -f "/Users/<user>/.local/bin/codebase-memory-mcp"
   

4. Run codebase-memory-mcp install (or update). It fails with the error above.
5. Confirm there is genuinely nothing left holding CBM open (steps listed in the Summary). The error persists indefinitely regardless.

Root cause (found via fs_usage)

Since neither the CLI's own diagnostics nor CBM_DIAGNOSTICS=true / CBM_LOG_LEVEL=debug surfaced the actual path being checked (the process exits before the periodic diagnostics writer ever runs), we traced the failing install invocation with:

sudo fs_usage -w -f filesys codebase-memory-mcp

This revealed a per-UID rendezvous/coordination directory that is not documented anywhere in docs/CONFIGURATION.md and is separate from ~/.cache/codebase-memory-mcp:

/private/tmp/cbm-daemon-<uid>/

containing (anonymized, real trace excerpt, timestamps/PID trimmed):

srw-------  cbm-<hash>.anc
-rw-------  cbm-<hash>.lifetime.lock
-rw-------  cbm-<hash>.lock
srw-------  cbm-<hash>.sock
-rw-------  cbm-<hash>.startup-v2.lock
-rw-------  cbm-version-cohort-admission-v1.lock
-rw-------  cbm-version-cohort-daemon-v1.lock
-rw-------  cbm-version-cohort-lifetime-v1.lock   (214 bytes — the only non-empty file)
-rw-------  cbm-version-cohort-maintenance-v1.lock

and, matching this, CBM_LOG_LEVEL=debug on a plain codebase-memory-mcp cli ... invocation (no install) printed:

level=info msg=version_cohort.claimed_unheld build=<sha>
codebase-memory-mcp: CBM CLI could not start because a pre-coordination or unverified CBM generation is active; close all CBM sessions and commands, then retry

Our reading: each CBM process "claims" a version-cohort slot in this directory for its generation/build, and expects a follow-up step to mark that claim as "held"/verified. When a process is killed abruptly (SIGKILL/hard pkill, or a crash — we also found a stale ~/Library/Application Support/CrashReporter/codebase-memory-mcp_*.plist), that follow-up never runs, and the claim is left dangling in cbm-version-cohort-lifetime-v1.lock / cbm-version-cohort-admission-v1.lock forever. Every later install/update/cli invocation sees an "unheld"/unverified claim and refuses to proceed, because from its perspective it cannot prove no other generation is mid-transition — even though, in reality, nothing is running anymore and the claim is simply orphaned.

Confirmed as the actual cause: removing the directory entirely resolved the issue immediately and permanently.

rm -rf /tmp/cbm-daemon-<uid>
codebase-memory-mcp install   # now succeeds

We also found that CBM_RUNTIME_DIR (mentioned only in the v0.10.5 release notes, not in docs/CONFIGURATION.md) can point this coordination logic at a fresh directory as a workaround without touching the default one — useful for anyone who wants to unblock install without deleting the existing rendezvous directory outright:

CBM_RUNTIME_DIR=/tmp/cbm-runtime-clean codebase-memory-mcp install

Note, though, that this creates a split-brain: install then commits its "verified generation" state under the custom CBM_RUNTIME_DIR, while any later plain invocation (cli, an editor's MCP server launch, etc.) that does not set CBM_RUNTIME_DIR falls back to the still-broken default directory and immediately hits the same version_cohort.claimed_unheld / "pre-coordination or unverified CBM generation is active" error. CBM_RUNTIME_DIR is only a safe workaround if set consistently everywhere, or as a stepping stone before clearing and returning to the default directory (which is what ultimately fixed it for us).

Why this was hard to diagnose

The error message and daemon status hint entirely at live processes ("something is still using CBM... an editor or agent is running an MCP server... daemon status lists the holders"). There is no mention that:

• a per-UID directory under /tmp holds durable cross-run coordination state independent of any running process,
• that state can be inspected or reset via any documented command,
• CBM_RUNTIME_DIR exists and affects this exact code path.

This sent us through a long, unproductive diagnostic chain (checking ps, lsof, launchctl, SQLite WAL files, license/session theories, etc.) before fs_usage tracing revealed the real location.

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

No response

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.