v0.9.14: converge on the MCP 2026-07-28 spec — rmcp ClientLifecycleMode negotiation, per-server opt-in, server echoes requested protocolVersion

[Hmbown]

Why this matters

Codewhale was pinned to the original MCP revision (2024-11-05) in three places and the client never read the protocolVersion a server returns. Current servers negotiate 2026-07-28; we could not participate.

Verified state

• Original pin sites: crates/mcp/src/lib.rs:1039, crates/tui/src/mcp_server.rs:317, crates/tui/src/mcp.rs:1834.
• First half landed from a parallel lane (2026-09-16, uncommitted at filing): advertise 2025-06-18, negotiate over MCP_SUPPORTED_PROTOCOL_VERSIONS = [2025-06-18, 2025-03-26, 2024-11-05] — server echoes the client's revision when supported (latest otherwise), stdio client accepts the set instead of exact-match, streamable HTTP sends the required MCP-Protocol-Version header post-initialize. Verified: codewhale-mcp 79/79, codewhale-tui --lib mcp 425/425, fmt clean.
• rmcp 3.2.0 is already a dependency of crates/tui (Cargo.toml:76, features auth, client) — the hand-rolled client in crates/tui/src/mcp.rs coexists with it. The remaining work is convergence, not adoption.
• ~/.codewhale/mcp.json today: 2 servers, both stdio, no HTTP/SSE servers configured. The legacy HTTP+SSE transport (mcp.rs:1510 region) has no local dependents — keep it reachable or gate it explicitly, never silently drop.
• reqwest: workspace on 0.13.1 while Cargo.lock still carries 0.12.28 (see Dependency dedupe: reqwest 0.12/0.13, toml/toml_edit, thiserror 1/2, bitflags 1/2, sha2/digest splits #6151); grokbuild quarantines rmcp in a dedicated crate (refs/grokbuild/crates/codegen/xai-grok-mcp) — mirror that isolation only if the lock graph demands it.

Remaining work (second half)

Per refs/codex/codex-rs/rmcp-client — do not hand-roll negotiation:

1. Copy the model of rmcp-client/src/protocol_mode.rs: McpProtocolMode (Legacy | V20260728) defaulting to Legacy, mapping to rmcp's ClientLifecycleMode; Auto performs the 2026-07-28 probe with 2025-06-18 fallback. Reference tests: rmcp-client/tests/mcp_2026_discovery.rs, mcp_2026_stdio.rs.
2. Default every server to Legacy; modern is opt-in per server; stdio opts in via an env marker exactly as the codex reference does. Keep that property.
3. Replace the hand-rolled client in crates/tui/src/mcp.rs with rmcp, isolated in its own crate. Expect a large deletion.
4. Keep the legacy HTTP+SSE transport reachable (or explicitly gated with a report of what uses it).

Order and gates

Implementation first, prove it runs against a real MCP server, then tests. Land in slices, one commit each. Final gate: npm test && npm run check:web with real pass/fail counts in the commit message; failures reported with output.

Related

• Reconcile the two MCP client stacks (tui/src/mcp vs crates/mcp) #6142 (reconcile the two MCP client stacks — this lands its direction)
• MCP: qualify one negotiated protocol adapter across legacy and current servers #6131 (one negotiated protocol adapter across legacy and current servers)

[Hmbown]

Recon for the second half (2026-07-28 / rmcp), before any code moves

Three facts change the shape of this work, all verified in the current tree.

1. The dependency quarantine is not needed — rmcp is already here

crates/tui/Cargo.toml:76 already declares it:

rmcp = { version = "3.2.0", default-features = false, features = ["auth", "client"] }

The worry from the task description was that rmcp wants reqwest 0.13 while
the workspace sits on 0.12, which is why refs/grokbuild/.../xai-grok-mcp
exists as a quarantine crate. That does not apply:

• workspace: reqwest = { version = "0.13.1", ... } (Cargo.toml:63)
• Cargo.lock: rmcp 3.2.0 → reqwest 0.13.4

Same major line. No quarantine crate. (reqwest 0.12.28 is still in the
lock via other transitive deps — that is #6151, not this.)

Codex pins rmcp = "=3.2.0" (refs/codex/codex-rs/Cargo.toml:430); we are on
a caret 3.2.0 resolving to the same version. Worth pinning exactly here too,
per the original instruction to pick one and pin it.

2. SSE: reported, not dropped

The task said to check mcp.json for anything still needing SSE and report
before dropping it. Result:

Config	Servers	Transport
~/.codewhale/mcp.json	github, aws, playwright, codewhale-cu, chrome-devtools	stdio
	linear, stripe	http (streamable)
builtin computer-use plugin	computer	stdio
account/desktop plugins	codewhale-plugins	streamable-http

No configured server uses SSE. But it is not dead code either — it is a
documented opt-in: crates/tui/src/mcp.rs:554 documents transport: "sse" as
the legacy escape hatch, the selector is at :1528/:1536,
HttpTransportMode::Sse is a live arm in crates/tui/src/mcp/http.rs:28, and
there is a test module mcp::sse::endpoint_tests.

So SSE is a public config surface with zero current users, and rmcp ships
no SSE transport. That is a decision, not a refactor detail:

• (a) keep mcp/sse.rs as a non-rmcp fallback wired to the same selector,
  and route only non-SSE servers through rmcp; or
• (b) deprecate transport: "sse" with a loud config-load error naming the
  replacement — which satisfies "misconfiguration fails loud" rather than
  silently downgrading someone's server to a transport they did not ask for.

Silently dropping it is the one option that is not available: a user with
transport: "sse" in their config must not end up on a different transport
without being told.

3. What the negotiation layer actually costs

refs/codex/codex-rs/rmcp-client/src/protocol_mode.rs is ~50 lines and does
not hand-roll anything: ClientLifecycleMode::Auto { preferred_versions: [V_2026_07_28], legacy_version: Some(V_2025_06_18) } makes the SDK do the
probe and the fallback. Legacy stays the default and stdio servers opt in via
an env marker, which is the property to preserve.

Our first half (landed in #6281, crates/mcp/src/lib.rs) hand-rolls
MCP_SUPPORTED_PROTOCOL_VERSIONS negotiation. That is correct for the server
side, which rmcp does not cover for us. The client side is where the
hand-rolled code should go away.

Suggested slicing

1. Pin rmcp exactly; add McpProtocolMode (Legacy default, V20260728
   opt-in per server via env marker) — small, no behaviour change.
2. Route the streamable-http client through rmcp behind that mode; leave
   stdio alone. Prove against a real server (linear or stripe are live
   streamable-http servers in the current config).
3. Route stdio through rmcp.
4. Decide SSE per §2 above and execute that decision.
5. Server side: crates/mcp + mcp_server.rs extend the supported set to
   include 2026-07-28. The echo-the-requested-revision logic from feat(mcp): negotiate the protocol revision (2025-06-18) + bundle-mode dsh converter #6281 already
   generalises.

Steps 1–3 are where the deletion the task hoped for actually lands: the
hand-rolled client lifecycle in crates/tui/src/mcp.rs.