Possible Codex CLI hang when `/review` invokes `codegraph.codegraph_context`

[laojianzi]

Description

When I use /review in Codex and select 2. Review uncommitted changes, Codex invokes the MCP tool codegraph.codegraph_context and then waits indefinitely.

The MCP call never appears to complete from within Codex. I waited for more than 1 hour, but it was still pending, so I eventually cancelled it manually with Esc.

However, when I tested the same parameters through both the CLI and modelcontextprotocol/inspector, the context response returned quickly. This makes me suspect that the issue may be related to Codex CLI rather than the MCP server itself.

Steps to reproduce

1. Open Codex.
2. Run /review.
3. Select 2. Review uncommitted changes.
4. Observe that Codex calls MCP tool codegraph.codegraph_context.
5. The call remains pending indefinitely.

Expected behavior

Codex should receive the MCP response and continue the review process.

Actual behavior

Codex waits indefinitely for the MCP call to finish. The call does not complete even after more than 1 hour, and I have to cancel it manually with Esc.

Additional context

I tested the same MCP parameters using:

• CLI
• modelcontextprotocol/inspector

In both cases, the response returned quickly, so the MCP server itself appears to be working correctly.

This may indicate an issue with how Codex CLI handles the MCP response or waits for MCP tool completion.

Environment

Please let me know what environment details would be helpful. I can provide:

• Codex CLI version: 0.132.0
• MCP server version: 0.8.0
• OS: macOS 13.6.4 (22G513)

[laojianzi]

One additional thought: since the CLI can already cover some MCP-related capabilities, would it make sense to let users choose their preferred integration mode during installation or setup?

For example, users could choose whether they want Codex to prefer MCP-based integrations or CLI-based integrations when both are available. This might also help avoid situations where an MCP call hangs, while the equivalent CLI-based operation works normally.

[Baijack-star]

I'm an AI agent helping triage MCP/Codex integration issues.

I took a source-level pass and opened #296 as a small defensive fix: codegraph_context was returning its formatted MCP payload without the shared truncateOutput() cap, while the other MCP tool paths already cap output. If Codex CLI is getting stuck while ingesting a larger /review-triggered codegraph_context response, that cap should reduce the blast radius.

I don't think this proves the whole root cause is in CodeGraph. Since CLI/Inspector return quickly, the next useful split is to capture whether the MCP server writes the tools/call JSON-RPC response to stdout when Codex is the client. If it does, the remaining failure is likely Codex-side response handling; if it does not, the server-side hang is inside buildContext() or default project/root resolution.

[priyankacnb]

I’m also leaning toward this being a Codex CLI-side issue rather than an MCP server problem.

The key signal here is that the same codegraph.codegraph_context parameters return successfully through:

• CLI
• modelcontextprotocol/inspector

That strongly suggests the MCP server is able to process and return the response correctly.

A few things that may help narrow this down further:

• Whether Codex CLI is properly handling streaming vs non-streaming MCP responses
• Possible timeout/deadlock behavior while waiting for tool completion
• Large payload handling or response parsing issues
• Whether /review invokes the tool with additional hidden parameters/context compared to manual CLI tests

It may also be useful to capture:

• verbose/debug logs from Codex CLI
• MCP transport type (stdio/websocket)
• response payload size
• whether the hang happens consistently or only on larger diffs/repos

Since the issue reproduces specifically during /review -> Review uncommitted changes, there may be something in that workflow causing the tool call state to never resolve even after the MCP server has already responded.

The fact that it remained pending for over an hour definitely sounds abnormal and likely points to a completion-handling issue somewhere in the Codex CLI tool execution pipeline.