Conversation
…aemon (#2183, #2167) 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>
DeusData
force-pushed
the
docs/cli-daemon-behavior
branch
from
September 30, 2026 22:34
99ccc7d to
c86be38
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
README.md and docs/CONFIGURATION.md said one-shot
clicommands "never start or connect to the coordination daemon" in three places (README.md:132, 633, 761) and one more in docs/CONFIGURATION.md:203. That was already contradicted a few lines above (README.md:126 lists one-shot CLI commands among the processes sharing the admission barrier with the daemon) and by the code:main_local_cli_daemon_execute()bootstraps a client connection to the shared per-user daemon, spawning one if none is running, before dispatching the tool call.Verified live with an isolated HOME/CBM_CACHE_DIR/CBM_RUNTIME_DIR:
cli --verbose list_projectsprinted "this command started a temporary CBM daemon", and the daemon log showed it start and then exit again once the CLI command's own connection closed (no other session attached). So CLI commands do connect to (and may start) the shared daemon, and a daemon they had to start themselves does not outlive the command.Also corrected the related environment-capture claim:
posix_spawn(..., environ)inbootstrap_production_spawn()means a CLI invocation that starts the daemon seeds that daemon's captured environment, rather than the daemon reading its own environment independently.Documentation only; no behavior change. No line overlap with the watcher-scope docs in #2348.
Refs #2183 #2167