Repository navigation
CBM_CACHE_DIR ignored; daemon still requires /private/tmp/cbm-daemon-<uid> on macOS #1621
Description
Version
built-from-source (unknown)
Platform
macOS (Apple Silicon)
Install channel
GitHub release archive / install.sh / install.ps1
Binary variant
standard
What happened, and what did you expect?
I set CBM_CACHE_DIR to a per-user cache directory (e.g. $HOME/.cache/codebase-memory-mcp), but the daemon still fails to create a secure endpoint under /private/tmp/cbm-daemon-. The binary reports that an ancestor directory is not a usable private-directory parent.
Reproduction
- export CBM_CACHE_DIR="$HOME/.cache/codebase-memory-mcp"
- mkdir -p "$CBM_CACHE_DIR" && chmod 700 "$CBM_CACHE_DIR"
- codebase-memory-mcp
Observed: the process exits with an error about /private/tmp/cbm-daemon- not being a usable private-directory parent.
Expected: the program should honour CBM_CACHE_DIR and use that path for cache/runtime artifacts, or at least document why /private/tmp is still required and provide a way to override the runtime parent.
Logs
{"jsonrpc":"2.0","id":null,"error":{"code":-32001,"message":"secure daemon endpoint could not be created: /private/tmp/cbm-daemon-501: ancestor 'cbm-daemon-501' is not a usable private-directory parent (must be owned by you, not world-writable, and carry no allow-ACL)"}}
codebase-memory-mcp: secure daemon endpoint could not be created: /private/tmp/cbm-daemon-501: ancestor 'cbm-daemon-501' is not a usable private-directory parent (must be owned by you, not world-writable, and carry no allow-ACL)
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 14, 2026
Thanks for filing this with the exact error text, @Carnival-z — quoting
ancestor 'cbm-daemon-501' is not a usable private-directory parentalongside the fact that you had alreadychmod 700'd your cache directory told us immediately that relocating the cache was never going to help you.You are right on both counts. The daemon rendezvous parent is separate from
CBM_CACHE_DIR, and in a product build there is currently no supported way to move it: the only override lives behind a compile-time test seam, so it does not exist in the binary you are running. That leaves you with a process that refuses to start and no lever to pull, which is not an acceptable place to leave anyone.This is a top item for tonight's v0.10.5, which is being cut specifically for the issues that make cbm impossible to operate. The same gap is reported on Windows in #1574, and whatever lands will need to cover both. Sorry for the wasted setup time.
fix(daemon): name the directory that actually refused, not the one af…
fix(daemon): let a shipped build relocate the rendezvous via CBM_RUNT…
DeusData commentedon Aug 17, 2026
Verified fixed: since #1645 (7f3e30e, shipped in v0.10.5) a product build honours
CBM_RUNTIME_DIRfor the daemon rendezvous parent — the compile-time-seam-only limitation this issue reported is gone. End-to-end on macOS:CBM_RUNTIME_DIR=$HOME/.cbm-runtime(0700) +daemon start→ endpoint created under it, daemon up, no /private/tmp requirement. Two notes for anyone landing here: the relocated parent goes through the same strictness checks (owned by you, not world-writable, no allow-ACL — the check names the ancestor that refused since daac6bd), andCBM_CACHE_DIRremains a separate knob for cache artifacts, as you correctly diagnosed. Thanks for the precise report with the exact refusal text — it pinpointed the missing product lever immediately.