Feature Request: Message queue mode — queue messages instead of interrupting active tasks

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/48268
2. https://github.com/anthropics/claude-code/issues/30677

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

I'm confused.... If you enter prompts while it is busy they get queued and executed in turn when the Claude agent finishes its current task. You have to press ESC to interrupt it. What is it that you want it to do differently?

I'd love to queue a message that only gets passed on Stop

Echoing @dsfaccini — "queue until Stop" is exactly the missing piece. I prototyped a working pattern using a Stop hook that approximates this today, sharing in case it helps shape a built-in solution.

Pattern: Stop hook + queue file

Claude Code's Stop hook fires only when the main agent finishes its turn (not at intermediate tool pauses or subagent returns), making it the right gate for "actually idle."

1. User appends queued messages to a file (e.g. ~/.claude/queue.txt)
   from a side channel — NOT the main input box (which still uses
   the built-in mid-turn queue).

2. On Stop, hook script:
   - reads ~/.claude/queue.txt
   - if empty → exit 0 (allow stop)
   - if non-empty → emit JSON:
       {"decision": "block", "reason": "<queued contents>"}
     and clear the file
   - Claude resumes, treating `reason` as the next instruction.

{"decision": "block", "reason": "..."} from a Stop hook tells Claude Code "don't stop, here's more input."

What works

• Queued messages can never arrive mid-tool-call.
• Multiple queued lines naturally batch into one delivery.
• No core changes required.

What's still rough (and why a built-in would be better)

1. Input side channel. Users can't use the normal input box — that still goes through the built-in mid-turn queue. They need a separate mechanism (a cq "msg" CLI alias, a tmux pane appending to the file, etc.). Hard to discover.
2. No idle flush. If Claude is already idle when you queue, the file sits until next Stop. A manual nudge triggers it, but feels unintuitive.
3. Cosmetic mismatch. Queued text arrives as a Stop hook reason, not a true user turn — shows up differently in the transcript.
4. Per-user setup. Every user has to wire it up themselves. Not portable.

Suggested built-in shape

• A queue toggle in the input box (Shift+Enter, or dedicated key) that routes to a true-end-of-turn queue instead of the current mid-pause queue.
• Visible queue indicator (already in OP).
• Optional --queue-mode=defer CLI flag / settings.json key.

The Stop-hook pattern proves the mechanism works — promoting it to a first-class feature would close the UX gaps that make the workaround painful. Happy to share the prototype scripts if useful.

Can we please implement a queue instead of "steer" similar to Codex? Sometimes you do not want to interrupt a long running thing to steer it and want it to take that message in on stop.

Codex CLI you just press tab instead of enter to do that and it's super nice.

Can we please implement a queue instead of "steer" similar to Codex? Sometimes you do not want to interrupt a long running thing to steer it and want it to take that message in on stop. Codex CLI you just press tab instead of enter to do that and it's super nice.

UPVOTE

This can be such a game changer for people with >5+ tabs! imagine the usage $$$!

We need this feature!

+1

Can't believe this is not a feature yet. Other CLI agent harnesses use "tab" or "alt+enter" to queue the next message to be picked up once the agent thinks its done.

I used to do this in terminals (e.g. bash, cmd, powershell) too, you can just paste the next commands and the shell will pick it up, though in those shells what you had typed/pending was not visualized anywhere, but that strategy worked.

UPVOTE! I NEED THIS❤!

Adding a concrete reference implementation for this: Codex CLI ships exactly this behavior via a dedicated Tab keybinding, and it's lovely to use.

While the agent is working, you type a follow-up and press Tab (instead of Enter). The message is added to a queue and is explicitly deferred — it does not run in the current turn and does not interrupt; it's appended and picked up only after the current turn completes. Enter still means "send/interrupt now," so the two intents are cleanly separated by key.

Why the explicit key matters, vs. Claude Code's current implicit "type-while-it-works" queuing:

