Sweep 19 Sep 2026 · 02:36Z Build v2.1.278 500 read Stable v2.1.267 Latest v2.1.278 Next v2.1.278 Feeds RSS JSON llms.txt Unofficial
Claude Code v2.1.267 ·

MCP tools can now be 'adopted' as passthrough tools instead of routed through the device bridge

Remote worker sessions can now adopt a machine's MCP tools directly under policy, tracked via new passthrough_adopted/declined telemetry

TierNothing to try yethow much it should matter to you
Useful3my rating, 1 to 5
Signal3worth watching, 1 to 5
AreaMCPwhat it touches
KindIn Developmentin v2.1.267,
Group of 3 Nothing to try yet No documentation found

Remote worker sessions can now adopt a machine's MCP tools directly under policy, tracked via new passthrough_adopted/declined telemetry

What

  • A reworked remote-tools setup pipeline, gated by adoptMcpOverChannelSwitchOn, computes a machineMcpToolsPolicy (allowed/denied/pending/unavailable) for each MCP server and decides whether its tools are "adopted" as passthrough tools, used directly by a remote worker, instead of being routed through the device bridge. Adoption requires remote tool forwarding to be enabled, the channel switch to be on, policy to allow it, and the tool not to be disabled.
  • The remote-tools announce handler now computes passthrough_adopted and passthrough_declined (with reasons policy, pending, or unavailable) outcomes and reports them in telemetry.
  • The remote_tools_announce acknowledgement schema was extended with passthrough_adopted (count of MCP tools kept) and passthrough_declined fields, and ignored_tools now documents more reasons, including tools beyond the cap that the worker keeps.

Why Routing every MCP tool call through the device bridge adds overhead; letting a remote worker adopt and call MCP tools directly, when policy allows, should make those calls faster while keeping visibility into which tools were adopted versus declined and why.

Read from
Names in the bundleadoptMcpOverChannelSwitchOn

See this entry in the whole of v2.1.267 →