Repository navigation
No such xattr: com.apple.quarantine #1537
Description
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.
Activity
DeusData commentedon Aug 11, 2026
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
curldoesn'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:Workaround right now: quit whatever agents/editors are using cbm (or check with
pgrep -fl codebase-memory-mcpand 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-mcpfrom before a retry would help us confirm whetheruninstallis 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!
fix(install,daemon): unbreak npx clients, group-writable homes, and l…
fix(install,daemon): unbreak npx clients, group-writable homes, and l…
fix(install,daemon): unbreak npx clients, group-writable homes, and l…
DeusData commentedon Aug 11, 2026
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 commentedon Aug 12, 2026
@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 commentedon Aug 12, 2026
codebase-memory-mcp daemon status zsh: command not found: codebase-memory-mcplistepo commentedon Aug 12, 2026
Even after rebooting, I couldn't find the related process
listepo commentedon Aug 12, 2026
Everything broke after the
codebase-memory-mcp uninstallcommandDeusData commentedon Aug 12, 2026
@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 afteruninstall, 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:
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:
ls -la "${CBM_CACHE_DIR:-$HOME/.cache/codebase-memory-mcp}"— the full listing, including any.lock,.pid, or.corrupt*entries.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/tmpon reboot, so a stale artifact here would survive exactly the reboot you tried.pgrep -fl codebase-memory-mcp(expected: nothing) andid -u.Unblocking you in the meantime, in order of least destructive:
then re-run the installer. If that doesn't do it:
and re-run — that preserves your indexes in the
.bakcopy 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 xattrline 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 olderinstall.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.
13 remaining items
DeusData commentedon Aug 13, 2026
Thank you @listepo — and that output is exactly what I needed, because it rules out the obvious suspect and exposes a gap on our side.
Your permissions are fine.
drwx------owned by you, parentdrwxr-xr-xowned by you. No group- or world-write anywhere, so the ancestor relaxation shipped in v0.10.3 was never going to be your fix. Good to have that eliminated rather than assumed.And our new message is half-useless, which is our bug. It correctly tells you this is not a session problem — that part worked. But it then says "Check the errors above" when there are no errors above: the validation detail that names the failing component lives on the daemon side and never reaches the CLI's refusal path. So we replaced a message that blamed the wrong thing with one that blames nothing. I am fixing that propagation in the current batch; an error that says "see above" with nothing above is not much better than the fabricated errno it replaced.
One command would give us the answer today, because that same detail does surface on the daemon path:
On v0.10.2 this printed you:
On v0.10.3 that same line now names the directory and the rule that refused it instead of inventing an errno. Whatever it prints is the root cause, and it is the one fact this issue has been missing since it was opened.
If it hangs instead of printing — a separate reporter just hit exactly that on Linux (#1416) — then say so, because that is its own bug and a serious one: it is the command our error message tells people to run.
A second thing worth trying, cheap and informative:
The
-eflag lists ACLs, which the@in your earlier output does not cover (@is extended attributes,+would be an ACL). macOS puts agroup:everyone deny deleteACL on home directories by default; our walk is supposed to accept deny-only ACLs, and if yours carries something else that is a strong candidate.Sorry this has taken three rounds. The fabricated errno cost the first one, and this "see above" gap cost the second — both ours, and both now fixed or being fixed.
Merge pull request #1588 from DeusData/fix/refusal-detail-propagation
fix(cli): show the check that refused, instead of pointing at nothing (…
listepo commentedon Aug 14, 2026
curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash
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.4
codebase-memory-mcp install 0.10.4
xattr: /tmp/cbm-install-u9huDS/codebase-memory-mcp: No such xattr: com.apple.quarantine
/tmp/cbm-install-u9huDS/codebase-memory-mcp: replacing existing signature
codebase-memory-mcp 0.10.4
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.
DeusData commentedon Aug 14, 2026
@listepo — you posted the v0.10.4 transcript this morning, and this issue is still carrying an
awaiting-reporterlabel. That is wrong, and it is ours to fix: nothing here has been waiting on you for days, and you have answered every single thing we asked.Four rounds in, we have sent you after a phantom session, a fabricated
errno, and now a "check the errors above" with nothing above it — each of those was our message lying to you, and each cost you a retry on a machine where cbm simply will not install. The reservation-failure path is being worked on right now, including getting the daemon-side validation detail through to the CLI so the refusal finally names what it refused, instead of pointing at empty space.Tonight's v0.10.5 is being cut specifically for the issues that make cbm impossible to operate, and this is at the top of that list. I am sorry it has taken this many attempts on your machine to get us a straight answer.
DeusData commentedon Aug 14, 2026
@listepo — we have been sending you to the wrong directory this entire time, and I am sorry. You were right every time you said
.cachewas fine.The refusal reads
ancestor '.cache' is not a usable private-directory parent. But the check that fails validates the directory we are already in — the parent of the one named. So when it says.cache, the directory actually refusing is/Users/listepo, your home directory. The code tested one directory and printed the name of the next one.That is why every round of this went nowhere: you inspected exactly what we named, correctly reported it was
drwx------and owned by you, and we had no idea we were pointing you one level too deep.Would you mind checking your home directory instead?
We are looking for: owned by you, not world-writable, and no ACL entries — an
+in the mode column or any0: group:everyone …line fromls -ldewould do it. Achmod -N ~clears an extended ACL if one is there.Fix for the message is up as #1646, so the next person gets the real directory named. Two other things landing that touch your case: #1645 adds
CBM_RUNTIME_DIRso the rendezvous parent can be relocated in a shipped build, and #1627 makes the CLI refusal print the validation detail instead of pointing at errors that were never printed.Thank you for staying with this and for re-confirming on v0.10.4 today rather than giving up. This one is squarely our fault — the message named the wrong variable from the day it was written.
listepo commentedon Aug 14, 2026
Fixed
listepo commentedon Aug 14, 2026
Thnaks
fix(cli): say what the agent-config target IS when a write is refused
fix(daemon): name the directory that actually refused, not the one af…
fix(cli): name the check that refused, and a remedy that can remove it
fix(cli): name the check that refused, and a remedy that can remove it
fix(cli): name the check that refused, and a remedy that can remove it