Claude Code review hangs on MCP tool call when an MCP server triggers elicitation

Using the openai-codex Claude Code plugin for /codex:review can hang indefinitely when the spawned Codex review thread tries to call an MCP tool from fff.

The strongest local evidence points to a protocol mismatch in the plugin integration:

• current Codex app-server protocol includes server-initiated requests such as mcpServer/elicitation/request
• openai-codex plugin 1.0.2 does not appear to support server requests and responds with Unsupported server request: <method>
• stalled review sessions consistently show ResolveElicitation { server_name: "fff", ... decision: Decline } followed by failed to resolve elicitation request in session error=elicitation request not found

Because of that, the review gets stuck right after Calling fff/find_files or Calling fff/multi_grep.

Environment

• OS: Windows
• Claude Code plugin: @openai/codex-plugin-cc 1.0.2
• Codex CLI currently installed: codex-cli 0.122.0
• Observed with Codex app versions 0.121.0 and 0.122.0
• MCP server involved: fff-mcp.exe 0.6.1

What works

• fff-mcp.exe --healthcheck <repo> works
• direct MCP calls to find_files and multi_grep against fff work outside Claude Code review flow
• /codex:review works again when fff is removed from active Codex MCP servers

So this does not look like a general fff failure. It looks specific to the Claude Code plugin + Codex app-server review integration.

Reproduction

1. Install/enable openai-codex plugin in Claude Code.
2. Ensure global Codex config enables fff as an MCP server.
3. Run /codex:review in a repo where the reviewer decides to use fff/find_files or fff/multi_grep.
4. Observe that the review UI reaches Calling fff/find_files. or Calling fff/multi_grep. and then never completes.

Expected

• The review either completes normally, or fails cleanly with an actionable error.
• If the app-server emits an MCP elicitation / approval request, the plugin should handle it correctly.
• If approvalPolicy = "never" is used, read-only MCP search calls should not get stuck in an unresolved elicitation path.

Actual

• Review stalls indefinitely.
• Plugin state/logs stop after:
  • Calling fff/find_files.
  • Calling fff/multi_grep.
• Codex logs show:
  • ResolveElicitation { server_name: "fff", request_id: "mcp_tool_call_approval_call_...", decision: Decline }
  • failed to resolve elicitation request in session error=elicitation request not found

Evidence

1. Review jobs stall exactly on the fff tool call

Examples from local Claude plugin state:

• review-moa11nxv-0934lo.log: Calling fff/find_files.
• review-moa294re-87ljju.log: Calling fff/multi_grep.
• review-moa3kgbj-vtg42d.log: Calling fff/multi_grep.

When fff was no longer active, a later review completed normally.

2. Stalled review threads always included fff in mcp_servers

Examples from Codex logs:

• stalled: mcp_servers="codex_apps, fff, qmd"
• stalled: mcp_servers="fff, codex_apps, qmd"
• successful later review: mcp_servers="qmd, codex_apps"

3. Codex core logs show broken elicitation resolution for fff

Examples:

ResolveElicitation { server_name: "fff", request_id: "mcp_tool_call_approval_call_...", decision: Decline }
failed to resolve elicitation request in session error=elicitation request not found

This happened in multiple stuck review threads.

4. The plugin starts review threads with approvalPolicy: "never" and sandbox: "read-only"

In the plugin source:

• plugins/codex/scripts/lib/codex.mjs

approvalPolicy: options.approvalPolicy ?? "never",
sandbox: options.sandbox ?? "read-only",

5. The plugin app-server client rejects all server-initiated requests

In:

• plugins/codex/scripts/lib/app-server.mjs

handleServerRequest(message) {
  this.sendMessage({
    id: message.id,
    error: buildJsonRpcError(-32601, `Unsupported server request: ${message.method}`)
  });
}

6. Current Codex app-server protocol includes MCP elicitation as a server request

Generated locally from current CLI via:

codex app-server generate-ts --out <tmp-dir>

The generated ServerRequest type includes:

{ "method": "mcpServer/elicitation/request", id: RequestId, params: McpServerElicitationRequestParams }

and there is a corresponding McpServerElicitationRequestResponse type.

Likely root cause

The openai-codex plugin appears to be built around an older or narrower app-server protocol shape where only client-initiated request/response plus notifications were expected.

Current Codex app-server protocol now includes server-initiated requests, including MCP elicitation or approval flows. The plugin client currently rejects these requests instead of handling or forwarding them. That likely breaks the fff MCP approval or elicitation path during review, leading to an internal ResolveElicitation attempt against a missing request and an indefinitely hung review.

Suggested fix directions

Primary fix in openai/codex-plugin-cc:

1. Regenerate and adopt current app-server protocol bindings.
2. Add handling for server requests, especially:
   • mcpServer/elicitation/request
   • other approval-related server requests that may occur during review
3. Either:
   • forward those requests into Claude Code correctly, or
   • auto-resolve them in a way consistent with approvalPolicy = "never"

Secondary or defensive fix on the Codex app-server side:

1. If approvalPolicy = "never" and an MCP tool call would require approval or elicitation, fail cleanly instead of hanging.
2. Consider whether read-only MCP search tools should bypass this path in review mode.

Why I think this belongs here first

The clearest actionable mismatch is in openai-codex plugin code:

• plugin explicitly uses approvalPolicy = "never"
• plugin explicitly rejects server requests
• current app-server protocol now includes server requests for MCP elicitation

So even if there is also an app-server-side robustness issue, the first obvious integration break seems to be in the plugin.

Start with plugins/codex/scripts/lib/app-server.mjs, especially handleServerRequest, and compare its behavior with the current app-server protocol generated by codex app-server generate-ts --out <tmp-dir>. Trace the mcpServer/elicitation/request flow alongside plugins/codex/scripts/lib/codex.mjs and the reported logs. Done means /codex:review handles or cleanly rejects the MCP elicitation path without hanging.