›_ Codex Issues
Codex Issues / #36190

Custom provider reports initialized Model Context Protocol servers as uninitialized

Open 💬 4 comments Opened Jul 30, 2026 by ciechanowiec

Environment

  • Codex command-line interface: codex-cli 0.146.0
  • Subscription: Pro Lite
  • Model: gpt-5.6-sol
  • Operating system: macOS 26.5.2 on arm64
  • Terminal: iTerm2 3.6.11

codex doctor --summary --ascii reports 17 successful checks, 1 idle check, 0 warnings, and 0 failures. The WebSocket connectivity check receives HTTP status 101. All configured provider endpoints are reachable. Authentication is configured. The Model Context Protocol (MCP) configuration is valid.

Observed Behavior

A custom model provider with supports_websockets = false makes the terminal interface report that Model Context Protocol (MCP) startup was interrupted. The warning identifies MCP servers as uninitialized after the servers completed their initialization handshakes.

One direct-endpoint run produced the following warning:

MCP startup interrupted. The following servers were not initialized:
chrome_devtools, codex_apps, context7, drawio, playwright

The server list varies between runs because the warning occurs at different points in the startup sequence. Before Codex displays the warning, the Codex log contains Service initialized as client for servers named in the warning.

Reproduction

  1. Configure at least one Model Context Protocol (MCP) server.
  2. Authenticate Codex with ChatGPT.
  3. Start Codex with a direct custom provider that disables WebSockets.

``bash
codex --no-alt-screen \
-c 'model_provider="direct_http_test"' \
-c 'model_providers.direct_http_test.name="direct-http-test"' \
-c 'model_providers.direct_http_test.base_url="https://chatgpt.com/backend-api/codex"' \
-c 'model_providers.direct_http_test.wire_api="responses"' \
-c 'model_providers.direct_http_test.requires_openai_auth=true' \
-c 'model_providers.direct_http_test.supports_websockets=false'
``

  1. Wait for MCP startup.

The direct custom provider connects to the standard ChatGPT Codex endpoint.

Expected Behavior

The model provider's Responses transport setting should not invalidate successful Model Context Protocol (MCP) initialization handshakes. An MCP server that returns a successful initialization response should remain ready. Codex should not report the server as uninitialized.

Controlled Comparison

The two control runs use the same authentication and Model Context Protocol (MCP) configuration as the reproduction.

| Provider configuration | supports_websockets | MCP startup result |
| --- | --- | --- |
| Direct custom provider | true | Startup completes without the warning |
| Built-in provider | Not configured | Startup completes without the warning |

View original on GitHub ↗

4 Comments

mtmitchel · 28 days ago

I’m seeing the same false “uninitialized” warning without a custom provider.

Environment:

  • Fedora 44, x86_64
  • Codex CLI/TUI 0.146.0
  • Built-in OpenAI provider with ChatGPT authentication
  • gpt-5.6-sol, reasoning effort max
  • WebSockets enabled and working

codex doctor --json, run outside the restricted sandbox, reported:

  • MCP configuration: OK
  • Provider reachability: OK
  • WebSocket handshake: HTTP 101
  • Codex version: current

The TUI displayed:

MCP startup interrupted. The following servers were not initialized: MCP_DOCKER, codex_apps, github, openaiDeveloperDocs, sequential-thinking

However, the logs showed successful initialization for all five servers before later startup rounds were cancelled. I then made a read-only tool call through each listed
server from the same thread, and all five succeeded.

This suggests the false “uninitialized” status is not limited to custom providers or supports_websockets = false. It also occurs with the built-in provider and working
WebSockets.

styler-ai · 28 days ago

I can reproduce this false "uninitialized" warning on native Windows with the built-in OpenAI provider.

Environment

  • Codex CLI/TUI: 0.146.0
  • OS: Windows 11 Pro 10.0.26200, x64
  • Shell/terminal: PowerShell 7.6.4 in Windows Terminal
  • Provider/auth: built-in OpenAI provider with ChatGPT authentication
  • Model: gpt-5.6-sol
  • A second Codex CLI 0.146 session was running during this reproduction

