{"version":"2.1.283","anchor":"device-bridge-dispatch-can-now-hold-back-tools-judged-by-di","canonical_anchor":"device-bridge-dispatch-can-now-hold-back-tools-judged-by-di","heading":"Unused groundwork for checking remote tool requests before any tool runs","tier":"soon","area":"Remote Tools","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.283\/e\/device-bridge-dispatch-can-now-hold-back-tools-judged-by-di","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.283","markdown":"### Unused groundwork for checking remote tool requests before any tool runs\n\nTool requests from a bridged device can now be refused before the tool runs, but no tool uses this yet\n\n**Unclear.** It is not clear whether any tool opts in in a less direct way, or whether the refusal depends on the bridge's enforcement setting.\n\n**What**\n\nClaude Code can receive requests from another device over a bridge to run tools on this machine. A tool is an action Claude can take, such as running a command. Each tool says where the sender of a request is checked. Until now, that was always inside the tool itself.\n\nA tool can now ask for the check to happen before it runs. Claude Code then checks the sender and refuses the request if the check holds it back. No tool asks for this yet, so nothing changes in practice.\n\n**Why**\n\nThis moves a security check to one central place, instead of each tool doing its own.\n\n- Flag `tengu_bridge_attestation_enforce`: Off by default, switched on for this account (read for one account on one subscription tier against v2.1.283; this account: on, anonymous baseline: on, compiled default: off) These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.\n- Area: Remote Tools\n- Tier: Nothing to try yet\n- Useful: 2\/5\n- Signal: 4\/5\n- Present in the build but not switched on"}