A review thread is offered every configured MCP server, including ones that cannot serve the workspace

[patriyang]

Observation

Split out of #100, which is closed by #104. #100 raised four sub-questions; three are answered there (no per-tool cancel exists at the app-server layer, aborted turns are now failureClass: "stalled", MCP calls got their own inactivity budget). The fourth is a policy question that PR #104 deliberately did not decide:

Whether MCP servers should be filtered per workspace — e.g. a server that reports it cannot serve this workspace gets dropped from the turn's tool list rather than offered to the model.

Why it is still live

The incident behind #100 was a reviewer calling codegraph/codegraph_explore in a workspace that deliberately carries no .codegraph/ index. Under Claude Code the same server answers immediately and usefully ("No CodeGraph project is loaded for this session"). Under Codex the call sat in flight until a watchdog fired.

#104 made that outcome cheaper and legible — the budget is more patient and the abort is now classified — but the reviewer is still offered a tool that cannot answer for this workspace, and it still costs the turn when the call hangs rather than errors.

What would need deciding

The plugin does not configure Codex's MCP servers today; they come from the user's own ~/.codex/config.toml and are inherited wholesale. thread/start does accept an arbitrary config override map (ThreadStartParams.config, the same shape as Codex's -c overrides), so narrowing or clearing mcp_servers for a specific thread class looks mechanically possible — untested.

Non-prescriptive, and the choice is a policy call rather than a patch:

1. Leave it alone. A reviewer that can reach the user's MCP servers is a feature; the workspace is the right place to say "do not call this one" (which is what the downstream repo did in patriyang/obsidian-vault#652).
2. Scope MCP servers per thread class. Review threads are short, read-only, and self-contained; dropping MCP from them removes a whole class of stall at the cost of tools a reviewer might genuinely want.
3. Probe and drop. Ask each server whether it can serve this workspace before offering it. Most protocol-correct, most work, and depends on servers answering a health question promptly — the exact thing the failing server did not do.

Option 2 or 3 would need to establish first that config: { mcp_servers: ... } on thread/start actually takes effect against a live app-server; the generated types permit it, but nothing in this repo exercises it.

Related

• tool-in-flight watchdog kills the whole review turn when an MCP call never returns, instead of failing the call #100 — parent; the three answered sub-questions.
• Classify watchdog-aborted turns, give MCP calls their own budget, and pace retryable failures #104 — the PR that closed tool-in-flight watchdog kills the whole review turn when an MCP call never returns, instead of failing the call #100 without taking this on.

[patriyang]

Live reproduction while working #102

The final branch review dispatched during the #102 fix stalled on exactly the failure this issue describes. From the job log (review-msp8714r-olp7hz):

[2026-08-11T22:23:39.520Z] Calling codegraph/codegraph_explore.
[2026-08-11T22:26:39.657Z] Codex turn stalled (tool-in-flight): no activity for 180s while
  "Calling codegraph/codegraph_explore." was in flight [budget 180s; measured 180s since the
  last of 360 activity events at 2026-08-11T22:23:39.654Z]. Interrupting and aborting the turn.

The turn was classified failureClass: "stalled" and returned no findings. A fresh review --background dispatch against the identical tree completed normally, so the stall cost one full review cycle (~3 min to the watchdog, plus the re-dispatch) rather than producing a wrong result.

The detail that makes this recurrent, not incidental

.codegraph/ is untracked and not in .gitignore, so it exists only in whichever checkout was indexed:

$ ls -d ../codex-plugin-cc/.codegraph ../codex-plugin-cc-issue-102/.codegraph
../codex-plugin-cc/.codegraph
ls: ../codex-plugin-cc-issue-102/.codegraph: No such file or directory

Every worktree created by this repo's own fix/-branch workflow therefore starts without the index — which is precisely the condition (no .codegraph/ index in this workspace) under which the server hangs instead of answering. So the plugin's standard development loop reproduces this on the review step of essentially every worktree-based change, not just in the downstream repo from the original incident.

What this does and does not settle

It does not decide the policy question in this issue. It does add evidence against option 1 (leave it alone): the "workspace says do not call this one" remedy has to be re-applied per worktree for a directory that is untracked by design, which is not a durable fix.

It also supplies the missing datapoint for option 3 (probe and drop): this server does not fail fast on an unservable workspace — it does not answer at all, so a health probe against it would hang on the same call the reviewer hangs on, unless the probe carries its own much shorter timeout.

No change requested here; recording the reproduction so the decision is made against observed behavior rather than the single original incident.