Outdated rmcp 0.15.0 dependency may contribute to HTTP MCP session failures

What version of Codex CLI is running?

0.116.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.4

What platform is your computer?

Darwin 25.4.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

iTerm2

What issue are you seeing?

Codex CLI fails to call tools on Streamable HTTP MCP servers with:

Session not initialized. Only 'initialize' and 'ping' are allowed before initialization. Got:
tools/call

The initialize and tools/list phases succeed, but subsequent tools/call requests arrive at the
server without a valid mcp-session-id header, hitting an uninitialized session.

This was reported against a tower-mcp HTTP server (joshrotenberg/cratesio-mcp#61, filed 2026-03-04).
Both Codex CLI and Cursor failed identically.

Codex's codex-rmcp-client depends on rmcp = "0.15.0" (codex-rs/Cargo.toml:273). rmcp appears to
have shipped several session-related fixes between 0.15 and 1.2:

• 1fe5d1e (2026-03-03) - fix(streamable-http): map stale session 401 to status-aware error
• 27b0096 (2026-03-11) - feat: transparent session re-init on HTTP 404
• 3ea8c3c - feat: add configuration for transparent session re-init

What steps can reproduce the bug?

1. Run a Streamable HTTP MCP server that enforces session IDs (e.g. any tower-mcp HTTP server without

optional_sessions()).

1. Configure Codex CLI to use it:

[mcp_servers.myserver]
url = "http://localhost:3000/"

1. Ask Codex to call a tool from that server.
2. initialize and tools/list succeed during setup, but tools/call fails with the session error above.

We verified this with rmcp 1.2 (current HEAD) against the same tower-mcp server with strict session
enforcement. All operations succeed -- the session ID is correctly forwarded on every request. An rmcp
0.15-era client may not correctly forward mcp-session-id on requests after initialization, based on the
error pattern and the fixes present in 1.x.

What is the expected behavior?

tools/call requests should include the mcp-session-id header obtained during initialization,
maintaining session continuity with the server as required by the MCP 2025-11-25 spec.

Additional information

Server-side workaround: tower-mcp 0.9.2+ provides HttpTransport::optional_sessions() which creates a
transient pre-initialized session for requests arriving without mcp-session-id. In our local testing,
enabling this made Codex-compatible HTTP tool calls succeed. tower-mcp's own HTTP client correctly
stores and forwards mcp-session-id, so the observed failure does not appear to be server-side.

Possibly related open issues (similar pattern -- HTTP MCP init succeeds but subsequent operations
fail):

• #13920 - Codex desktop cannot reliably connect to local Streamable HTTP MCP servers
• #14115 - codex exec initializes MCP and lists tools but never sends tools/call

Note: #14115 may involve a separate MCP registry/discovery issue in codex exec rather than (or in
addition to) session handling.

Upgrade scope: The codex-rmcp-client integration surface is broad (custom StreamableHttpClient impl,
ClientHandler, OAuth state management), so upgrading to rmcp 1.x appears to be a real migration rather
than a version bump.