Skip to content

Answer a declined discover probe ahead of rmcp - #38

Merged
jserv merged 1 commit into
mainfrom
discover-probe
Oct 4, 2026
Merged

jserv merged 1 commit into
mainfrom
discover-probe

Conversation

@jserv

@jserv jserv commented Oct 4, 2026 •

Copy link
Copy Markdown
Contributor

Claude Code 2.1.285 now opens a stdio session with server/discover at 2026-07-28, and when the server declines that revision (this one always does, see EXCLUDED_PROTOCOL_VERSIONS) it falls back to initialize on the same session. rmcp marks the session as requiring per-request _meta as soon as the first message is not initialize, before the probe is rejected, and never clears it. The fallback handshake succeeds, then tools/list is refused with -32602 request _meta is missing or has malformed required fields, so /mcp shows the server connected with no tools. rmcp 3.5.0 has the same behavior.

This adds a small transport wrapper in src/main.rs. Until initialize arrives, it answers a discover for a declined revision itself, with the same -32022 unsupported-version error rmcp sends, so rmcp sees initialize first. A discover that names a revision this server supports still goes to rmcp. The 2026-07-28 exclusion is unchanged.

Verification: I captured Claude Code's actual exchange through a logging wrapper and replayed it against the new binary, and tools/list now answers. The new test a_declined_discover_probe_falls_back_to_initialize (test-process-lifecycle) replays the probe, the fallback and tools/list. As a negative control, starting the wrapper as already initialized (so the probe reaches rmcp) makes that test fail with the reported error. scripts/run-gates.sh passed all 18 gates on macOS with Frama-C 33.0 (unit 651, lifecycle 40, stdio 157).

The underlying problem is in rmcp, and the wrapper can go once rmcp stops setting the flag for a probe it rejects.


Summary by cubic

Fixes a Claude Code compatibility issue where a server/discover probe caused the fallback initialize session to show no tools. Declined probes are now answered before rmcp sees them, so the fallback handshake remains usable and tools/list succeeds.

  • Probes for supported revisions still pass through to rmcp; the 2026-07-28 exclusion is unchanged.
  • Failed probe replies are logged before the session ends.
  • Adds a lifecycle regression test covering the probe, fallback handshake, tools/list, and negotiated protocol state.

Written for commit d37c0a6. Summary will update on new commits.

Review in cubic

cubic-dev-ai[bot]

This comment was marked as resolved.

Claude Code now opens a stdio session with server/discover at
2026-07-28 and falls back to initialize on the same session when the
server declines that revision, which this one always does. rmcp marks a
session as needing per-request _meta the moment its first message is
not initialize, before the handler rejects the probe, and never clears
the mark. The fallback handshake succeeded and then tools/list was
refused for missing _meta, so "/mcp" showed the server connected with
no tools. rmcp 3.5.0 behaves the same.

A thin transport wrapper answers a discover for a declined revision
with the same unsupported-version error rmcp sends, until initialize
passes through, so rmcp sees initialize first and keeps the session on
the lifecycle it negotiated. A discover naming a revision this server
speaks still goes to rmcp. A failed write of that reply is logged
before the session ends. The 2026-07-28 exclusion is unchanged.

The new lifecycle test replays the probe, the fallback and tools/list.
Starting the wrapper as already initialized, which hands the probe to
rmcp, fails it with the reported error.
@jserv jserv changed the title Answer a declined discover probe before rmcp sees it Answer a declined discover probe ahead of rmcp Oct 4, 2026
@jserv
jserv merged commit 17f55cd into main Oct 4, 2026
9 checks passed
@jserv
jserv deleted the discover-probe branch October 4, 2026 02:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant