mirror of
https://github.com/DeusData/codebase-memory-mcp.git
synced 2026-10-03 05:18:26 +08:00
Martin Vogel
c86be38954
README.md:132, README.md:633, README.md:761, and docs/CONFIGURATION.md:203 said one-shot `cli` commands "never start or connect to the coordination daemon" / read "their own environment without starting the daemon". That was already contradicted a few lines above it (README.md:126 lists one-shot CLI commands among the processes that "share a crash-safe OS admission barrier" with the daemon) and by the code: main_local_cli_daemon_execute() (src/main.c) bootstraps a client connection to the shared per-user coordination daemon via main_client_bootstrap_with_upgrade(), spawning one (bootstrap.daemon_spawned) when none is running, before dispatching the tool call. Verified live: `cli --verbose list_projects` against an isolated HOME/CBM_CACHE_DIR/CBM_RUNTIME_DIR printed "hint: this command started a temporary CBM daemon", and its cbm-daemon.log showed daemon.start -> daemon.runtime_stopping (reason=last_committed_client_disconnected) -> daemon.lifetime_end, i.e. the daemon it spawned exited again once the CLI command's own connection closed. bootstrap_production_spawn() passes the calling process's `environ` straight to posix_spawn(), so a CLI invocation that starts the daemon also seeds that daemon's captured daemon-owned environment (CBM_DIAGNOSTICS, CBM_LOG_LEVEL, etc.) - it does not read "its own environment" independently as the docs claimed. Corrected all four passages to state the real behavior: CLI commands connect to the shared daemon (starting one if none is running) for the same admission barrier and per-project locks, hold a `cli_session` that is never registered with the background watcher, and - if their own connection is what started the daemon - that daemon exits again once the command's connection closes and no other session is attached. No opt-out env var or flag for an in-process/no-daemon CLI mode exists (grepped the whole tree), so none is documented. This is a pure documentation fix; no production behavior changed. Kept clear of PR #2348 (fix/issue-2167), which separately rewrites the watcher-scope paragraph at README.md:152/237/672 and docs/CONFIGURATION.md:88 for issue #2167's auto-sync-scope correction - none of the lines here overlap with that diff. Refs #2183, #2167 Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
