Follow Discord
Sweep 22 Oct 2026 · 04:32Z Build v2.1.308 527 read Stable v2.1.308 Latest v2.1.308 Next v2.1.308 Feeds RSS JSON llms.txt llms-full.txt Unofficial
HomeReleasesv2.1.248entry #88

Claude Code v2.1.248 ·

Permission approvals are matched to the tool call they answer

Approvals are now tied to the exact tool call they answer, so a late one can't hit the wrong call.

You'll notice New Features
JSON All of v2.1.248
You'll noticeTier: how much it should matter to you
4Useful: my rating, 1 to 5
3Signal: worth watching, 1 to 5
PermissionsArea: what it touches
New FeaturesKind: in v2.1.248,
What probably matters to youSection of the release
What

Approve 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.

Details
  • 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.
  • Both the approved and rejected branches of mailbox permission handling, the path that carries permission decisions between sessions, forward the tool use id.
  • The poller that waits for a queued response compares ids and rejects mismatches rather than accepting the first answer that arrives.
  • A response that cannot be routed because the owning team is unknown fails with [PermissionSync] Cannot send permission response: team name not found.
Evidence

[PermissionSync] Cannot send permission response: team name not found, processMailboxPermissionResponse, answered for a different tool use

Strings lifted out of the shipped bundle, so the claim above can be checked against them.

See this entry in the whole of v2.1.248 →

Feedback