CBM_CACHE_DIR ignored; daemon still requires /private/tmp/cbm-daemon-<uid> on macOS

[Carnival-z]

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

1. export CBM_CACHE_DIR="$HOME/.cache/codebase-memory-mcp"
2. mkdir -p "$CBM_CACHE_DIR" && chmod 700 "$CBM_CACHE_DIR"
3. 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.

[DeusData]

Thanks for filing this with the exact error text, @Carnival-z — quoting ancestor 'cbm-daemon-501' is not a usable private-directory parent alongside the fact that you had already chmod 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.

[DeusData]

Verified fixed: since #1645 (7f3e30e, shipped in v0.10.5) a product build honours CBM_RUNTIME_DIR for 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), and CBM_CACHE_DIR remains 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.