probe mcp starts but never responds to MCP initialize handshake (stdout stays silent)

[markus-michalski]

Summary

probe mcp starts successfully and logs "Probe MCP server running on stdio" to stderr, but never responds to a valid MCP initialize request over stdio — no bytes are ever written to stdout, and the process just sits there. Reproduced identically on two separate release-candidate builds. Any MCP client (tested: Claude Code) sees this as a hung/closed connection.

Environment

• OS: Debian GNU/Linux 13 (trixie), x86_64
• Node.js: v20.19.2 (from Debian's nodejs apt package)
• npm: 9.2.0
• @probelabs/probe: tested on 0.6.0-rc331 (current latest npm dist-tag) and 0.6.0-rc250 — identical behavior on both
• Downloaded platform binary: probe-v0.6.0-rc331-x86_64-unknown-linux-musl.tar.gz (auto-selected by the package's install step)
• MCP client used to reproduce: Claude Code CLI v2.1.239 (claude mcp add/claude mcp list), plus a manual raw JSON-RPC stdio harness (see below) to rule out anything client-specific

Steps to reproduce

1. npm install @probelabs/probe (or npx -y @probelabs/probe mcp directly — exactly the config from this project's own README)
2. Register it as a stdio MCP server. Config used (copied verbatim from the README's "Using as an MCP Server" section):

   {
     "mcpServers": {
       "probe": {
         "command": "npx",
         "args": ["-y", "@probelabs/probe", "mcp"]
       }
     }
   }

3. Via Claude Code (claude mcp add probe -s user -- npx -y @probelabs/probe mcp, then claude mcp list): consistently reports

   probe: npx -y @probelabs/probe mcp - ✘ Failed to connect — CONNECTION_CLOSED: Connection closed
   

   Reproduced across multiple separate claude mcp list invocations (not a one-off flake), including after the npx cache was already warm from prior manual runs.
4. To rule out anything Claude-Code-specific, reproduced manually with a bash coprocess holding stdin open (so EOF-triggered shutdown isn't a confound) and sending a real initialize request:

   coproc PROBE { node node_modules/@probelabs/probe/bin/probe mcp 2>err.log; }
   sleep 1
   printf '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}\n' >&"${PROBE[1]}"
   sleep 2
   timeout 3 head -c 2000 <&"${PROBE[0]}"   # -> nothing, ever
   kill -0 "$PROBE_PID"                      # -> still alive

   err.log shows the server started fine:

   Found package.json at: .../node_modules/@probelabs/probe/package.json
   Using version from package.json: 0.6.0-rc331
   Bin directory: .../node_modules/@probelabs/probe/build/bin
   Probe MCP server running on stdio
   

   but stdout never receives a response to the initialize call, for as long as the process is kept alive (tested up to several seconds of waiting; the process itself doesn't crash or exit).
5. Repeated the exact same manual test against 0.6.0-rc250 — byte-for-byte same symptom (starts, logs the banner, never responds).

Expected behavior

The server responds to a well-formed initialize request with a JSON-RPC result containing protocol version / server capabilities negotiation, per the MCP spec.

Actual behavior

No response is ever written to stdout. The process stays alive (not a crash) but is unusable as an MCP server — any real client eventually gives up and reports the connection as closed/failed.

Things I ruled out

• Not a config mistake: the MCP server config used is copied verbatim from this repo's own README ("Using as an MCP Server" section).
• Not the underlying binary: the native probe binary works fine outside MCP mode (probe --version → probe-code 0.6.0, probe search/extract work as documented).
• Not an EOF/stdin-closed artifact: the coprocess harness above keeps stdin open across the whole test, so this isn't just "exits cleanly on EOF before it can reply."
• Not npx cold-cache overhead: reproduced with the package already installed locally (npm install, not npx -y) and invoked directly via node bin/probe mcp.
• Not version-specific: identical on two RC builds ~80 releases apart (rc250 vs rc331).
• Probably not an SDK version mismatch: package.json pins @modelcontextprotocol/sdk: ^1.0.0, which resolves to 1.30.0 in node_modules — a current, presumably well-tested SDK version.

Context

Ran into this trying to add Probe as a Claude Code MCP server for local code search. Note this project currently has no stable release on npm — npm view @probelabs/probe dist-tags returns { next: '0.6.0-rc191', latest: '0.6.0-rc331' }, i.e. latest itself is a release candidate. Worth flagging in case this bug is specific to the RC channel and a stable cut would avoid it — but since it reproduces identically on two RCs ~80 builds apart, it doesn't look like transient RC noise.

Happy to provide more logs/traces or test a fix — this is blocking MCP usage entirely for me right now (the non-MCP CLI usage is unaffected).