[FEATURE] The ability to queue up messages.via asking the user for further info on user input.

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/33323
2. https://github.com/anthropics/claude-code/issues/30677
3. https://github.com/anthropics/claude-code/issues/34345

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

1. [FEATURE] Task queue for queuing multiple prompts/tasks #33323

This is not a duplicate. The first feature request does not give a specific mechanism for providing this functionality, wheras this ticket does.

The second two feature requests listed have to do with vscode extensions. I don't see why this feature would need to be limited to vscode - having a simple, disambiguating question here when typing input would be a simple method to make this available everywhere, on all platforms that claude code supports.

Please fix this. You guys have competition enough, I love claude code and many thanks for it, but its hard to defend it when it has blindspots like this that have been around for this long without actually being addressed in the face of quite a bit of end-user demand.

again, I'm tagging @8enmann as the owner of this, and I'm asking for a fix for this.. Please.

in addition @claude, I'd like to get your take on my above comment. looking at the original feature request and comparing it to cursor and codex, what are your takes? do you still think this is a dup or no?

could you comment here please?

strongly +1 on this. wanted to add some cross-reference context and a concrete ux precedent that already ships in production.

codex cli already solved this with two keybindings

openai's codex cli has first-class support for exactly this problem with a simple, explicit ux:

| key | action | what happens |
|-----|--------|-------------|
| enter (while agent is busy) | steer | injects your message into the current turn at the next natural breakpoint — the agent adjusts course without stopping |
| tab (while agent is busy) | queue | appends your message to a fifo buffer — current task finishes uninterrupted, then queued message runs next |
| esc | interrupt | hard stop, aborts current generation |

this is documented at the official codex cli features page. the key insight is that steer and queue are two fundamentally different user intents, and conflating them (which is what claude code currently does) leads to exactly the problems described in this issue — interrupted workflows, lost context, wasted hours.

there's also a great taxonomy in this blog post that breaks it into three modes:

1. post-turn queuing (fifo) — message runs after current task completes (codex: tab)
2. boundary-aware steering — message injected at next tool call / reply boundary (codex: enter)
3. hard interrupt — abort current generation (both tools: esc)

claude code currently has a rough form of boundary-aware queuing (messages get inserted at breakpoints), but the ux around it is ambiguous — as the op describes, it's unclear whether you're replacing the current task or adding to it. codex's explicit enter/tab split eliminates that ambiguity entirely.

this has been requested for a year

for the anthropic team's visibility — this is one of the most persistently requested features across the project's history:

• #535 — original request (mar 2025, closed not planned)
• #1124 — queued messages being dropped/ignored (may 2025)
• #15854 — programmatic queue access via cli flag (dec 2025, closed not planned)
• #25845 — comprehensive prompt queue with steer controls (feb 2026, closed not planned)
• #29224 — side-channel acknowledgment for queued messages (feb 2026, open)
• #30677 — vs code extension interrupts instead of queuing (mar 2026, open)
• #26388 — queued messages misinterpreted due to lost timing context (feb 2026)
• #11106 — messages stuck in queue, never processed (nov 2025, open)
• #879 — input cleared when queued message promoted (apr 2025, open)

that's 9+ issues spanning 12 months, all describing the same core problem: there's no clear, intentional distinction between "interrupt this task" and "do this next."

minimal viable fix

the op's (s)top / (q)ueue prompt would work, but codex's approach is even lower friction — no prompt needed, just different keys. a minimal implementation:

• enter while busy = steer (inject at next breakpoint, current behavior but made explicit)
• tab while busy = queue (fifo buffer, process after current turn)
• visual indicator showing queued message count (e.g. [1 queued])

this would bring claude code to parity with codex on a feature that directly impacts whether teams can adopt it for real workflows — which is exactly the op's situation.

Adding novel suggestions from #36817 (which should be considered a sub-request of this issue):

