{"version":"2.1.248","anchor":"permission-approvals-are-matched-to-the-tool-call-they-answe","canonical_anchor":"permission-approvals-are-matched-to-the-tool-call-they-answe","heading":"Permission approvals are matched to the tool call they answer","tier":"notice","area":"Permissions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248\/e\/permission-approvals-are-matched-to-the-tool-call-they-answe","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248","markdown":"### Permission approvals are matched to the tool call they answer\n\nApprovals are now tied to the exact tool call they answer, so a late one can't hit the wrong call.\n\n**What**\n\nApprove and deny responses now carry the id of the tool call they belong to, and the code that collects them refuses any response aimed at a different call, logging \"answered for a different tool use\". This closes a window where a late or misrouted approval could be applied to the wrong tool call. Always on, with no flag or setting to turn it off.\n\n**Details**\n\n- `tool_use_id` is added to both the error and success shapes of the permission response message, sitting alongside the existing `request_id`, `subtype`, `updated_input` and `permission_updates` fields.\n- Both the approved and rejected branches of mailbox permission handling, the path that carries permission decisions between sessions, forward the tool use id.\n- The poller that waits for a queued response compares ids and rejects mismatches rather than accepting the first answer that arrives.\n- A response that cannot be routed because the owning team is unknown fails with `[PermissionSync] Cannot send permission response: team name not found`.\n\n**Evidence**\n\n`[PermissionSync] Cannot send permission response: team name not found`, `processMailboxPermissionResponse`, `answered for a different tool use`\n\n- Area: Permissions\n- Tier: You'll notice\n- Useful: 4\/5\n- Signal: 3\/5"}