[FEATURE] Setting to hold queued messages until the turn completes instead of folding them mid-turn

Status Open

Reported on v2.1.234

Maintainer reply None cached

Activity 4 comments · opened Aug 18, 2026

Feature request

Add a setting that makes a message typed while Claude is working wait until the current turn finishes, instead of being injected into the running turn.

Current behavior

Two separate paths deliver typed input into a turn that is already in progress, and neither is configurable:

Mid-turn fold. At each tool-result boundary the main loop pulls every queued command with priority <= next and injects it into the running turn as a queued_command attachment. Typed input always enqueues at next, so it is always folded. The only suppressor is isMidTurnFoldSuspended(), which is set solely by end_session.
Interrupt on submit. When every currently executing tool reports interruptBehavior() === "cancel", the engine emits interruptible_tool_in_progress: true, and a fresh submit aborts the running turn outright (interrupt_on_submit) rather than queuing.

Checked against 2.1.234 on darwin-arm64: there is no settings key and no CLAUDE_CODE_* environment variable that controls either path.

Desired behavior

A setting, with the current behavior as the default, that holds human-typed input below the next priority (or otherwise excludes it from the mid-turn fold) and suppresses interrupt-on-submit, so the message lands only once the turn completes.

Why this matters

Mid-turn injection changes what the model is doing halfway through work I already asked for. When the follow-up is a next task rather than a correction, folding it in mixes the two: the model re-plans against a goal that arrived after it started, and the original turn never reaches a clean finish. Steering is the right default for corrections. It is the wrong default for stacking work. Ctrl-C already covers the case where I do want to stop it now.

The workaround today is to leave the text sitting in the input box and not press Enter, which means staying at the session instead of queueing work and stepping away.

Suggested shape

{ "queuedMessages": { "delivery": "steer" } }

with "turn-end" as the opt-in alternative.

Related issues

#65452 — the same request, closed by the stale bot with "open a new issue if this is still relevant".
#73661 (open) — sequential vs merged delivery of queued messages. Complementary: it assumes queueing already defers to turn end.
#50246, #36817 — closed, covering queue-vs-interrupt in earlier versions.

Environment

Version: 2.1.234 (Claude Code)
Platform: darwin-arm64, macOS 25.5.0
Install: npm global, native binary

View original on GitHub ↗

3 Comments

chinigo · 1 month ago

Confirming this on the Claude desktop app's Code tab, not just the TUI — worth adding area:desktop to the existing area:tui / area:core labels. The TUI-only labeling may be why this is sitting at zero comments, since the desktop symptom is the more severe one.

Desktop app 1.49585.0, bundled CLI 2.1.236, darwin-arm64.

Symptom: path 2 in the original report (interrupt_on_submit) makes Send and Interrupt behaviorally indistinguishable in the Code tab. With cancellable tools in flight, pressing Enter on a typed message aborts the running turn rather than queuing it.

Repro:

In the Code tab, start a task that runs several tool calls.
While it is working, type a follow-up and press Enter.
The turn aborts immediately. The message lands as a normal user turn; nothing queues.

This contradicts the app's own release notes, which still say:

Changed the composer to keep the standard Send button while a response is running: it appears when you type, and sending mid-response queues your message instead of showing a separate Queue button.

Mid-response send does not queue in the Code tab. It aborts.

Composer state. The separate Queue button and the queued-message widget are both gone. The send split-button now offers only "Send" and "Send in a forked session".

Having reproduced the behavior functionally, I went looking in the shipped renderer bundle, and the queue machinery does still appear to be present: submitQueued, releaseQueuedSubmit and onSubmitHeld exist as composer props, next to a gate named enableMidTurnSteer (alongside enableForkSubmit / forkSubmitPref). These are minified identifiers read out of V8 code cache, so treat that part as inference — the reproduction above is not.

Confirming the report's negative finding on 1.49585.0 / 2.1.236: no settings key, no CLAUDE_CODE_* env var, and nothing in config.json, Local Storage, Session Storage, IndexedDB or the flag caches controls either path.

On the ask: #64624 originally proposed steering as a separate chord, keeping the queue as the default. What shipped made steering the default for plain Enter and dropped the queue affordance, so neither behavior is now selectable. The setting described here would restore the choice; so would exposing queue-until-turn-end as a distinct submit action.

Also relevant: #71726 documented the desktop Code window holding messages until the turn fully completed as recently as June. For this surface it is a behavior change, not a missing feature.

codecShivam · 1 month ago

i wanted exactly this and ended up building it outside claude code: a small pane next to it where typed messages wait for the turn to fully end, delivered one per turn, in order. it uses the Stop hook (returns the next message as additionalContext) plus SessionStart/End and UserPromptSubmit, so nothing is patched
https://github.com/codecShivam/claudeq

still think this belongs in claude code itself, sharing in case it unblocks anyone until then.

Classic298 · 18 days ago

+1. The case that hurts most: "Send now" on a queued message in Remote Control interrupts and kills all running background agents, while leaving it queued can lag several tool calls. Opened #97705 for "Send now" to deliver right away without killing background work.

Showing cached comments. Read the full discussion on GitHub ↗