Windows 11: MCP-based review is extremely slow while CLI graph operations are fast

[reponemec]

Summary

code-review-graph CLI itself is fast on my machine, but using it through MCP from Claude Code, Codex CLI, and Gemini CLI becomes very slow in practice, to the point where it is not usable for normal code review workflows.

This feels especially problematic because the graph database and local commands are responsive, while the agent + MCP path is heavily delayed.

Environment

• OS: Windows 11 (10.0.26100.7171)
• Repo size: 2462 files
• Languages: csharp, javascript, tsx, typescript
• code-review-graph: current latest (installed via pip on Windows)
• Clients tested:
  • Claude Code
  • Codex CLI
  • Gemini CLI

What works fast

These commands are very fast in the same repository:

code-review-graph status
code-review-graph detect-changes
code-review-graph postprocess

Example output:

Nodes: 9724
Edges: 34488
Files: 2462
Languages: csharp, javascript, tsx, typescript
Last updated: 2026-04-13T12:06:24
Built on branch: master
Built at commit: 295fc161ecf2

detect-changes also returns quickly:

{
  "summary": "Analyzed 2 changed file(s):\n  - 0 changed function(s)/class(es)\n  - 0 affected flow(s)\n  - 0 test gap(s)\n  - Overall risk score: 0.00",
  "risk_score": 0.0,
  "changed_functions": [],
  "affected_flows": [],
  "test_gaps": [],
  "review_priorities": []
}

postprocess is also fast.

What is slow

When I ask Claude Code / Codex CLI / Gemini CLI to use code-review-graph via MCP for review of current changes, the workflow becomes very slow and often appears stuck for several minutes.

Example prompt:

Use code-review-graph to quickly evaluate the current changes in this repo.
First determine impacted files and minimal context through it, then in one message summarize what I should watch out for.

Observed behavior:

• the agent often enters a long planning phase
• MCP-driven workflow becomes much slower than plain review without graph
• in Codex CLI I saw it explicitly trying to work around internal diff handling:
  • it said it would compute changed_files via git diff --name-only HEAD~1 and then pass them into graph tools
• for small changes this makes the whole setup unusable
• for this repo size (2462 files) the MCP path is much slower than expected from the raw CLI performance

Additional concerns

Installation/configuration also writes project-local files such as:

• .mcp.json
• .claude/skills/...

This may be intended, but it is surprising when configuring for multiple agents with different MCP server preferences.

Additional findings (Windows 11, Codex CLI)

The question “What the hell took you so incredibly long?” was directed at Codex CLI, not at code-review-graph itself.

From Codex’s point of view, the delay came from MCP tool calls timing out, not from the local graph commands.

Concretely:

• First attempt (get_minimal_context + get_impact_radius) both timed out at 120s per call.
• I verified that the graph is built and fresh (list_graph_stats is fast), but as soon as a tool tries to do its own git diff / change detection internally (detect_changes, get_impact_radius without explicit changed_files), it hits the same 120s timeout again.
• Only after I manually did git diff --name-only HEAD~1 and passed that list of files into the tool as changed_files, get_impact_radius completed immediately and the review context was computed quickly.

So the delay was not the model “thinking” for a long time, but the MCP tool backend never returning within the 2 minute limit when it performs its own git diff on this repo, until I worked around it by providing an explicit list of changed files from Codex CLI.

Expected behavior

• MCP usage should be close enough to raw CLI responsiveness that it remains practical
• small-diff review should not take minutes when graph commands themselves are fast
• ideally there should be a clearer lightweight path for:
  • changed files -> impact radius
  • changed files -> review context
    without triggering large planning / prompt orchestration overhead

Possible debugging help

If there is a recommended debug mode for MCP requests / tool timings, I can test it and provide logs.