›_ Codex Issues
Codex Issues / #37567

Qonto MCP regression in 0.147.0: startup completes without caching or exposing tools

Open 💬 4 comments Opened Aug 8, 2026 by dperetti
💡 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.146.0: Qonto MCP works
  • Codex CLI 0.147.0: Qonto MCP initialization fails
  • Codex Desktop client version observed in logs: 26.803.41515 (internal traces reference client version 0.147.0)

What operating system are you using?

macOS 26.5.2 (25F84)

What is the issue?

Qonto MCP tools are missing in Codex 0.147.0 although OAuth succeeds and the same MCP server works in Codex CLI 0.146.0.

Internal logs show:

MCP server tools unavailable while building tool list
server_name=qonto
has_cached_tools=false
startup_complete=true

The keychain credentials are loaded successfully, but the server is later omitted with:

omitting MCP server without an exact ready client server_name=qonto

MCP configuration

[mcp_servers.qonto]
url = "https://mcp.qonto.com/mcp"
  • Endpoint: https://mcp.qonto.com/mcp
  • Server identity: mcp-qonto version 0.2.0
  • Negotiated protocol version: 2025-06-18

Steps to reproduce

  1. Configure the Qonto MCP endpoint above.
  2. Run codex mcp login qonto and complete OAuth successfully.
  3. Start a new Codex Desktop conversation or Codex CLI 0.147.0 session.
  4. Request a Qonto tool such as qonto/get_organization.
  5. Observe that Qonto tools are unavailable or that Qonto is reported among MCP servers that failed to initialize.
  6. Reauthentication and new conversations do not fix the issue.

Control tests

  • An authenticated raw MCP initialize request returns HTTP 200 with text/event-stream.
  • The response advertises tools with listChanged: true.
  • An authenticated tools/list request returns 56 tools.
  • Codex CLI 0.146.0, using the same global configuration and keychain credentials, successfully executes:

``text
mcp: qonto/get_organization started
mcp: qonto/get_organization (completed)
``

  • Immediately after updating the CLI to 0.147.0, startup reports:

``text
MCP startup incomplete (failed: ..., qonto)
``

  • Other MCP integrations, including OpenAI documentation and authenticated Linear, work.

Expected behavior

Codex should register and expose the tools returned by Qonto's tools/list.

The 0.146.0 success versus 0.147.0 failure strongly suggests a regression in the 0.147.0 MCP connection manager or deferred tool catalog. A characteristic of Qonto's response may trigger the defect, but it is accepted by 0.146.0 and by direct standards-compliant MCP calls.

Feedback reference

Private Codex feedback thread: 019fe0cb-7026-78a2-9880-95e0dccc7381

No credentials, organization names, bank identifiers, UUIDs, transactions, or accounting data are included.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 20 days ago

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

  • #36932

Powered by Codex Action

wanou2c · 16 days ago

+1, also experiencing this on Windows with remote HTTP MCP servers (Lingxing/SellerSprite). 0.146.0 works, 0.147.0 fails with "omitting MCP server without an exact ready client".

Happy to provide logs if needed.

wanou2c · 15 days ago

Adding another Windows reproduction with remote HTTP MCP servers (Lingxing + SellerSprite).

Environment:

  • Codex Desktop 26.803.81509, engine 0.147.0-alpha.6.6 (also reproduced on 26.803.61601)
  • Windows 11 x64
  • Model: DeepSeek-V4-Flash via a local model catalog with "use_responses_lite": false

Symptoms match this report exactly:

  • MCP handshake succeeds and tools/list returns the full tool inventory
  • The app-server reports the servers as connected (mcpServerStatus/list with errorCode=null)
  • But the tools never appear in the Chat session tool catalog; the log shows omitting MCP server without an exact ready client
  • Reproduces both with direct Streamable HTTP URLs and with a local stdio proxy in front of the same servers
  • The same config works on 26.803.41515 and in Codex CLI 0.147.0-alpha.6.6

One data point that should help narrow the root cause: our model entry already sets "use_responses_lite": false, so the workaround from #33679 does not apply here ? this is not the Responses Lite tool-exposure path. It looks like the startup race from #35742/#34588: the server is still "pending" when the per-step tool catalog is captured, so it gets omitted. The startup grace period seems too short for remote HTTP servers on Windows.

HaoYue1027 · 7 days ago

Still reproduced on Desktop app-server 0.149.0 (MSIX 26.818.3698.0) and CLI 0.148.0; the local Streamable HTTP server itself is protocol-clean

Adding a reproduction from a local Streamable HTTP MCP server, consistent with #37567/#37976 and #38689.

Environment

  • OS: Windows 11, build 26200
  • Codex Desktop (ChatGPT desktop app): MSIX 26.818.3698.0; embedded app-server version read from the installed codex.exe binary string: 0.149.0
  • Codex CLI: v0.148.0
  • MCP server: local Streamable HTTP (Python mcp SDK 2.0.0 + uvicorn), http://127.0.0.1:8765/mcp, no auth; configured in ~/.codex/config.toml as [mcp_servers.kika-obsidian-http] with url only

Repro timeline (stable, 2026-08-21)

  1. codex mcp list / codex mcp get -> server enabled, transport streamable_http.
  2. Server-side protocol probe with the official mcp SDK 2.0 client: initialize OK, tools/list returns 17 tools, tools/call list_notes returns real data.
  3. Codex Desktop thread (fresh sessions, twice): no MCP tools in the thread tool registry, while /mcp lists the server as enabled.
  4. codex exec (CLI 0.148.0, both --sandbox read-only and workspace-write): model reports no MCP tools - same symptom as #38689.
  5. Control: hand-written JSON-RPC against the same endpoint (initialize + Mcp-Session-Id + tools/call list_notes) succeeds, returning the vault note list.

Causal isolation

  • The same server and config work at the protocol level and via direct JSON-RPC; the failure is in Codex's tool-catalog injection for streamable_http servers in both Desktop threads and CLI exec sessions, not in the server, transport, or configuration.
  • The regression persists in 0.148.0 (CLI) and 0.149.0 (Desktop app-server), both newer than the 0.147.0 in the original report. #38794 also reports 0.148.0-alpha.9 failing HTTP MCP tool calls that passed in 0.147.0.

Suggestions

  • Fix tool-catalog readiness for streamable_http servers in Desktop threads and CLI exec (the "omitting MCP server without an exact ready client" path).
  • Regression test: with a local no-auth streamable_http server, assert tools/list output is exposed both in codex exec and in a Desktop thread; this covers the 0.146 -> 0.147+ regression window.

Scope

  • Verified only with a local no-auth server on 127.0.0.1; no OAuth or remote-server cases tested. No code-level root cause identified from this side.

Request

  • Expected: tools from an enabled streamable_http MCP server appear in Desktop threads and CLI exec sessions (they did in 0.146.0 per earlier comments).
  • Actual: handshake succeeds and direct JSON-RPC works, but tools are omitted from the session tool catalog in 0.148.0/0.149.0.
  • Please confirm and fix; happy to provide full logs.