No such xattr: com.apple.quarantine

[listepo]

Version

0.10

Platform

macOS (Apple Silicon)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

codebase-memory-mcp installer
os: darwin
arch: arm64
target: /Users/listepo/.local/bin/codebase-memory-mcp

Downloading codebase-memory-mcp-darwin-arm64.tar.gz...
######################################################################## 100.0%
Checksum verified.
Extracting...
Fixing macOS code signing...
Verified candidate: codebase-memory-mcp 0.10.0
codebase-memory-mcp install 0.10.0

xattr: /tmp/cbm-install-zRIanz/codebase-memory-mcp: No such xattr: com.apple.quarantine
/tmp/cbm-install-zRIanz/codebase-memory-mcp: replacing existing signature
codebase-memory-mcp 0.10.0
error: active CBM sessions and operations could not be stopped safely; no activation was committed.

Reproduction

codebase-memory-mcp uninstall
curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash

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.

[DeusData]

Thanks for the clear report, @listepo — the full installer transcript makes this easy to read, and it surfaced two things worth fixing.

The xattr line in the title is actually harmless — the installer tries to strip macOS's quarantine attribute and prints that message when there's none to strip (fresh download via curl doesn't always carry it). It should be silent; we'll make it so. Sorry it pointed you at the wrong suspect.

The real failure is the last line: active CBM sessions and operations could not be stopped safely; no activation was committed. The installer refuses to swap the binary while something still holds a live cbm session — most likely an MCP client (Claude Code, Codex, an editor integration) that kept a server process running through your uninstall, or a daemon it respawned. The refusal itself is safety-correct, but it has two real defects on macOS which we're treating as the bug here:

1. It doesn't tell you which processes are blocking — on Windows this same refusal lists the pids since v0.10.0 (Windows: install/uninstall/doctor all fail with "active CBM sessions and operations could not be stopped safely" #1416), and the POSIX path should do exactly the same.
2. A session that the installer could safely stop (as on Windows) should be stopped rather than failing the install.

Workaround right now: quit whatever agents/editors are using cbm (or check with pgrep -fl codebase-memory-mcp and stop those processes), then re-run the install — and grab v0.10.1 while you're at it; it fixes an important MCP output bug in 0.10.0.

If it's easy for you, the output of pgrep -fl codebase-memory-mcp from before a retry would help us confirm whether uninstall is leaving a daemon behind (that would be a second bug) — but no worries if not, we can reproduce from what you've given.

This is slated for v0.10.2, the next fix release — we've moved to small, fast fix releases, so it won't be a long wait. Thanks again for taking the time to file this!

[DeusData]

Fixed in v0.10.2, released just now: https://github.com/DeusData/codebase-memory-mcp/releases/tag/v0.10.2 (GitHub archives, npm, and PyPI are all serving it).

Please give it a try when you get a chance — if it behaves in your setup, feel free to close this out; if anything still looks off, say so and we'll pick it straight back up. Thank you again for the report, it made this fix fast and precise.

[listepo]

@DeusData xattr: /tmp/cbm-install-PqqhWL/codebase-memory-mcp: No such xattr: com.apple.quarantine
/tmp/cbm-install-PqqhWL/codebase-memory-mcp: replacing existing signature
codebase-memory-mcp 0.10.2
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.

[listepo]

codebase-memory-mcp daemon status zsh: command not found: codebase-memory-mcp

[listepo]

Even after rebooting, I couldn't find the related process

[listepo]

Everything broke after the codebase-memory-mcp uninstall command

[DeusData]

@listepo — I'm sorry. You reported this cleanly, we told you it was fixed in v0.10.2, and it isn't. Worse, the "improvement" we shipped made your situation harder: the new line tells you to run codebase-memory-mcp daemon status — a command that doesn't exist after uninstall, which is exactly when you're reading it. That was our mistake, and the fact that you rebooted, found no process, and still got blamed for "active sessions" means we sent you looking for something that was never there.

What we got wrong, concretely. The activation guard funneled two unrelated outcomes into one message:

• the coordination cohort is busy — real sessions hold it, and closing them is the fix;
• the reservation failed — lock I/O, leftover coordination state, or permissions — where nothing is running at all.

Your case is the second, and we printed the first. Same mistake we'd already fixed twice elsewhere (#1416, #1535): a non-session failure wearing a session costume. Fixed on our side for the next patch release: the two conditions now say different things, the failure one states plainly that nothing needs to be closed, and neither remedy assumes a cbm binary is on PATH.

What that fix does not do is explain your root cause — why the reservation fails when nothing is running. I tried to reproduce it (uninstall then reinstall in an isolated HOME and cache) and it completed normally, so whatever is blocking you is persistent state my machine doesn't have. To pin it, could you share:

1. ls -la "${CBM_CACHE_DIR:-$HOME/.cache/codebase-memory-mcp}" — the full listing, including any .lock, .pid, or .corrupt* entries.
2. ls -la /private/tmp/cbm-daemon-$(id -u)/ 2>/dev/null — the coordination rendezvous directory. This is the prime suspect: macOS does not reliably clear /private/tmp on reboot, so a stale artifact here would survive exactly the reboot you tried.
3. pgrep -fl codebase-memory-mcp (expected: nothing) and id -u.
4. The full installer output from a fresh attempt, with the two lines above the error included.

Unblocking you in the meantime, in order of least destructive:

rm -rf "/private/tmp/cbm-daemon-$(id -u)"      # stale coordination state only

then re-run the installer. If that doesn't do it:

mv "$HOME/.cache/codebase-memory-mcp" "$HOME/.cache/codebase-memory-mcp.bak"

and re-run — that preserves your indexes in the .bak copy while ruling the cache in or out. If either of those unblocks you, please say which: that alone identifies the culprit, and it becomes the thing we make impossible rather than merely better-worded.

(The No such xattr line is still harmless noise — it just means the download carried no quarantine attribute. We silenced it in v0.10.2; if you're seeing it from a locally saved older install.sh, that copy predates the fix.)

Thank you for staying with this and for the follow-ups — "even after rebooting" was the detail that showed our message was lying.