Linux 0.10.5: new MCP/CLI clients intermittently wait 15–30s or time out while healthy daemon serves existing clients

[chris-han]

Version

codebase-memory-mcp 0.10.5

Platform

Linux (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

Client admission and read-only queries must remain available while indexing is running or other clients are connected; only
mutation of the same project index should serialize.

Reproduction

This failure occurs during daemon client admission, before any graph query or
index access, so it does not depend on the code being indexed.

Environment:

• OS: Linux / WSL2
• codebase-memory-mcp: 0.10.5
• Multiple MCP clients: Codex sessions connected to the same per-user daemon
• Daemon mode: session-managed

Steps:

1. Start at least three Codex/MCP sessions configured to use
   codebase-memory-mcp.

2. Confirm that the shared daemon is healthy:

   codebase-memory-mcp daemon status
   

Output during the failure:

 daemon: active (session-managed)
   pid: 2458
   build: 0.10.5 (dfd7db016354...)
   committed clients: 3
     - pid 55306
     - pid 49179
     - pid 110190
   ui: configured at http://127.0.0.1:9749

3. Existing MCP sessions can still execute read operations such as
   search_graph, search_code, and get_code_snippet.

4. From another terminal, attempt to start a new client with a read-only tool
   call:

   time codebase-memory-mcp cli --json index_status

   No project argument is intentionally supplied. Once admitted, the expected
   result is an immediate validation error saying that project is required.
   This isolates daemon admission from database/index behavior.

5. Intermittently, the new client waits for the complete 30-second startup
   deadline and exits with:

   codebase-memory-mcp: CBM daemon is active or starting but could not accept
   this client within 30000 ms
   error: CBM daemon is active or starting but could not accept this client
   within 30000 ms

6. Repeat the identical command. In one observed retry it connected after
   approximately 15 seconds and returned the expected tool-level validation
   response:

   {
   "error": "missing required argument: project",
   "hint": "Pass the project as the "project" argument..."
   }

Expected behavior:

A healthy daemon with 3 committed clients should admit the new client promptly.
The source configures HOST_MAX_CLIENTS = 64. Read-only client admission should
not wait for or be blocked by index mutation coordination. Only concurrent
mutation of the same project index should be serialized.

Actual behavior:

A new client intermittently takes 15–30 seconds to connect or times out
completely, while the daemon remains active and existing clients continue
serving graph searches.

Diagnostics:

• /tmp and the cache filesystem had approximately 837 GB free.

• Inode usage was approximately 4%.

• The daemon log showed successful requests from existing clients.

• No daemon.ipc.listen_failed, daemon.start_failed,
  connection capacity reached, or index-lock error was present around the
  failure.

• The failure was observed with only 3 committed clients, well below the
  configured capacity of 64.

Code being indexed:

Not applicable to the minimal reproduction because the failure occurs before
tool dispatch. The same test can be run with no project argument, as above.
If an indexed public repository is required, use:

• Repository: DeusData/codebase-memory-mcp
• Commit: ec08f76

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

No response

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.