0.10.0/0.10.1 MCP server silent on initialize (regression from 0.9.0)

[wassolles]

Summary

Since 0.10.0, the stdio MCP server produces zero output in response to a standard MCP initialize request. Clients time out / mark the server failed (opencode surfaces this as -32000 Connection closed). Version 0.9.0 responds correctly.

Environment

• codebase-memory-mcp: 0.10.0 and 0.10.1 (broken) vs 0.9.0 (works)
• Node v20.20.2, npm/npx 10.8.2
• OS: Linux (WSL2, Ubuntu), x86_64
• Invoked as a stdio MCP server via npx -y codebase-memory-mcp

Reproduction

Send a valid MCP initialize over stdin, capture stdout:

(printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"diag","version":"1.0"}}}'; sleep 5) \
  | timeout 60 npx -y codebase-memory-mcp@0.10.1

Actual (0.10.0 and 0.10.1)

• stdout: empty (0 bytes)
• stderr: empty
• exit 0 on stdin EOF — the server never writes a response

Expected (works on 0.9.0)

stdout:

{"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2024-11-05","serverInfo":{"name":"codebase-memory-mcp","version":"0.9.0"},"capabilities":{"tools":{"listChanged":false}}}}

stderr shows normal startup (mem.init, server.start version=0.9.0, watcher.start, mcp.request method=initialize status=ok).

Version bisect

Version	initialize response	Published
0.9.0	✅ works	2026-07-08
0.9.1-rc.1	not tested	2026-07-30
0.10.0	❌ silent	2026-08-10
0.10.1	❌ silent	2026-08-11

Regression was introduced in 0.10.0.

Client-side symptom

opencode log: level=WARN message="server unavailable" key=codebase-memory-mcp type=local status=failed, surfaced to the user as MCP error -32000: Connection closed.

Workaround

Pin to the last known-good release: npx -y codebase-memory-mcp@0.9.0.

Happy to run additional diagnostics (e.g. capture a trace with --print-logs, inspect bin.js behavior) if that helps narrow it down. Thanks!

[wassolles]

Update — root cause identified + workaround

I dug deeper. The initialize silence is a symptom; the real cause is the new daemon's client image verification rejecting npx-invoked clients.

What happens

Running npx -y codebase-memory-mcp (0.10.0 / 0.10.1) starts the stdio shim, which tries to become a client of the CBM daemon. The daemon then verifies the client's running binary image and rejects it:

level=error msg=daemon.client_image_rejected reason=image_unverifiable

The client keeps waiting for admission and eventually hits:

CBM daemon is active or starting but could not accept this client within 30000 ms

→ exits non-zero with zero bytes on stdout, so the MCP client sees a silent drop / -32000.

Where it is

src/daemon/runtime.c, the admission path after a successful rendezvous (runtime_rendezvous_compare already passed → claimed version+build matched):

// runtime.c:1739-1774  (abridged)
bool peer_image_verified = runtime_process_image_reference_matches_process(...peer_pid);
bool peer_image_fingerprinted = false;
if (!peer_image_verified) {
    peer_image_fingerprinted =
        cbm_daemon_runtime_process_build_fingerprint(worker->peer_process_id, peer_fingerprint);
    peer_image_verified = peer_image_fingerprinted &&
                          strcmp(peer_fingerprint, requested_build) == 0 &&
                          strcmp(peer_fingerprint, service->identity.build_fingerprint) == 0;
}
if (!peer_image_verified) {
    const char *reason = peer_image_fingerprinted ? "fingerprint_mismatch" : "image_unverifiable";
    cbm_log_error("daemon.client_image_rejected", "reason", reason);
    ...reject...
}

