Tool calls and Bash can be routed to another machine over a device bridge.
A versioned remote tool-routing client with permission forwarding and call reconciliation is newly present in the bundle.
What's wrong with this entry?
A new client-side layer can route a tool call, Bash or an attached machine's own MCP tools, to a different machine reached through the device bridge. It negotiates a protocol version, forwards permission prompts back into your session, and reconciles calls that dropped or timed out by asking the host what happened. None of it exists in the previous build.
- Reconciliation outcomes are reported as replayed, still running, host restarted, or not received.
- Permission asks forwarded back include automatic-mode classifier verdicts.
- New telemetry events:
tengu_remote_tool_forward,tengu_remote_tool_targets,tengu_remote_tool_classifierandtengu_remote_tool_serve_hook_held. - Users would see text listing attached machines, plus errors for an unreachable host or a protocol mismatch.
- Every entry point is behind the same boolean check: the attached-machines notice is only shown when it passes, the runtime is only loaded when it passes, and each routed call re-checks it and fails with the code
gate_off. The name of that check and what it defaults to are not resolvable from the build.
The attached machine could not be reached through the device bridge right now; the call did not run. Try again shortly.
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.247
Session-channel messages from senders this session cannot verify are refused, dropped or trimmed
Both mention tool
-
v2.1.247
Plumbing calls and passthrough MCP tools: described in the protocol, not yet served
Both mention tool
-
v2.1.247
Clearer explanations when a call to an attached machine fails
Both mention tool