Session Coordination Daemon · codebase-memory-mcp 繁中教學站

為什麼要 daemon

你在 Claude Code、Codex、OpenCode 各開一個 session 都用 CBM——如果每個 session 各跑各的 watcher、各自索引、各自開 UI，就是浪費。CBM 用每帳號一個協調 daemon解決：

第一個 daemon-backed session 啟動它，每個 session 註冊自己的 work，最後一個 session 關閉它。
daemon 擁有長駐背景服務：watchers、共享索引 jobs、可選的 UI。
關掉一個 session 只取消「它擁有的 work」；其他 session 還需要的 work 繼續。

daemon 不依賴 MCP frontend 的 stderr

daemon 是 detached 的，它把事件寫到 owner-only 的 durable records（${CBM_CACHE_DIR}/logs）：

檔案	內容
`cbm-daemon.log`	daemon lifecycle、watcher/indexing、UI、resource、error 事件
`daemon-conflicts.ndjson`	exact-build、coordination-ABI、cache-root admission 衝突
`activation-events.ndjson`	install/update/uninstall 的 activation 進度與結果

exact-build admission barrier

所有 active 的 CBM process 必須：完全相同版本 + 相同 executable build + 相同 coordination ABI + 相同 canonical cache root。等效的 CBM_CACHE_DIR alias 解析到同一個 root；真正不同的 root 在還有 CBM process active 時被拒絕。衝突會被記錄到 daemon-conflicts.ndjson。

為什麼：不同版本的二進位對同一份 SQLite 圖做讀寫，會產生 ABI/格式衝突——admission barrier 讓「混版狀態」在做事之前就失敗，而不是讓資料壞掉。

CLI 模式刻意分離

codebase-memory-mcp cli <tool> 是單次指令：不啟動也不連 daemon、不註冊 session、不啟動 watcher/UI。唯一的共享狀態是 OS admission barrier 與 per-project locks（防止同專案並行寫入衝突）。指令跑完就結束，不留常駐 process。

更新與 daemon

native install/update/uninstall 是衝突規則的刻意例外：先下載/驗證/暫存好，然後才發布維護意圖、要求 daemon 與所有暫時性操作取消、等所有 process 退出、獨佔 admission/lifetime barriers 更換二進位。成功後會提示你重啟 agent session 以載入新 build。

套件管理器（npm/PyPI/Go）只發布該套件的私有快取二進位，不會停止執行中的 session——該二進位執行時仍進同一個 admission barrier。

看完這頁你應該能說出：daemon 解決了什麼共享問題、admission barrier 為何要求 exact-build、CLI 為何刻意不連 daemon、以及更新流程「先備好再換」的安全順序。