MCP server ignores indexed sub-projects below cwd

[nakisen]

Summary

planFrontload already handles the case where the index lives in a child rather than at the agent's cwd. That is what findIndexedSubprojectRoots() was added for (#964). The MCP server's own root resolution never got the same treatment: resolveDaemonRoot() and MCPEngine.doInitialize() still rely solely on the upward walk in findNearestCodeGraphRoot().

So when an MCP host is launched from a workspace container whose sub-projects are indexed, the server starts, advertises its tools, and then does nothing: no database is opened, no default project is set, and startWatching() is never called. Live auto-sync, the main reason to run the daemon at all, is silently off.

Reproduction

workspace/
├── .mcp.json                 ← MCP host cwd; NO .codegraph/ here
├── service-a/
│   └── .codegraph/           ← indexed
└── service-b/
    └── .codegraph/           ← indexed

1. Run codegraph init inside service-a and service-b, not in workspace/.
2. Give the host a plain entry, with no --path:

   { "codegraph": { "type": "stdio", "command": "codegraph", "args": ["serve", "--mcp"] } }

3. Start the agent with cwd = workspace/, edit and save a source file under service-a.

Expected: the edit is picked up, the same way it is when cwd is the indexed root itself.

Actual: nothing happens.

• ~/.codegraph/daemons/ never gains an entry for either child root, so no daemon was ever started for them.
• No daemon.log is created under either child's .codegraph/.
• The MCP tools are listed but have no default project.
• A later manual codegraph sync from inside a child does pick up the change, which makes the failure look intermittent rather than structural.

Why it happens

1. resolveDaemonRoot() (src/mcp/index.ts:160) calls findNearestCodeGraphRoot(cwd). The walk only goes up (src/directory.ts:158), so the two indexed children are never seen. It returns null.
2. null means direct mode, correctly so, since the lock and socket both live under .codegraph/. No daemon is started.
3. MCPEngine.doInitialize() (src/mcp/engine.ts:201) repeats the same lookup at :204, gets null, and returns early:

   if (!resolvedRoot) {
     // No .codegraph/ above searchFrom. Sessions may still discover one later via roots/list
     this.projectPath = searchFrom;
     return;
   }

   startWatching() at :215 is skipped. retryInitializeSync() (:157) uses the same upward-only lookup, so the retry path cannot recover either. roots/list reports the same container directory, so that fallback does not help here.

The helper that would fix this already exists and is already exported: findIndexedSubprojectRoots() (src/directory.ts:212) is a bounded breadth-first scan (depth 4, max 64 results, heavy directories skipped) that stops at the first indexed directory on each branch. src/mcp/engine.ts:15 currently imports only findNearestCodeGraphRoot.

Suggested fix

Mirror what planFrontload (src/directory.ts:543) already does, in doInitialize (and retryInitializeSync), only when the upward walk returns null:

• exactly one indexed sub-project → adopt it as the default project and watch it;
• several → keep no default, but log the list so the agent knows to pass projectPath explicitly;
• none → today's behaviour.

The same resolution should feed resolveDaemonRoot, so the adopted root also gets a daemon and the single-watcher, single-writer guarantees rather than a direct-mode server per host.

The cost is one bounded scan on the path where the server currently gives up entirely, and the semantics are already precedented by the front-load hook.

Open question: the workspace-root gate

findIndexedSubprojectRoots is reached in planFrontload only behind looksLikeProjectRoot() (src/directory.ts:196), which requires one of the WORKSPACE_ROOT_MANIFESTS (package.json, go.mod, Cargo.toml, and so on). A container that holds only agent configuration and a .git directory, with no build manifest of its own, fails that gate, so it would still get nothing after this change. That is the exact shape that motivated this report.

Widening the gate to include .git would cover it, but it also turns the down-scan on for essentially every repository, and #1454 already reports the gate misfiring in the other direction. Worth deciding deliberately rather than as a side effect. The diagnostic in the companion issue is useful either way, since it makes the "no project resolved" state visible even when the scan is not attempted.

Environment

CodeGraph 1.5.0, Windows 11, native filesystem (no WSL). Line numbers are against main at the time of writing.

[colbymchenry]

Confirmed and fixed in #1614 — thanks @nakisen, the diagnosis was exact on every point: resolveDaemonRoot() and doInitialize() (plus retryInitializeSync()) only ever ran the upward walk, startWatching() was skipped, and roots/list reporting the same container directory meant no fallback could recover. The fix is what you suggested: the same bounded down-scan planFrontload uses, wired into one shared resolveServerRoot() that all of them — including the daemon-root resolution, so the adopted child gets the shared daemon and its single-watcher/single-writer guarantees rather than a direct-mode server per host.

On the open question (the workspace-root gate), decided deliberately per your framing: the server-side down-scan runs when the base has a workspace manifest or a .git entry — the exact container shape that motivated your report — and never when the base is $HOME or the filesystem root. Exactly one indexed sub-project is adopted; zero or several never guess. The gate lives only in the new server-side helper: planFrontload and the prompt-hook are untouched, so this does not widen the #1454 surface.

The several-candidates case now surfaces the list instead of going quiet, per your companion issue #1607 — stderr at startup and, protocol-reachable, in the "no default project" tool response. The retry path re-resolves (down-scan throttled) so a child indexed mid-session is still picked up live.