Regression: first `codegraph_explore` in each new Codex conversation waits ~45s then returns "busy serving other concurrent requests"

[Lok17]

Title: Regression: first codegraph_explore in each new Codex conversation waits ~45s then returns "busy serving other concurrent requests"

Summary

On CodeGraph 1.3.0, the first codegraph_explore in each new Codex desktop conversation consistently waits about 45 seconds and then returns a "busy serving other concurrent requests" message instead of results.

This looks related to the previously closed shared-daemon concurrency issue (#987), but in my case it happens during ordinary use in Codex, without intentionally launching parallel agents or multiple MCP clients myself.

Environment

• CodeGraph version: 1.3.0
• Client: Codex desktop app via MCP
• OS: Windows
• Project size: about 33,179 indexed files

Steps to Reproduce

1. Open Codex desktop on a repo that already has a .codegraph/ index.
2. Start a brand-new conversation/thread.
3. Ask the agent something that causes an immediate codegraph_explore call.
4. Observe the first CodeGraph call in that thread.

Observed Behavior

• The first codegraph_explore consistently waits about 45 seconds.
• Instead of returning source/results, it returns this message:

CodeGraph is busy serving other concurrent requests right now (this call waited 45s in the queue). This is NOT an error and the index is fine — wait a few seconds and retry this exact call; it will return normally.

• This happens on essentially every new Codex conversation, not just under intentional multi-agent fan-out.
• Retrying from the same conversation may eventually succeed, but in my case the retry took about 82 seconds, so the "wait a few seconds and retry" guidance does not match actual latency.

Expected Behavior

• The first codegraph_explore in a normal new Codex conversation should usually return results directly.
• The busy/queue response should appear only under real saturation, not reliably on every new thread.
• If Codex startup triggers hidden concurrent requests, CodeGraph should either absorb that normally or expose enough logging/telemetry to make the cause visible.

Why this seems like a regression

• Issue [Feature] Shared daemon serializes concurrent tool calls — N clients = N× tail latency #987 described shared-daemon queueing under concurrent MCP clients and is now closed.
• The 1.1.2 changelog says concurrent requests now run through a worker pool and saturated calls should return a brief busy response instead of hanging.
• On 1.3.0, I still see the busy path trigger reliably on the first CodeGraph call in each new Codex conversation.

Additional Notes

• I have only confirmed this from Codex desktop so far.
• I can help test with daemon logging, CODEGRAPH_QUERY_POOL_SIZE, or CODEGRAPH_NO_DAEMON=1 if that would help narrow it down.
• If this is considered the same root cause as [Feature] Shared daemon serializes concurrent tool calls — N clients = N× tail latency #987, reopening that issue may make more sense than tracking this separately.