Repository navigation
mcp: a projectPath naming a file inside a project returns isError ("Path is not a directory") #2982
Description
A projectPath that names a file inside an indexed project is refused with isError: true ("Path is not a directory"), while a path that doesn't exist at all resolves fine.
| call | result on main |
|---|---|
codegraph_status {"projectPath": "<proj>/src/a.ts"} |
isError: true, "Error: Path is not a directory: …/src/a.ts" |
codegraph_status {"projectPath": "<proj>/no/such/dir"} |
success: the project's status (walks up to .codegraph/) |
Cause. mcp/tools.ts#L2355 runs validateProjectPath on an existing path, which returns "Path is not a directory" (utils.ts#L218). That error is surfaced like a path refusal: isError, with no guidance.
Reproduced on main at 77ee348 (serve --mcp over stdio, Linux/WSL2, Node 22.23.2).
Why it matters. Passing the file it's looking at as projectPath is an easy agent mistake, and AGENTS.md reserves isError for "stop trying" cases ("Errors teach abandonment"). A file path inside a project is recoverable.
Expected. For an existing file, use its directory and walk up to .codegraph/ as for any other path inside the project. Or at least return a success-shaped hint ("projectPath should be the project directory; using
Activity
colbymchenry commentedon Oct 30, 2026
Thanks for the report and the clear table! An MCP call whose
projectPathnames a file inside an indexed project now answers from that project instead of returning isError "Path is not a directory", and a file inside a sensitive folder is still refused. The fix is #3075; it's on main and ships in the next release.fix(mcp): a projectPath naming a file resolves through its directory
feat(upstream): catch up to cd04b21, batch 2 — TypeScript-side fixes (#…