Daemon startup exceeds hardcoded 30s client-accept timeout on slow devices (Termux proot, aarch64) #2569

Environment

• Version: codebase-memory-mcp 0.11.0
• Platform: Linux (arm64)
• Install channel: GitHub release archive / install.sh
• Binary variant: standard
  (codebase-memory-mcp-linux-arm64-portable.tar.gz, release v0.11.0)

Additional context: Termux proot-distro, Ubuntu 25.10 (Questing), aarch64,
glibc 2.42, 8 CPUs, ~5.6 GB RAM. Client: opencode 1.18.35 (MCP stdio), but
also reproduced with cli directly. Installed to ~/.local/bin via
install -y --force --skip-config after manual download (the one-line
curl | bash stalls on this device's slow network).

What happened, and what did you expect?

On this device, every daemon-backed operation fails — both cli <tool> and
MCP stdio mode. The daemon needs ~28–30s+ just to publish its IPC listener,
while the client gives up at exactly 30s, so the handshake never succeeds. I
expected the client to wait long enough (or the timeout to be configurable)
so the first connection succeeds on slower devices.

Actual error (every attempt):

codebase-memory-mcp: CBM daemon is active or starting but could not accept this client within 30000 ms

--version, --help, and config list/get/set work fine — only
daemon-backed paths fail.

Reproduction

No repository needed — this fails before any indexing, on daemon startup:

1. Environment: Termux proot-distro, Ubuntu 25.10 aarch64, install v0.11.0 to
   ~/.local/bin.
2. Ensure clean rendezvous state (fresh CBM_RUNTIME_DIR).
3. Command: echo '{}' | codebase-memory-mcp cli --quiet list_projects
4. Result: exit 1 with the 30s accept-timeout error above.
   Expected: the project list (empty store is fine).

Timing evidence from polling the rendezvous dir during a single run:

• +5s … +25s: only .lock files, no socket; --cbm-daemon-internal
  visible from ~+15s
• +30s: cbm-<hash>.sock + .sock.identity finally appear
• +35s: CLI's 30s timer (started at +0s) already expired → exit 1
• +40s: socket gone; daemon logged lifetime_end reason=initial_window_expired

The race is lost identically on 6+ single attempts. Page cache is warm (cat
of the 286 MB binary takes ~1.6s), so this is startup work under proot, not
disk I/O. These did not change the outcome: clean rendezvous dir,
watcher_enabled=false, ui_enabled=false, CBM_WORKERS=1,
CBM_SEMANTIC_ENABLED=0, CBM_LSP_DISABLED=1, CBM_MEM_BUDGET_MB=512.
(I grepped the binary — no CBM_* timeout override exists today.)

Logs

Daemon log tail (typical run):

level=info msg=mem.init budget_mb=1422 total_ram_mb=5689 source=ram_fraction
level=info msg=watcher.disabled reason=config
level=info msg=daemon.start version=0.11.0 pid=25193 cache_fingerprint=aaefd8b8489b6c3cc7b9030f7d7e19d59e3e2dcb328def3cd68506085c1f3e0f memory_budget_bytes=1491437568 physical_job_limit=4 worker_memory_budget_bytes=1491437568
level=info msg=daemon.lifetime_end reason=initial_window_expired
level=info msg=daemon.runtime_stopping reason=service_stop
level=info msg=daemon.stop

Secondary observation: after timeout-killed runs, the rendezvous dir can hold
a dangling symlink that is undeletable under proot (ls shows
l??????????, rm/python os.unlink → ENOENT, rm -rf dir →
"Directory not empty"). Later runs then fail with listen_failed stage=pending_publication / stable_publication or pre-coordination or unverified CBM generation is active until a fresh CBM_RUNTIME_DIR is used.

Diagnostics trajectory

Happy to provide (CBM_DIAGNOSTICS=1 run) on request — let me know exactly
which scenario to capture.

Project scale

n/a (fails before any indexing).

Confirmations

• I searched existing issues and this is not a duplicate. (Related but
  different: Server hangs and requires SIGKILL after list_projects on large project (SQLite lock contention) #52 SQLite lock contention on large projects, Deep diving into memory issues #46/codebase-memory MCP server OOM kills entire Claude Code session #49 memory/OOM
  — those are post-indexing issues; this is a startup-handshake timeout with
  an empty store.)
• My reproduction uses shareable code — no repository or proprietary code
  involved.

Request

1. Make the client accept timeout (and ideally the daemon initial window)
   configurable, e.g. CBM_CLIENT_ACCEPT_TIMEOUT_MS.
2. Harden socket publication/cleanup so a killed run cannot leave undeletable
   state behind.