How to fix codebase-memory-mcp stdio pipe dying (connection closed: EOF) in idle sessions?
codebase-memory-mcp 0.8.1 (macOS 15) only supports stdio transport. In long or idle Claude Code/Codex sessions the pipe silently dies: the server stays alive but every tool call returns connection closed: EOF, and only a client restart fixes it. Subagents don't help because all agents share the same CLI-level stdio pipe. Is there a native HTTP/SSE transport or a working workaround? (Feature request still open.)
Originally asked on GitHub: https://github.com/DeusData/codebase-memory-mcp/issues/709
4 answers
Status: Open as of 2026-10-25. Native HTTP transport exists only as a maintainer-accepted feature request, with no release commitment. A maintainer source review of main at commit
96c3f41(2026-10-02) confirmed the normal client connection still uses stdio, and the UI/rpcendpoint only accepts a few UI operations, not a general MCP HTTP transport.What works today
mcp-proxywrapper (confirmed workaround). Runcodebase-memory-mcpbehindmcp-proxyas a persistent HTTP/SSE daemon. The reporter used this successfully, but it requires a separate LaunchAgent and manual config changes. The maintainer called it "the practical workaround" and said native transport is not a short-term drop-in for the C server because transport lifecycle and local-listener semantics need deliberate design.- Streamable HTTP prototype (design evidence only, not production-ready). A commenter built a proof of concept around v0.10.3 (Windows, Python MCP SDK 1.26.0, 91 indexed projects) that keeps one CBM stdio backend alive and forwards the existing 15 tools to HTTP clients at
/mcpusing stateless Streamable HTTP (legacy HTTP+SSE is deprecated in current MCP guidance). Measured: initialize ~72–92 ms,tools/list~30–40 ms,search_graph~44–46 ms; the ~37 s cold cost waslist_projectsacross 91 projects. Concurrent calls, cancellation, backend restart and long-running indexing still need testing, and it binds to localhost only.
Subagents do not help: all agents share the same CLI-level stdio pipe, so the EOF returns. General advice, not from the thread: try a client-side keepalive for the idle EOF, and if you run any HTTP bridge keep it localhost-bound.
Did this work for you?What a GitHub user tried on GitHub (Worked)
Reporter wrapped codebase-memory-mcp with mcp-proxy as a persistent HTTP/SSE daemon, run as a separate LaunchAgent with manual config changes. It worked but was described as painful to set up and maintain.
Source: https://github.com/DeusData/codebase-memory-mcp/issues/709 (opens external site)
Did this work for you?What @GanizaniSitara tried on GitHub (Partly worked)
A commenter built a Streamable HTTP proof of concept around v0.10.3 (Python MCP SDK 1.26.0, Windows, 91 indexed projects): one persistent CBM stdio backend forwarding 15 tools to HTTP clients at /mcp, with latencies for initialize, tools/list and search_graph. The author stresses it is design evidence only; concurrent calls, cancellation, backend restart and long-running indexing need testing.
Did this work for you?What a GitHub user tried on GitHub (Didn't work)
Same issue body: the reporter tried spawning new subagents to recover from the dead pipe. It did not help because all agents share the same CLI-level stdio pipe.
Source: https://github.com/DeusData/codebase-memory-mcp/issues/709 (opens external site)
Did this work for you?
Related questions
- codebase-memory-mcp cli search_code returns "search failed: temp file" on Windows
- Claude Code hook blocks every Read instead of once per session, how to fix?
- search_code always returns 0 results – ripgrep invoked without explicit path
- Does codebase-memory-mcp support PowerShell (.ps1, .psm1, .psd1) files?
- codebase-memory-mcp install/update fails with 'active CBM sessions could not be stopped safely' after killed processes