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

Claude Code v2.1.242 ·

Interrupt behaviour for held sends is now written down

The control protocol now spells out that interrupts keep held messages queued unless you cancel them.

Under the hood Improvements
JSON All of v2.1.242
Under the hoodTier: how much it should matter to you
2Useful: my rating, 1 to 5
2Signal: worth watching, 1 to 5
ElsewhereArea: what it touches
ImprovementsKind: in v2.1.242,
ImprovementsSection of the release
What

The control-protocol schema now explains what happens to a message a client is still holding back: a plain interrupt leaves it held and lists it under still_queued, while cancelling queued messages withdraws it and reports it under cancelled.

Details
  • The same message can also be withdrawn on its own with cancel_async_message.
  • Today the only such hold is a message waiting for the session to take the initial upload from that machine.
  • A hosted-session driver follows a cancellation with a command_lifecycle frame marked cancelled when its own sweep cancels a send it had already delivered.
  • The behaviour is advertised to clients through the interrupt_cancel_queued_v1 capability.
Evidence

behind a send gate (today: waiting for the session to take the initial upload from that machine)

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.242 →

Feedback