Multiple persistent processes and redundant indexing with codebase-memory-mcp

Environment

• OS: Windows 11
• Editor: VS Code
• Extension: Codex (or similar MCP-enabled extension)

Description

I have noticed that the codebase-memory-mcp server spawns multiple instances that remain running even after work is finished. In one session involving a single chat and 4 prompts (where I didn't even explicitly call the tool), multiple processes were active:

Redundant Indexing & cwd Behavior

After restarting VS Code, the MCP did not start automatically (correct). However, upon requesting a re-index, I discovered that two separate databases were being created for the same project: one for the root and one for the /src folder.

Index Status Output:

Reindex completed with codebase_memory for your workspace root.

Project: d-My Data-Projects-Private projects-my_project
Root: d:\My Data\Projects\Private projects\my_project
Status: ready
Index type: incremental (after full reindex run)
Nodes: 12319 | Edges: 16072

Also present (session project):
Project: D-My Data-Projects-Private projects-my_project-src
Root: D:\My Data\Projects\Private projects\my_project\src
Status: ready
Nodes: 4624 | Edges: 6678

Resulting Cache Files:

• d-My Data-Projects-Private projects-my_project.db
• D-My Data-Projects-Private projects-my_project-src.db

I had assumed setting the cwd in config.toml would define the MCP's root, but it seems to be indexing both the workspace root and the cwd.

My config.toml:

[mcp_servers.codebase_memory]
command = "D:\\Dev\\MCP\\codebase-memory-mcp\\codebase-memory-mcp.exe"
cwd = "D:\\My Data\\Projects\\Private projects\\my_project\\src"
startup_timeout_sec = 20
tool_timeout_sec = 120

Process Proliferation per Chat

Each new chat session appears to spawn a unique MCP process. While archiving a chat kills some processes, others remain orphaned.

Process Ownership:

This behavior is discussed in a related OpenAI/Codex issue: Issue #12333.

Key Observation: Premature Spawning

I discovered that a process is spawned as soon as I type "codebase_memory mcp" into the prompt box—before the prompt is even sent.

1. Type the tool name in the prompt: 1st process starts.
2. Hit Enter to send: 2nd process starts.

I get a normal response the first time I reuest a db index, but If I manually kill these processes and try to continue the chat with a new tool call to re-index the project, the call fails:

tool call error: tool call failed for `codebase_memory/index_repository`
Caused by: tools/call failed: Transport closed

Potential Mitigation

To prevent these processes from accumulating indefinitely, it might be beneficial for some to implement an idle timeout within the MCP server itself although there is a risk of prematurely closing connections on long running chats if there is a long delay between tool calls within the same chat. The user would themselves be responsible for setting the timeout limit and keeping an eye on it, but as long as they're actively prompting and making tool calls the time-out timer would reset on every call and therefore delay terminating the process.

Suggested Implementation:
If using the MCP Go/Rust/TS SDK, the Serve() loop could be wrapped with a timer that resets upon receiving a JSON-RPC message. Adding a --timeout flag would allow users to configure this in their TOML:

command = "codebase-memory-mcp.exe --timeout 600"

Conclusion:
I kind of answered my own question but it was an interesting analysis to do. While the connection needs to stay alive for the duration of a chat, the current behavior (especially the double-spawning and persistent processes after a chat is no longer active) leads to some resource waste on Windows. Use of a .cgrignore might solve the redundant indexing, but the process management seems to be an architectural issue between the extension and the MCP lifecycle.