• It's a deliberate "this is for later, not now" gesture, so there's zero ambiguity about whether the message interrupts or gets addressed this turn (cf. the ambiguity raised in #57263 and #54031).
• It keeps you in flow on long-running tasks — capture the thought, Tab it, keep watching, without breaking the active run.
• It pairs naturally with the editable / ordered-queue asks in #62877 and #54031.

Concrete request: a dedicated keybinding (Tab, matching Codex) that queues the current input as a deferred follow-up delivered after the active turn finishes, with a small queue indicator near the input. Enter = send/interrupt now; Tab = queue for after.

+1. I hit this constantly when using Claude Code to manage ML training jobs on Kubernetes.

My workflow: submit PyTorch jobs, monitor logs, check metrics, verify outputs — tasks that involve long waits (sleep, kubectl logs -f, etc.). While Claude is busy waiting, I think of follow-up questions or want to check something else, but my only options are interrupt (lose the running task) or open a separate terminal (lose shared context).

A simple queue (type while busy, Claude picks it up when done) would make a huge difference for async-heavy workflows. Shift+Enter for queue vs Enter for interrupt feels right.

Cline has a PR in flight doing something similar

Related: #62877, #63190

Please implement this, quick

+1

+1

+1 pretty please with apple sauce on top. There are jobs I send to Codex instead of Claude Code over this one silly feature. Would be great if you could adopt the same standard and have tab be the queue signal so I don't have to learn different keystrokes for different CLIs.

This is the cleanest statement of the problem in the tracker — "interrupt and derail, or try to
remember it." +1 on native message-queue mode.

For the capture half specifically — not losing the follow-up and not derailing the current run —
that part is buildable as a plugin today, and I built one. Disclosure: mine, open source, called valet.

/valet:park <text> runs through a UserPromptExpansion hook that returns decision: block, so the
text never expands into a prompt and never reaches the model on the current turn: zero tokens, current
task untouched. It appends to a project-local queue. /unpark later opens a native picker to pull one
back as the next turn.

Where it deliberately differs from this request: pickup is manual, it never auto-fires. So it covers
"don't interrupt, don't lose it, don't burn context," not "auto-run my queue when the turn ends" — that
half still needs native support, hence the +1. Sharing as a working reference for the zero-token capture
mechanism: https://github.com/YeautyYE/claude-valet

+1 — and a Remote Control / mobile variant of this that makes the missing-queue gap worse: it actively loses input.

On mobile Remote Control (claude.ai → CLI session), when the agent is busy I type a follow-up, but there is no queue, so the message just sits in the compose box as an un-sent draft. If I then switch to a different chat/session while waiting, that drafted message is silently discarded — it's gone when I come back, and it was never delivered to the agent.

So on mobile this isn't only a "queue would be nice" ergonomics request — without queueing, the input I composed during a busy turn is data-lost on navigation. A real queue (deliver-when-turn-ends) as proposed here would fix the loss directly. Short of that, at minimum the unsent draft should persist per-session across chat switches instead of being thrown away.

plus one pretty please

@bcherny I am dreaming about this at this point, even trying hackish workarounds.

+1, please please please

+1. This is one of the top codex features that claude is missing (steer vs queue)

+1. I have been using Codex for quite a while now and am painfully missing this feature from the Claude extension.

+1 claude code. urgently please. Makes multi-threaded work almost impossible without that queueing feature.

Adding the mobile angle here, since the related bugs (#32457, #20431, #36326) are all closed + locked as "resolved" but the behavior is still present on Android.

On the Claude Code Android app, while the agent is actively working there is no way to send a message at all: anything I type shows as "Queued" and the send control acts as Stop/Interrupt, so the only way to deliver my message is to interrupt/stop the agent's current turn. On top of that, if I switch projects while a message is in the "Queued" state, the queued text is silently dropped — no delivery, no preserved draft, no warning.

So this isn't just a nice-to-have queue mode for me — on mobile it's the difference between being able to steer a running task or not. What I'd want:

1. A real Send/interject action while the agent is working (distinct from Stop), delivering at end-of-turn.
2. Queued/draft messages that survive a project switch instead of being lost.

Since #32457/#20431 are marked resolved-and-locked, flagging that it's still reproducing on the latest Android build.

Possible today with AgentBuddy.

claude has wasted so much of mine and its time by not steering in the claude desktop. its going down some path and i'm like no you're wrong, and i have to cancel what its doing. that risks stopping it in the middle of work and leaving files in a bad state.

Note: you can patch it together yourself via stop hook. ask your claude code instance :)

(example case: https://github.com/fkarg/configs/commit/03cee90555eb067741efd405de10f16e1e510990 - note that I need to write/copy the message from a second terminal, but that's a small price to pay)

+1

plus one pretty please

plus + 1

https://github.com/anthropics/claude-code/issues/68998

This would be brilliant... +2

++

+1 for this. A related need: when messages pile up in the queue while Claude is working, there's currently no way to force the queued messages to run on demand — they only flush when you send another message (and Esc interrupts the running task instead). A dedicated way to flush/execute the queue immediately (a keybinding or /flush-style command) would be very helpful. See also #66310 (queued messages don't fire on their own).

+1

Adding a related data point: the Claude Code VS Code extension already handles this well — you can send a message while Claude is mid-task (thinking or executing) and it gets picked up and incorporated before the next step, without needing to interrupt.
In the Desktop app's Code tab, the equivalent doesn't happen. A message sent while a task is running just sits until the entire current task finishes, instead of getting incorporated at the next natural break. So today the only options mid-task are: wait out the whole thing, or hit Stop and interrupt/lose progress.
Since the VS Code extension already does this correctly, it'd be great if the Desktop app's Code tab could match that behavior — quick steering without derailing the task.

+1

++