Claude Code can now stop a running turn on its own when a follow-up arrives before any output appeared, if the connected client opts in
What
- A new
system/turn_preemptedevent (reasonrapid_followup) is sent when Claude Code itself stops a running turn because the person sent a follow-up message before the turn produced any output; any running shell commands are backgrounded rather than killed, and the follow-up is answered right away instead of waiting in queue. - This only happens when the connected client has declared support for it: a new SDK capability,
rapidFollowupPreempt(declared viadeclareRapidFollowupPreempt, read back assdkRapidFollowupPreempt()), mirrors the existingperTaskStopAffordancecapability and tells Claude Code the client knows how to handle aturn_preemptedevent. - It is also gated behind a rollout flag (
tengu_zippy_spindle), off by default, so both the client declaration and the flag must be enabled. Preemption is skipped for slash commands, bridge-originated messages, and similar cases where it wouldn't make sense.
Why Without this, sending a quick follow-up while Claude Code is still working on the previous message just queues it silently. With this enabled (and supported by the client), the follow-up can preempt the still-running turn so it gets addressed immediately.
tengu_zippy_spindle Not enough to sayNothing here resolved what this flag was doing on this version, so nothing here should be read as on or off.
This account: no value returned · anonymous baseline: no value returned · compiled default in v2.1.271: off
These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.
Read once, for one account on one subscription tier, against v2.1.271. It isn't a statement about your account. What a flag value here can and cannot tell you
Nothing has been read yet about whether `tengu_zippy_spindle` is on for any account.
New in this build: tengu_zippy_spindle