A client started from a different install path gets no daemon rendezvous and fails after 30 s (same version, identical binary)

[sgaabdu4]

Version: 0.11.0 (npm package codebase-memory-mcp)
Platform: macOS 27.0, Apple Silicon (arm64)

Problem

When the per-user daemon was started by a client from one install path, a client started from any other path gets no rendezvous reply. After 30 s, initialize returns:

{"code":-32001,"message":"CBM daemon endpoint is held by pid <N> but that process answered no rendezvous within 30000 ms; the daemon runtime is likely dead — stop that process, then retry"}

The daemon is alive. During the same period, clients launched from its own path connect in about 1.7 s.

This happens without anything unusual. pnpm dlx and npx put each spec (@0.11.0 vs @latest) and each cache refresh in a new directory. It also happens when a user-level and a project-level MCP entry launch different installs. Hosts give up first: Codex's default startup timeout is 10 s, and Claude Code shows Failed to connect — CONNECTION_CLOSED.

Reproduction

1. Start an MCP client from install A (e.g. pnpm dlx codebase-memory-mcp@0.11.0) and keep it running, so the daemon runs from A's path.
2. Copy A's binary to another path: cp <A>/bin/codebase-memory-mcp /tmp/cbm-copy/codebase-memory-mcp. cmp reports the two files identical.
3. Send initialize to each binary:
   • A's binary: result in 1.7 s.
   • /tmp/cbm-copy/codebase-memory-mcp: the -32001 error above after 34.4 s.

pnpm dlx codebase-memory-mcp@latest gives the same result (it resolves to 0.11.0 in a different dlx directory): the error comes after 31–36 s. cbm-daemon.log has no client_image_rejected line for these attempts.

Expected

The daemon admits a client with the same version and binary from another path, or rejects it at once with a message naming the image/path mismatch. Today the message says the daemon is "likely dead" while it is serving other clients.

Related

#2378 (the daemon spins after its executable is moved; image_unverifiable admissions).