You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
codebase-memory-mcp.exe running after quitting VS Code. #185
Thanks for the report. Each MCP client (VS Code, OpenCode, OpenChamber) launches its own codebase-memory-mcp stdio server, so a few concurrent processes is expected — but they should each exit when their client closes the stdio pipe. Lingering instances mean a process isn't detecting that its parent went away.
Looking at the server lifecycle: on Windows the event loop relies on stdin reaching EOF (the client closing the pipe) to terminate. That works for a graceful client shutdown, but if a client is force-killed or crashes and leaves the pipe write-handle dangling, the server can be orphaned — there's currently no parent-process-death watchdog as a backstop.
A fair amount of MCP-loop and Windows work has landed since this was filed (v0.7.0): MCP ping, a reworked stdin poll path, and Windows-specific I/O fixes. Could you retest on v0.7.0 and let me know:
Does the problem still occur on v0.7.0?
When you see orphans, was the client closed gracefully (normal quit) or force-killed/crashed?
Do the orphaned processes eventually exit on their own (e.g. after a minute), or do they stay forever?
Which client's processes linger — is it one specific client or all three?
That'll tell me whether to add a Windows parent-death watchdog or whether it's a specific client not closing its pipe. Thanks!
Closing for inactivity — no response to the retest request. The MCP loop got ping, a reworked stdin poll path, and Windows I/O fixes in v0.7.0; current is v0.8.1.
If you still see orphaned codebase-memory-mcp.exe processes after quitting VS Code on v0.8.1, comment with the answers to the four questions above (graceful quit vs force-kill, do they exit eventually, which client) and I'll reopen right away. Thanks!
Activity
DeusData commentedon May 31, 2026
Thanks for the report. Each MCP client (VS Code, OpenCode, OpenChamber) launches its own
codebase-memory-mcpstdio server, so a few concurrent processes is expected — but they should each exit when their client closes the stdio pipe. Lingering instances mean a process isn't detecting that its parent went away.Looking at the server lifecycle: on Windows the event loop relies on stdin reaching EOF (the client closing the pipe) to terminate. That works for a graceful client shutdown, but if a client is force-killed or crashes and leaves the pipe write-handle dangling, the server can be orphaned — there's currently no parent-process-death watchdog as a backstop.
A fair amount of MCP-loop and Windows work has landed since this was filed (v0.7.0): MCP
ping, a reworked stdin poll path, and Windows-specific I/O fixes. Could you retest on v0.7.0 and let me know:That'll tell me whether to add a Windows parent-death watchdog or whether it's a specific client not closing its pipe. Thanks!
DeusData commentedon Jun 12, 2026
Closing for inactivity — no response to the retest request. The MCP loop got
ping, a reworked stdin poll path, and Windows I/O fixes in v0.7.0; current is v0.8.1.If you still see orphaned
codebase-memory-mcp.exeprocesses after quitting VS Code on v0.8.1, comment with the answers to the four questions above (graceful quit vs force-kill, do they exit eventually, which client) and I'll reopen right away. Thanks!