Claude Code Codex plugin native review hangs/fails with IDEA MCP enabled by default

Summary

When the Claude Code Codex plugin is used with the default configuration, it inherits the user's global Codex MCP servers. If JetBrains IDEA MCP is enabled, /codex:review can hang or fail when the native review/start flow tries to call an IDEA MCP tool.

This appears to be distinct from #25061. In my current setup, the JetBrains IDEA MCP server is reachable through a stdio bridge, and ordinary Codex / Codex Desktop interactions can call IDEA MCP tools successfully. The failure is specific to the Claude Code plugin's native review path.

Environment

• macOS
• Codex CLI: codex-cli 0.135.0
• Claude Code Codex plugin: openai-codex/codex 1.0.4
• JetBrains IDEA MCP configured in the user's global Codex config
• IDEA MCP transport in this setup is a stdio wrapper around the JetBrains streamable HTTP endpoint

What Happens

With IDEA MCP enabled in the user's Codex config, running /codex:review from Claude Code starts a Codex app-server native review:

[codex] Starting Codex review thread.
[codex] Thread ready (...)
[codex] Reviewer started: current changes
...
[codex] Calling idea/search_symbol.

At that point the app-server emits an MCP elicitation request for the IDEA tool approval. The logged request is for the idea server and a normal tool call such as:

method: mcpServer/elicitation/request
serverName: idea
tool: search_symbol
params: {
  q: "WangwangStartAnalyzer",
  projectPath: "/path/to/repo",
  limit: 20
}

The plugin then attempts to resolve that elicitation, but it is resolved against the wrong session/thread and fails:

ResolveElicitation {
  server_name: "idea",
  request_id: "mcp_tool_call_approval_...",
  decision: Accept,
  content: Some(Object {}),
  meta: None
}

failed to resolve elicitation request in session error=elicitation request not found

The review does not return a normal result after this. From the user's perspective this looks like /codex:review is stuck on the IDEA MCP call.

Expected Behavior

If the plugin inherits enabled MCP servers, native /codex:review should either:

1. handle MCP elicitations for tools invoked inside the review thread correctly, or
2. avoid inheriting MCP servers that require approval unless the plugin can route the approval to the correct app-server session/thread.

Why This Seems Specific To The Review Path

The same IDEA MCP setup works in ordinary Codex / Codex Desktop interactions. Direct IDEA MCP calls such as get_repositories, search_symbol, and get_file_problems complete successfully there.

The problematic path is the Claude Code plugin's native review flow, which uses review/start. That flow appears to create/use an internal review session/thread, while the elicitation resolution is attempted against the source thread/session, resulting in elicitation request not found.

Related Review Gate Observation

The stop review gate is a separate path: it runs codex-companion.mjs task, which uses ordinary turn/start, not native review/start. However, under default plugin behavior it can still reuse a shared app-server broker that was started with IDEA MCP enabled, so the gate task may also try IDEA MCP tools. In my local test it did not hang, but it did call idea/search_symbol before falling back to local shell inspection.

Workaround

For unattended review flows, disabling IDEA MCP for the app-server process avoids the hang/failure:

codex app-server -c mcp_servers.idea.enabled=false

For stop review gate tasks, this also needs to avoid reusing an already-running shared broker; otherwise the disabled setting may not take effect.

Impact

This makes Claude Code's Codex review integration unreliable for users who have IDEA MCP enabled globally, even though the same MCP server works from ordinary Codex surfaces.