For npx, cbm_daemon_runtime_process_build_fingerprint() returns false (the fingerprint can't be computed for the peer running from the ephemeral npx cache), so reason = image_unverifiable. Note the client had already proven version+build compatibility via the rendezvous HELLO — the image check is an additional, stricter gate that fails closed.

Why npx specifically, and the workaround

The binary run via npx lives at an ephemeral cache path (~/.npm/_npx/<hash>/node_modules/codebase-memory-mcp/bin/...). The daemon's image verification can't fingerprint that peer, so it's rejected.

The managed install (which the install subcommand exists for) places the binary at a stable path, and everything works:

# one-time, from any 0.10.x binary:
codebase-memory-mcp install --yes --skip-config   # -> ~/.local/bin/codebase-memory-mcp

Pointing the MCP client at the stable binary instead of npx fixes it. Verified end-to-end: a fresh opencode run calling list_projects returns all indexed projects, no errors, ~5s cold start.

Reproduction (clean)

rm -rf /tmp/cbm-daemon-$(id -u)
INIT='{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"d","version":"1"}}}'

# BROKEN — npx: 0 bytes stdout, exit 1 after ~30s, daemon logs image_unverifiable
(printf '%s\n' "$INIT"; sleep 5) | timeout 60 npx -y codebase-memory-mcp@0.10.1

# WORKS — managed binary at stable path: full initialize response
~/.local/bin/codebase-memory-mcp < <(printf '%s\n' "$INIT")

Suggested directions (happy to PR any of these with your guidance)

1. Fail open when unverifiable but rendezvous-compatible. If the peer's image can't be examined and the HELLO already proved version+build match the daemon, admit the client (warn-level log) instead of rejecting. Restores npx/ephemeral use without weakening the mismatch-rejection case.
2. Detect ephemeral/npx invocation and skip the image gate (or treat it as best-effort).
3. At minimum, document that npx/cache invocation is unsupported under the daemon model and that a managed install is required — so users hitting -32000 know the fix.

(1) is security-relevant, so I'd want your call on the threat model before opening a PR. Option (3) is a safe docs PR I can send immediately if useful.

Environment: Linux x86_64 (WSL2, Ubuntu), ptrace_scope=1, Node 20.20.2. The image_unverifiable is reproducible 100% of the time via npx and 0% via the managed binary.

[DeusData]

@wassolles this is a superb analysis — reproduction, the exact admission path, and the fix space, all correct on our read. Thank you.

Confirming your findings: this is the same root as #1383 (image_unverifiable rejections of legitimate clients) — your report adds the missing piece, which is that every npx invocation lands in this state deterministically because the ephemeral cache path defeats peer fingerprinting, and the failure is then silent on stdout. Silent-empty failures are exactly the class we just spent this release cycle stamping out (#1522), so this is going to the top of the current fix batch alongside the installer issues.

On your three directions:

1. Fail-open-when-unverifiable + rendezvous-proven is the one we're evaluating — you're right that it's a threat-model call (the image gate exists so a same-version-but-tampered peer can't ride in on a valid HELLO), and it's being decided together with two sibling strictness questions (POSIX install-dir permission checks in codebase-memory-mcp 0.10.0 update fails on Linux (Ubuntu) #1535, sandboxed-Windows ACLs in Windows: ancestor walk refuses app container / capability SIDs, so 0.10.0 cannot start inside a containerized host #1533/Windows installer fails with CodexSandboxUsers ACL in %TEMP% #1529) so the policy comes out coherent rather than piecemeal. Decision lands today.
2. Regardless of that call, two things are unconditional: the client must fail loudly — a proper JSON-RPC error on stdout naming the rejection reason and the managed-install remedy, never a 30 s silent death — and the daemon's rejection log must reach the user somewhere findable.
3. Yes please on the docs PR — a short "npx/ephemeral invocation under the daemon model" note with the managed-install path would help people hitting -32000 today, and we'd take it gladly right now.

We'll post the policy decision here as soon as it's made. Thanks again — reports that arrive with the admission-path code already read are a maintainer's dream.

[DeusData]

Policy decision (as promised): your option 1, adopted — a peer whose image cannot be fingerprinted but whose rendezvous HELLO already proved version+build compatibility will be admitted with a warn-level log; a fingerprint mismatch still rejects hard. Alongside it, the unconditional part: admission failures of any kind will emit a proper JSON-RPC error on stdout naming the reason and remedy — never a silent 30 s death. Both land in v0.10.2, in progress now. Your docs PR offer stands welcome for the interim npx note.

[DeusData]

Fixed in v0.10.2, released just now: https://github.com/DeusData/codebase-memory-mcp/releases/tag/v0.10.2 (GitHub archives, npm, and PyPI are all serving it).

Please give it a try when you get a chance — if it behaves in your setup, feel free to close this out; if anything still looks off, say so and we'll pick it straight back up. Thank you again for the report, it made this fix fast and precise.