{"version":"2.1.280","anchor":"new-remote-control-message-kind-remote-tools-reannounce","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 Control","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280\/e\/new-remote-control-message-kind-remote-tools-reannounce","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 triggers a reannouncement or how it affects the client side beyond the protocol addition itself.\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 Control\n- Names: `remote_tools_reannounce`\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}