Additional UX requests (from #36817)

The core queue-or-stop clarification requested here is great, but once a queue exists, there's a further gap: no visibility or control over what's queued.

Specific additions:

• View the queue — TUI should show pending messages while Claude is working (currently they're invisible)
• Delete a queued message — cancel a specific queued message without stopping the current task or waiting for it to run
• Promote / interrupt now — keyboard shortcut to take a specific queued message and run it immediately, stopping the current task cleanly
• Reorder the queue — move messages up/down in the pending list

Why it matters (Cursor parity)

Cursor surfaces the pending message queue prominently with inline controls. Without this, users are stuck either waiting for the full task to finish or hitting Escape (which cancels everything) with no selective control.

Related

• #29224 — Side-channel responses for queued messages
• #30677 — VS Code queued message support
• #36326 — Enter queues instead of interrupts (docs bug)

Adding a more code-level Codex reference here, using openai/codex branch main at commit e838645fa264ef108bb66b74ad284224d2a10ac0.

I checked that revision locally and traced the queue path end to end. The useful part is that this is not just a docs claim. Codex has a concrete TUI/data-flow implementation for it.

1. The behavior contract is explicit in the docs

Composer note

# abridged from the linked note
Tab   + running task -> queue
Enter               -> submit now
Tab on !command     -> do not queue/submit

This matters because it separates two user intents at the input-contract level, before getting into any queue internals.

2. The split is wired directly into the composer state machine

Composer routing
Busy key handling

// abridged from the linked file
if key == Tab && !is_bang_shell_command() {
    handle_submission(task_running)
}
if key == Enter {
    handle_submission(false)
}

if should_queue {
    return InputResult::Queued { ... }
}

This is the part I think is especially reusable: queuing is a first-class branch in the TUI input state machine, not a prompt-layer workaround.

3. Codex keeps steer state separate from queued-follow-up state

Queue state
Ordering logic

// abridged from the linked file
queued_user_messages: VecDeque<UserMessage>
rejected_steers_queue: VecDeque<UserMessage>
pending_steers: VecDeque<PendingSteer>

pop_next_queued_user_message() {
    rejected_steers first
    queued_user_messages after that
}

This is a strong design signal. Codex does not collapse everything into one ambiguous "pending input" bucket.

It distinguishes at least three cases:

• steer the current turn at the next safe boundary
• queue a future follow-up turn
• retry a steer that was rejected because the current turn is not steerable

That separation seems directly relevant to Claude Code, where the ambiguity between "interrupt", "steer", and "do this next" is the root problem.

4. The queue is real FIFO state, not just UI decoration

Queued result -> enqueue
Queue push/send
Next turn start
Drain next queued input

// abridged from the linked files
InputResult::Queued -> queue_user_message(user_message)

queue_user_message(msg) {
    if task_running {
        queued_user_messages.push_back(msg)
    } else {
        submit_user_message(msg)
    }
}

on turn complete -> maybe_send_next_queued_input()

So this is a normal, inspectable FIFO pipeline: queue while busy, then promote exactly one queued input into the next turn.

5. Codex also exposes queued state in the UI and lets the user edit it

Pending preview widget
Queued preview rendering
Edit last queued message

// abridged from the linked files
PendingInputPreview {
    pending_steers,
    rejected_steers,
    queued_messages,
}

if edit_last_queued_shortcut {
    restore_latest_queued_message_to_composer()
}

That is useful because once a queue exists, users also need visibility and control over what is queued.

6. The behavior is pinned by tests

Tab queues while busy
Interrupt restores queued messages
Edit-most-recent queued message
Rejected steers ordered ahead of later queued drafts

// abridged test expectations
Tab + task_running -> InputResult::Queued
Interrupt          -> queued messages restored into composer, in order
Edit shortcut      -> latest queued message pops back into composer
Rejected steer     -> retried ahead of ordinary queued draft

That is why I think this issue is better framed as a concrete implementation gap, not just a UX wishlist.

The most reusable ideas from Codex seem to be:

• explicit composer-level distinction between steer-now and queue-for-next-turn
• separate storage for pending steers vs queued drafts
• visible queue state in the TUI
• edit/restore behavior for queued drafts
• tests for FIFO ordering and interrupt/restore semantics

If Anthropic wanted a pragmatic first step, I would start from that decomposition rather than only adding a one-off clarification prompt.

For anyone who wants to reproduce the trace, mine was:
docs/tui-chat-composer.md -> bottom_pane/chat_composer.rs -> chatwidget.rs -> bottom_pane/pending_input_preview.rs -> related tests.

well, you banned third-party harness (Pi has follow-up msg), so no you have to fix it.

we really need this feature, most coding agents have it

I am not sure this is an exact match but I wrote this plugin that allows to queue messages.
They are auto inputted into your Claude sessions once it is idle: https://github.com/ncvgl/claude-prompt-queue/tree/main
I agree it is a missing feature that Codex has and they should add it eventually

It is becoming really annoying not to have this feature. Codex has much more advanced feature. Please implement this!

The ambiguity problem described here (queue vs. steer vs. interrupt) goes away when queue and steer are explicit, separate actions in the UI.

I built pikiclaw — it provides a web dashboard for managing Claude Code, Codex, and Gemini sessions. Messages sent while a task is running are queued by default. From the dashboard you can:

• Let it run in order (queue)
• Steer — interrupt current task and promote the queued one
• Recall — cancel a queued task before it executes

No disambiguation prompt needed — the intent is clear because queue and steer are distinct buttons, not overloaded on the same text input.

npx pikiclaw@latest

+1 — pure queue (no steering) behavior is still missing

I currently use Codex. I cannot use Claude Code as my primary CLI until this is fixed.

In Codex:

• Tab while the agent is busy = pure FIFO queue. The current task finishes uninterrupted, then the queued follow-up runs as the next independent turn.
• Enter while the agent is busy = steer / mid-turn injection.

That split is predictable. It supports long-running sessions where I can queue multiple follow-ups ahead of time without babysitting the agent.

Current Claude Code behavior does not provide that split:

• Enter while busy appears to route into the queued-command path and usually defers until a later boundary.
• Tab is still used for autocomplete, suggestions, or permission cycling, not queue.
• There is no explicit hotkey that guarantees pure deferral with zero ambiguity.

That ambiguity is the blocker. For long-running tasks, I need to know with certainty whether I am:

• queueing a follow-up that will run only after the current task fully completes, or
• steering the current task mid-flight.

Without that distinction, I cannot safely use Claude Code for workflows like:

• implement X
• add tests
• update docs
• commit
• run CI

Minimal change needed:

• Tab while busy -> explicit pure queue, FIFO deferral, no mid-turn injection
• keep Enter while busy as the steering path, or make the split configurable
• show clear UI state such as Queued — runs after current task vs Steering

The queueing infrastructure already exists. What is missing is the explicit, reliable, no-steering hotkey path.

The implementation should be split across claude-code/src/components/PromptInput/PromptInput.tsx, claude-code/src/utils/handlePromptSubmit.ts, and claude-code/src/screens/REPL.tsx, with a small optional type update in claude-code/src/types/textInputTypes.ts.

The key behavior change is:

• Tab while Claude is busy should become an explicit pure queue action, not steering.
• Enter while busy should keep the current steering / mid-turn behavior.
• The queued path should enqueue with priority: 'later'.
• The steering path should continue using the existing immediate queue behavior.
• The UI should show the current mode clearly, e.g. Queued — runs after current task versus Steering.

claude-code/src/utils/messageQueueManager.ts probably does not need a rewrite, since it already has the next vs later queue semantics.

ya'll need to understand that they obviously know about this since it has been requested for a long time and they dog food their own stuff, and that therefore they must necessarily have made a conscious decision not to implement this, but they cannot say it publicly because the reason would make them look bad or otherwise have to lie

ya'll need to understand that they obviously know about this since it has been requested for a long time and they dog food their own stuff, and that therefore they must necessarily have made a conscious decision not to implement this, but they cannot say it publicly because the reason would make them look bad or otherwise have to lie

I suspect they just want to disincentivise AFK claude coding because it will reduce the strain on their compute

> ya'll need to understand that they obviously know about this since it has been requested for a long time and they dog food their own stuff, and that therefore they must necessarily have made a conscious decision not to implement this, but they cannot say it publicly because the reason would make them look bad or otherwise have to lie I suspect they just want to disincentivise AFK claude coding because it will reduce the strain on their compute

Meanwhile Codex launches /goal

No real queue, but added goal. Makes sense 😅

recently started using pi.dev, deliberately minimal coding harness, but even they include "alt+enter" for queueing messages, in addition to plain enter (steer), out of the box...

Agreed the real fix is the explicit native split — Codex's Tab=queue / Enter=steer / Esc=interrupt,
where a queued message auto-runs as the next turn once the current one finishes. That's what most of this
thread wants and nothing third-party fully replaces it.

For the narrower moment in your example though — "an hour in, remembered I need a cleanup step afterward"
— here's a stopgap. Disclosure: I wrote a small open-source plugin called valet, so treat this as an
author plug.

• /valet:park <text> captures the follow-up. A UserPromptExpansion hook blocks the turn before the model

sees it, so the capture costs zero tokens and never enters the running task's context.

• /unpark later opens a native picker; you select the parked item and it becomes the next turn.

Limitation relative to your ask: it's manual, not auto-FIFO. It will NOT fire on its own when the current
task ends — you trigger it with /unpark. So it covers "don't lose the follow-up, don't interrupt the
run, don't burn context," not "run it automatically while I'm AFK."

https://github.com/YeautyYE/claude-valet