Skip to content

Codex blocks first model request on slow MCP tools/list #28640

Open
Open
Codex blocks first model request on slow MCP tools/list#28640
Labels
CLIIssues related to the Codex CLIbugSomething isn't workingmcpIssues related to the use of model context protocol (MCP) serversperformance

Description

@trackoor
trackoor
opened on Jun 17, 2026

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    CLIIssues related to the Codex CLI
    mcpIssues related to the use of model context protocol (MCP) servers
    performance
    on Jun 17, 2026

  2. github-actions commented on Jun 17, 2026

    @github-actions
    github-actionsBot
    on Jun 17, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. Necmttn commented on Jun 22, 2026

    @Necmttn
    Necmttn
    on Jun 22, 2026

    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

  4. tangweigang-jpg commented on Jun 23, 2026

    @tangweigang-jpg
    tangweigang-jpg
    on Jun 23, 2026

    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.

  5. starSumi commented on Jun 25, 2026

    @starSumi
    starSumi
    on Jun 25, 2026

    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 modelcontextprotocol/modelcontextprotocol#2036 and modelcontextprotocol/modelcontextprotocol#1888: meta-tools plus listChanged can work, but the meta-action has to be a normal listed tool for the model to use it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    CLIIssues related to the Codex CLIbugSomething isn't workingmcpIssues related to the use of model context protocol (MCP) serversperformance

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions