A leader's approval is now bound to the exact tool call it answered, not another one.
What's wrong with this entry?
When 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.
- A mismatch in the resume/reply teammate flow is handled by asking again rather than acting on the stale verdict.
- 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.
- What reaches the empty handler is not settled by the code itself.
onUnboundVerdict() {}
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.223
Undelivered attachments are reported as a tool error
Both mention teammate
-
v2.1.227
Teammate pane creation serialised under tmux and iTerm2
Both mention teammate