Follow Discord
Sweep 10 Nov 2026 · 02:18Z Build v2.1.322 539 read Stable v2.1.311 Latest v2.1.322 Next v2.1.322 Feeds RSS JSON llms.txt llms-full.txt Unofficial

Claude Code v2.1.265 ·

Unsent messages to remote sessions can now be taken back

Escape (or an empty-prompt cancel) now reclaims messages queued for a remote session that haven't been sent yet

Group of 5 You'll notice No documentation found Internal Changes
JSON All of v2.1.265
You'll noticeTier: how much it should matter to you
3Useful: my rating, 1 to 5
2Signal: worth watching, 1 to 5
SessionsArea: what it touches
Internal ChangesKind: in v2.1.265,
What probably matters to youSection of the release

Unclear The finding does not say what user-visible message or indicator appears when cloudMessageHeld is set, only that the state is threaded through to the message list.

What

  • Remote/cloud sessions now track when a queued message is "held" (queued but not yet sent to the cloud session) and could still be withdrawn. RemoteSessionManager calls a new tellWithholdableHeld() method on release, gate resolution, withdrawal, and settlement, and fires an onWithholdableHeldChanged callback when that status changes; the UI tracks this as a cloudMessageHeld state.
  • Users can now press Escape while idle to reclaim messages that were queued but not yet sent, via a new cancelHeldMessages capability, instead of triggering a full interrupt. This shows a notice and logs telemetry.
  • Cancelling with an empty prompt while in remote mode now also cancels held remote messages, via the same cancelHeldMessages path.
  • Taking back the very first prompt (the one given on the command line, which starts out withheld) now shows a distinct notice: "You took back your first message (the one given on the command line) — it wasn't sent to the cloud session."

Why

Previously a message queued for a remote/cloud session but not yet sent couldn't easily be pulled back. Now pressing Escape, or cancelling with an empty prompt, retracts it before it reaches the cloud session, with clear feedback about what happened.

Read from
Names in the bundlecloudMessageHeld
How sure we are
Something disagreesSomething we can check disagrees with this entry, or the writer said they could not settle it.
The writer flagged doubtThe finding does not say what user-visible message or indicator appears when `cloudMessageHeld` is set, only that the state is threaded…

See this entry in the whole of v2.1.265 →

Feedback