{"version":"2.1.251","anchor":"teammate-permission-approvals-are-now-bound-to-the-exact-too","canonical_anchor":"teammate-permission-approvals-are-now-bound-to-the-exact-too","heading":"Teammate permission approvals are now bound to the exact tool call they answer","tier":"notice","area":"Teammates","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.251\/e\/teammate-permission-approvals-are-now-bound-to-the-exact-too","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.251","markdown":"### Teammate permission approvals are now bound to the exact tool call they answer\n\nA leader's approval is now bound to the exact tool call it answered, not another one.\n\n**What**\n\nWhen a leader approves or denies a tool call on a teammate's behalf, the request now carries the tool name and a digest of the tool input, and the reply is classified as bound, unbound, a tool mismatch, or an input mismatch before it is applied. This stops an approval landing on a different tool call than the one it was given for.\n\n**Details**\n\n- A mismatch in the resume\/reply teammate flow is handled by asking again rather than acting on the stale verdict.\n- That same call site leaves the unbound case an empty function, while a second call site in tool execution sets a flag instead, so the two callers of the same poller behave differently on unbound replies.\n- What reaches the empty handler is not settled by the code itself.\n\n**Evidence**\n\n`onUnboundVerdict() {}`\n\n- Area: Teammates\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 4\/5"}