{"version":"2.1.280","anchor":"new-worker-to-client-control-request-for-remote-tool-re-anno","canonical_anchor":"new-worker-to-client-control-request-for-remote-tool-re-anno","heading":"New remote_tools_reannounce message lets a worker ask a client to re-announce its tools","tier":"internal","area":"Remote Tools","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280\/e\/new-worker-to-client-control-request-for-remote-tool-re-anno","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280","markdown":"### New remote_tools_reannounce message lets a worker ask a client to re-announce its tools\n\nRemote sessions can now ask an attached client to re-announce which tools it offers\n\n**Unclear.** The finding does not say what user-visible problem this fixes or when a worker gets replaced.\n\n**What**\n\nA new control message kind, `remote_tools_reannounce`, was added to the remote-session protocol. When a replacement remote-tool worker gets a tool call naming a machine it doesn't recognize, it can send this request, identified by a worker epoch and a deadline, to ask the attached client (the one serving the session's tools) to re-announce itself. The client side handles this with rate limiting and epoch checks, and the message kind is included in the reject-list for otherwise-unhandled message kinds.\n\n**Why**\n\nThis keeps a remote session's list of available tools and machines in sync even after a worker is replaced, avoiding stale or unrecognized machine references.\n\n- Area: Remote Tools\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}