Observed behavior

The TUI displayed:

MCP startup interrupted. The following servers were not initialized: codex_apps, context7, node_repl, projectatlas

The warning did not correspond to four process or handshake failures:

  • context7, node_repl, and projectatlas were all launched as child processes and remained running.
  • The registered executables and ProjectAtlas config/database paths existed.
  • codex mcp list and codex mcp get showed the three configured stdio servers enabled.
  • The startup log contained no matching executable-not-found, authentication, database-lock, handshake-failure, or startup-timeout error for these servers.
  • Subsequent dynamic tool discovery exposed tools from all four listed servers in the same thread.
  • Context7 already had startup_timeout_sec = 60; Node REPL had startup_timeout_sec = 120. The TUI emitted the cancellation-style warning before either configured timeout elapsed.

This appears consistent with the other reports here: a successful or still-viable server is presented as uninitialized after its startup round is cancelled or the TUI loses/settles startup-status events. In rust-v0.146.0, finish_mcp_startup_after_lag() classifies Starting or missing statuses as cancelled, and AppServerEvent::Lagged invokes that path:

The second concurrent CLI session may increase event or process pressure, but it does not look like the root cause: no server reported a concrete resource-conflict failure, and unrelated servers were cancelled together.

Expected behavior

Servers that have initialized successfully should remain Ready. Event-consumer lag, a refresh, or another concurrent Codex session should not downgrade ready servers or report them as uninitialized. If status delivery is incomplete, the TUI should resynchronize from the connection manager before producing the warning.

In-product feedback

Submitted through Codex feedback/upload with logs excluded.

Tracking thread ID: 019fb74a-1cb9-76b3-80f2-e97a37d5910f

redsteinway · 28 days ago

Additional data point from Windows: I can reproduce the same MCP startup interrupted warning on codex-cli 0.146.0 using the standard OpenAI configuration (not a custom provider).

The TUI reported analytics-mcp, context7, mobile-mcp, and next-devtools as not initialized. However, the log from that same TUI process records successful Service initialized as client handshakes for all four within about five seconds of launch. The same four also initialized successfully again during a later thread resume.

A codex exec smoke test that temporarily marked all four servers as required=true also completed successfully. This is consistent with a startup-status/reporting race rather than necessarily a per-server timeout or handshake failure.

This differs from the custom-provider reproduction in this issue, so I am offering it as an additional data point rather than evidence of a confirmed common root cause. I can provide a redacted trace if helpful.

nonsync · 13 days ago

I reproduced the same stale “uninitialized” warning with the built-in provider, so the trigger is not limited to a custom provider with WebSockets disabled.

Environment:

  • Codex CLI 0.147.0
  • macOS, fresh Codex session launched in a normal Orca 1.4.175 terminal
  • Built-in provider; no custom model_provider override
  • Higgsfield remained enabled with unchanged configuration and OAuth state

Observed TUI warning:

MCP startup interrupted. The following servers were not initialized: higgsfield, openaiDeveloperDocs

Relevant log timeline (2026-08-14 KST):

  • 22:25:10.710 — node_repl initialized
  • 22:25:10.815 — codex_apps initialized
  • 22:25:11.024 — openaiDeveloperDocs initialized
  • 22:25:11.528 — startup prewarm omitted pending optional MCP server higgsfield
  • 22:25:12.137 — higgsfield initialized
  • 22:25:54.894 — /mcp inventory built with 4 available servers, 0 unavailable
  • 22:25:54.909–22:25:54.917 — the four diagnostic MCP tasks were cancelled immediately after the inventory result

This looks like the warning snapshot races late successful initialization and/or diagnostic-task teardown. The servers are usable after the warning.

I uploaded the session logs and redacted diagnostics through /feedback. Uploaded thread: 01a00072-ab92-7bb0-821a-5ac612c1bb09.