›_ Codex Issues
Codex Issues / #5770

MCP not listing tools, timeout 10 seconds

Resolved 💬 3 comments Opened Oct 26, 2025 by phillippc Closed Oct 26, 2025
💡 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.50.0

What subscription do you have?

pro

Which model were you using?

gpt5-codex

What platform is your computer?

macosx m4

What issue are you seeing?

when calling a mcp server that has previously worked, suddenly i get timeout on startup of codex-cli.
2025-10-26T11:15:37.223575Z WARN Failed to list tools for MCP server 'bhmcp': Err(
Error {
context: "timed out awaiting tools/list after 10s",
source: Elapsed(
(),
),
},
)
2025-10-26T11:15:37.223653Z INFO aggregated 0 tools from 1 servers

the mcp server is responding however when using curl to verify.

What steps can reproduce the bug?

Uploaded thread: 019a2026-73fe-7e71-a2c1

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 10 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #5677
  • #5444
  • #4400

Powered by Codex Action

phillippc · 10 months ago

I’ve reproduced the timeout with Codex CLI 0.50.0 and captured both the server response and Codex’s internal trace to show the
sequence.

  1. Server response arrives immediately

Running the exact tools/list payload over HTTPS returns HTTP 200 in ~300 ms with the full 15‑tool catalog and
_meta.progressToken. (Verified with curl -H 'MCP-Protocol-Version: 2025-06-18' -H 'Authorization: Bearer …' POSTing
{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{"_meta":{"progressToken":0}}}`.)

  1. Codex logs show the response is received and acknowledged

With RUST_LOG=trace, Codex emits:

INFO serve_inner: Service initialized … logging={"setLevel": Bool(true)} …
TRACE serve_inner: new event evt=ProxyMessage(Request … ListToolsRequest …)
TRACE transport_worker: got new sse stream
TRACE serve_inner: new event evt=SendTaskResult(Request { id: Number(1), result: Ok(()) })
DEBUG sse stream terminated

So the client accepts the response and tears down the stream immediately after the server reply.

  1. But Codex still times out 20 s later

WARN Failed to list tools for MCP server 'bhmcp': Err(
Error { context: "timed out awaiting tools/list after 20s", source: Elapsed(()) }
)
INFO aggregated 0 tools from 1 servers

This happens despite the successful SendTaskResult … Ok(()) above.

The server side confirms matching timestamps: tools/list answer logged at … 58.753Z and streams notifications/message via SSE
without errors.

phillippc · 10 months ago

• Here’s what finally fixed it on our side, in case it helps other MCP implementers:

  • The server was replying to tools/list with SSE frames tagged event: jsonrpc. Codex’s Rust RMCP client only treats blank/message

events as JSON-RPC payloads, so it dropped the frame, never resolved the promise, and then hit its 20 s timeout.

  • Switching the controller to emit SSE replies without forcing an event name (i.e., let the event default to “message”) made Codex

process the response immediately. The payload hadn’t changed—just the event name.

  • After redeploying that tweak, /mcp reload completed successfully and the catalog populated.

If you’re building an MCP server, make sure your streamable HTTP responses use the default SSE event name for request/response
messages.