{"version":"2.1.283","anchor":"remote-control-bridge-can-host-tools-for-work-items-with-mod","canonical_anchor":"remote-control-bridge-can-host-tools-for-work-items-with-mod","heading":"Remote Control can offer this folder's tools to cloud sessions, behind tengu_radiant_heron","tier":"notice","area":"Remote Control","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.283\/e\/remote-control-bridge-can-host-tools-for-work-items-with-mod","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.283","markdown":"### Remote Control can offer this folder's tools to cloud sessions, behind tengu_radiant_heron\n\nA Remote Control daemon can now advertise its local folder and tools to cloud sessions, gated by tengu_radiant_heron and a chain of checks\n\n**Unclear.** It is not clear whether this is switched on, as a remote switch can turn it off.\n\n**What**\n\nRemote Control lets a session running elsewhere reach this machine. The daemon, the background process that runs Remote Control, now builds a \"tool host\": a way for cloud sessions to use this local folder and its tools. Before, the plumbing existed but the switch that decided this always returned off, so nothing was offered.\n\n- Work items with mode `tool_use` now go to a tool-host handler instead of being stopped as an unsupported mode.\n\n- When the verdict is to advertise, the Remote Control registration tells cloud sessions they may use this folder. Each change is logged as \"cloud sessions may use this folder:\", and the registration is renewed whenever the advert changes. The number of sessions being served is reported as `rc_serving_tools`.\n\n- The checks run in order. The server flag `tengu_radiant_heron` must be on, or the host withdraws with blocker `gate_off`. A local device flag must be on, or the blocker is `flag_off`. The platform must be macOS or Linux. No policy may turn it off, including the `disableRemoteControl` setting. You must be signed in through a stored claude.ai login that has a refresh token. The folder must be the root of a git checkout, meaning it contains a `.git` entry.\n\n- If the flags have not loaded, the verdict stays `unknown` for up to 120 seconds and then withdraws with `flags_unloaded`. If the flag is switched off remotely during a run, sessions being served are ended with reason `gate_off`.\n\n- A request that is still waiting when the host withdraws, for example with `host_unbound` or `host_stopped`, is now answered with a refusal carrying `code: \"withdrawn\"`, a reason and a message. Withdrawals with blocker `gate_off`, `flag_off` or `muted` are handled separately.\n\n- The flag's state can now be reported as true, false or \"unknown\", depending on where its value came from.\n\n`tengu_radiant_heron` defaults to false. The flag server returned it off for this site's account and for an anonymous check; no reading has been taken under this release yet.\n\n**Why**\n\nOnce the flag is on, a cloud session could run tools in a git checkout on your machine, and a caller whose request disappears is told why. The checks limit this to signed-in macOS and Linux machines where policy allows Remote Control.\n\n- Area: Remote Control\n- Tier: You'll notice\n- Useful: 5\/5\n- Signal: 5\/5"}