Follow Discord
Sweep 22 Oct 2026 · 04:32Z Build v2.1.308 527 read Stable v2.1.308 Latest v2.1.308 Next v2.1.308 Feeds RSS JSON llms.txt llms-full.txt Unofficial

Claude Code v2.1.239 ·

MCP servers supplied by a remote bridge: wired up, entirely stubbed

A remote bridge could hand your session MCP servers during handshake, but it is entirely stubbed.

Nothing to try yet In Development
JSON All of v2.1.239
Nothing to try yetTier: how much it should matter to you
1Useful: my rating, 1 to 5
4Signal: worth watching, 1 to 5
MCPArea: what it touches
In DevelopmentKind: in v2.1.239,
What probably matters to youSection of the release

Bridge-supplied MCP server install and hot-swap code exists but every part of it is inert.

What

Code exists for a remote bridge session to install MCP servers handed over by the server during its opening handshake, and to swap them later over the control channel. Every part of it is inert in this build, so no bridge session gains servers this way.

Details
  • The enabling check is a local return !1; the module holding the function that derives the servers from the handshake payload is declared as null; the apply step returns an empty added/removed pair; the release and refresh hooks have empty bodies.
  • The bridge passes no handler for setting servers, so an mcp_set_servers control request over the bridge is answered with an explicit unsupported error.
  • Telemetry slots for the failure modes ("handshake_threw", "payload_rejected", "relinquish_threw", "refresh_threw") are already present under a single event name.
  • There is no flag or setting that turns any of this on; it is disabled at build time.
Evidence

mcp_set_servers is not supported in this context (onMcpSetServers callback not registered)

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

See this entry in the whole of v2.1.239 →

Feedback