Codex CLI hangs when configured to use codex mcp-server as an MCP server
Open 💬 11 comments Opened Nov 14, 2025 by NikTheGeek1
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
What version of Codex is running?
codex-cli 0.58.0
What subscription do you have?
pro
Which model were you using?
gpt-5.1-codex
What platform is your computer?
Darwin 24.6.0 arm64 arm
What issue are you seeing?
When configuring Codex CLI to connect to Codex’s own MCP server (via the codex mcp-server subcommand), the Codex CLI hangs indefinitely when listing MCP servers (e.g., using the /mcp command). The MCP server never initializes successfully and no tools are exposed.
What steps can reproduce the bug?
- Add the following to ~/.codex/config.toml:
[mcp_servers.codex]
command = "codex"
args = ["mcp-server"]
- Start the Codex CLI with:
codex - In the CLI, run:
/mcp
What is the expected behavior?
Expected Behavior
• Codex CLI should successfully start codex mcp-server as an MCP server.
• /mcp should list the MCP server and its tools.
Actual Behavior
• /mcp hangs indefinitely
• Trying to kill the Codex CLI with cmd + C doesn't work
• No MCP tools ever appear.
• The child codex mcp-server process appears to start but the CLI never completes the MCP handshake.
Additional information
_No response_
11 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
same issue
@Zyy0530 If you want a workaround, I found a reliable approach:
use a small Node.js HTTP MCP wrapper instead of connecting the Codex CLI directly to codex mcp-server.
The idea is to run a tiny HTTP server that:
Then in your config.toml, enable the HTTP MCP client and point Codex to the wrapper:
This gives you full access to all Codex tools, just routed through a stable HTTP layer instead of the stdio path that currently hangs.
Not ideal long-term, but it’s a clean and reliable workaround until the direct stdio communication is fixed.
same issue
Same here. Used to work great, until it didnt.
@thomaswitt, you mentioned that it used to work great. Does that mean you suspect a regression? If so, can you provide any further details, including repro steps and the version where you saw the behavior change? We haven't spent much time on this issue because we don't have a good repro.
@etraut-openai I added codex as an MCP server in claude:
I see that Claude calls the MCP server:
codex - codex (MCP)(prompt: "Review the following architecture plan for …but then runs basically for 30-40+ minutes. It insists that the MCP call aborted:
I also see in the ps task list that the command itself is running:
codex -m gpt-5.2-codex -s read-only -a never -c model_reasoning_effort=high mcp-serverThis doesnt happen EVERY time, but in 70% of the time.
I didn't have these problems until around end of this year. Unfortunately I can't pinpoint them to a specific release.
OK, thanks for the details. That's still not a lot to go on. Since this issue has been reported only by a few users in the past several months, it hasn't been a big priority for us to investigate (relative to many other higher-impact issues), so community help is welcome here. If anyone is able to pinpoint concrete repro steps — or better yet, root cause the problem, that would be most helpful.
@etraut-openai It would be helpful if I could SOMEWHERE get some debugging output from Codex. I don't know if it's even starting to work, if it hangs because of questions (tried to avoid that with -a never) ... at least a mcp list command for the current thread ids and get an in-between result would be very helpful, as it apparently doesn't stream his results (that's at least what I assume).
Claudes session logs are also not much more insightful:
@etraut-openai I also found this debug output in /private/tmp/...claude../tasks/, in case that helps....
After a while, this file disappears, but claude still says
codex - codex (MCP)(prompt: "You are reviewing...So maybe the commuication that the job is done doesnt go well?
I can reproduce a narrower root cause for this on
codex-cli 0.114.0.This is not a full MCP handshake failure.
initializeandtools/listsucceed. The hang is specifically thatcodex mcp-servernever replies to:resources/listresources/templates/listThat explains why
/mcpwedges: the snapshot path waits for tools, resources, and resource templates together, so tools may already be available but the overall/mcprequest stays blocked until the resource timeout expires.Minimal JSON-RPC repro
This reproduces against a command that launches
codex ... mcp-serverover stdio.Control:
initializeandtools/listworkObserved:
initializerespondsresources/listbeforetimeoutkills the pipelineFailure:
resources/templates/listnever respondsSame setup, replacing the last request with:
Observed:
initializerespondsresources/templates/listSource-level explanation
Current source appears to explain this:
ClientRequest::ListResourcesRequestandClientRequest::ListResourceTemplatesRequestare acceptedhandle_list_resources()andhandle_list_resource_templates()only log and returnRequestIdsend_response(...)orsend_error(...)So the server is silently accepting the request and then never replying.
Requested fixes
Server-side
For
resources/listandresources/templates/list, please either:METHOD_NOT_FOUNDThe current behavior of accepting the request and never replying is a protocol bug.
Client-side
/mcpshould not block tool listing on optional resource enumeration.Even if one server:
/mcpshould still render tools and remain responsive.This also looks related to the broader “Codex over-indexes on resources/list” issue family for tool-only MCP servers.