›_ Codex Issues
Codex Issues / #28640

Codex blocks first model request on slow MCP tools/list

Open 💬 4 comments Opened Jun 17, 2026 by trackoor
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Codex blocks first model request on slow MCP tools/list

What version of Codex CLI is running?

@openai/codex 0.140.0

What subscription do you have?

N/A. The reproduction uses a local OpenAI-compatible mock provider and a fake API key.

Which model were you using?

gpt-4 in the local mock-provider replay.

What platform is your computer?

Linux x86_64 in Docker (node:24-bookworm-based target image).

What terminal emulator and version are you using?

Non-interactive Docker/CI shell.

Codex doctor report

Not available in this minimal Docker reproduction.

What issue are you seeing?

Severity / performance impact: High. A slow MCP tools/list response delays the first provider request, so a local MCP server can block first-turn progress before the model receives the user task.

What steps can reproduce the bug?

Prerequisites: Docker, Python 3, and the GitHub CLI (gh) for the clone command below. The linked reproducer is self-contained and uses only Python standard-library modules plus Docker. It builds the affected CLI version from the public package registry, starts a local mock provider, and runs the CLI in an isolated workspace. The Docker run is limited to 2 CPUs and 4 GiB RAM by default.

Complete self-contained reproducer: https://gist.github.com/N0zoM1z0/c1b0f3c6248f2c7ff44ba9de2197c5c4

The Gist contains codex-mcp-tools-list-blocks-first-turn.reproduce.py. Download and run:

gh gist clone c1b0f3c6248f2c7ff44ba9de2197c5c4 codex-mcp-tools-list-blocks-first-turn-reproducer
cd codex-mcp-tools-list-blocks-first-turn-reproducer
python3 codex-mcp-tools-list-blocks-first-turn.reproduce.py

To reuse an already-built local image:

python3 codex-mcp-tools-list-blocks-first-turn.reproduce.py --skip-build

Expected successful reproduction output includes:

REPRODUCED

Observed evidence

The reproducer configures a local MCP server whose tools/list reply sleeps for 2500 ms. The first provider request is delayed by at least 2000 ms.

What is the expected behavior?

Codex should bound MCP discovery latency or proceed with a clear degraded state instead of blocking the first provider request indefinitely.

Additional information

Public-upstream status: This reproduces against stock public @openai/codex@0.140.0 built from npm.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 2 months ago

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

  • #28556

Powered by Codex Action

Necmttn · 2 months ago

The degraded path should be observable. If Codex bounds MCP discovery latency, the first turn record should say which servers were ready, which timed out, the tools/list deadline, elapsed ms per server, and whether the first model request started with a partial tool surface.

That avoids a worse failure mode: the first request proceeds, but users cannot tell whether a missing tool was unavailable, still loading, or intentionally excluded.

Generated with ax - https://github.com/Necmttn/ax

tangweigang-jpg · 2 months ago

This is a good place to define MCP discovery as a degraded dependency rather than a startup dependency.

The acceptance criteria I would want are:

  1. The first provider request has a fixed upper bound independent of the slowest MCP tools/list.
  2. A server with cached startup tools can expose the cached snapshot immediately while refresh continues.
  3. A server with no cache and pending startup is marked unavailable/degraded, not silently omitted and not blocking the task.
  4. The user-visible status says which MCP server is still starting, timed out, or unreachable.
  5. When startup later succeeds, the new tool set becomes available on the next safe refresh boundary rather than mutating the tool surface mid-turn.
  6. Tests cover both slow-but-eventually-successful and never-responds cases.

The important UX detail is that optional MCP extensions should fail like optional extensions. The core chat/model turn should still start, with a clear note that some tools are not ready yet.

starSumi · 2 months ago

One additional acceptance edge from a local MCP lazy-loading proxy PoC that seems relevant if Codex moves to a bounded/degraded tools/list path:

This is not a separate Codex repro. It is a protocol-level trap we hit while testing a proxy.

If Codex proceeds with a partial tool surface while one MCP server is still pending, the user/model still needs a model-callable recovery path. A raw out-of-band JSON-RPC refresh/load method is not enough, because normal model tool use goes through tools/call.

Failing shape:

tools/list -> fs_read, fs_write, mcp_load_server_github-cli
tools/call(name="mcp_load_server_github-cli") -> tool not found
custom JSON-RPC method mcp_load_server(...) -> loads server

Working shape:

tools/list -> fs_read, fs_write, mcp_load_server_github-cli
tools/call(name="mcp_load_server_github-cli") -> loads github-cli
next safe tools/list refresh -> github-cli tools replace the load meta-tool

Suggested acceptance criterion to add: if a server is degraded/pending and later recoverable, Codex should expose either a status-only unavailable state or a small recovery/load meta-tool that is itself callable through standard tools/call; tests should cover that standard client path, not only an internal refresh or custom JSON-RPC method.

This lines up with the MCP progressive-disclosure pattern discussed in https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/2036 and https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1888: meta-tools plus listChanged can work, but the meta-action has to be a normal listed tool for the model to use it.