{"version":"2.1.281","anchor":"forwarded-call-dispatch-schema-accepts-request-id-and-instan","canonical_anchor":"in-flight-served-call-metadata-is-coalesced-and-carries-requ","heading":"Forwarded tool calls now carry request_id and instance_id","tier":"internal","area":"Remote Tools","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281\/e\/forwarded-call-dispatch-schema-accepts-request-id-and-instan","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281","markdown":"### Forwarded tool calls now carry request_id and instance_id\n\nRecords of tool calls forwarded to another host now include request_id and instance_id, and in-flight updates are batched\n\n**Unclear.** The finding does not say what the two new fields are used for once they are recorded.\n\n**What**\n\nWhen a tool call is forwarded to another host and served there, Claude Code keeps records of it. Those records now carry two extra identifiers.\n\n- The dispatch record (previously `tool_use_id`, `tool`, `host`, `host_epoch` and `dispatched_at`) accepts optional `request_id` and `instance_id` fields. Each is checked against a pattern, and a malformed value is dropped instead of rejecting the whole record.\n\n- The `in_flight_served_calls` record now includes `request_id` and `instance_id` and is refreshed when either changes. Before, it was keyed only by `host_epoch`.\n\n- Updates to that in-flight record are batched into one notification per short processing step, instead of one for every call added.\n\n- The directory-sync note written after a remote call is simpler: the `deferWrite` and `exclusive` options and the 'taken_in' routine flag are gone.\n\n**Why**\n\nThis is internal plumbing for remote execution. It lets forwarded calls be matched up more reliably and cuts down on repeated update messages.\n\n- Area: Remote Tools\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 2\/5"}