Codex companion review hangs before first JetBrains IDEA MCP tool call when resources/list never returns

What version of Codex CLI is running?

codex-cli 0.135.0

Node used by the companion wrapper: v24.13.0

What platform is your computer?

macOS / Darwin 25.5.0 arm64

What issue are you seeing?

A real codex-companion.mjs review --wait run can hang indefinitely when JetBrains IDEA MCP is enabled.

The visible companion progress stops at the first IDEA MCP tool call, for example:

Calling idea/get_file_problems.

This was reproduced on a local Streamable HTTP JetBrains IDEA MCP server:

http://127.0.0.1:64342/stream
IntelliJ IDEA MCP Server 2026.1.2

Important nuance: the IDEA MCP server itself is not globally dead. Direct HTTP probes using a normal session flow show that regular tool operations work:

• initialize succeeds
• tools/list succeeds
• tools/call search_symbol returns in about 1s
• tools/call get_symbol_info returns immediately
• tools/call get_file_problems returns rather than hanging; in one probe it returned a timed-out inspection result after about 5s

However, the real Codex companion review still hangs on the first IDEA use.

What steps can reproduce the bug?

1. Configure Codex with a local JetBrains IDEA MCP Streamable HTTP server:

``toml
[mcp_servers.idea]
url = "http://127.0.0.1:64342/stream"
``

1. Open/index a Java project in IntelliJ IDEA with IDEA MCP Server 2026.1.2 running.
2. Run a real companion review from a repository with a working-tree diff:

``bash
node /path/to/codex/scripts/codex-companion.mjs review --wait
``

1. Allow the model to use IDEA MCP for code-intelligence operations.
2. The review gets stuck at the first IDEA MCP operation. In my run the job log stopped at:

``text
Calling idea/get_file_problems.
``

What did the wire trace show?

I placed a transparent HTTP proxy between Codex and the IDEA MCP server.

For the hanging review, Codex successfully completed the initial MCP session setup:

• initialize returned an mcp-session-id
• notifications/initialized included that mcp-session-id
• the SSE GET /stream included that mcp-session-id
• tools/list included that mcp-session-id and returned normally

At the point where the companion log showed Calling idea/get_file_problems, the next actual request on the wire was not tools/call. It was:

{"jsonrpc":"2.0","id":2,"method":"resources/list","params":{"_meta":{"progressToken":1}}}

That resources/list request also included the correct mcp-session-id header, but no response status/body arrived before the review was killed after waiting. So this does not look like a missing session-id header for tools/call in this trace; the client appears to be stuck before sending tools/call.

A direct probe to the same IDEA MCP server also showed that resources/list does not return:

curl: (28) Operation timed out after 10002 milliseconds with 0 bytes received

What is the expected behavior?

Codex should not let an optional resources/list probe block the actual tool call or the entire review indefinitely.

A robust behavior would be one of:

• skip resources/list when the server did not advertise resources capability,
• apply a short timeout to resources/list and continue with tools/call,
• treat resources/list failure/hang as non-fatal for tools-only servers,
• or surface a bounded MCP error instead of hanging the whole review turn.

Why this seems client-side actionable

The IDEA MCP server behavior is also questionable: if it does not support resources, it should return a JSON-RPC error such as -32601 or an empty resources list, not hang.

But from the Codex side, the user-visible failure is that Codex companion review has no safe timeout/fallback around this protocol probe, so a single non-returning optional MCP method stalls the whole review before the real tools/call is sent.

Workaround

Adding instructions that tell the model to treat IDEA MCP as unavailable avoids the hang because it prevents entering the IDEA MCP dispatch path at all. Telling the model specifically not to call resources/list is not sufficient, because resources/list is sent by the MCP client layer, not chosen by the model as a tool.

Related issue checked

This is adjacent to but not the same as #15815. In this trace, requests up to and including resources/list did include the mcp-session-id header. The observed hang happened before any tools/call was placed on the wire.