[FEATURE] VS Code Extension: Support queued message sending instead of interrupting current task
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
When Claude Code VS Code extension is running a task, if I send a new message, it interrupts the current task immediately. This is disruptive to my workflow — I often want to queue up the next instruction while waiting for the current task to finish, not stop it mid-execution.
Proposed Solution
Add a message queue feature to the VS Code extension. When Claude is busy running a task, any new message sent by the user should be held in a queue and automatically sent once the current task completes — instead of interrupting the running task.
The interface should show a visual indicator (e.g., "1 message queued") so the user knows their message has been received and will be processed next.
Optionally, the user could also cancel the queued message before it's sent.
Alternative Solutions
Currently, the only workaround is to wait for the task to finish before typing the next message. There is no built-in queuing mechanism.
Other AI coding tools (e.g., Cursor) offer a similar "queue" or "wait" behavior that prevents accidental task interruption.
Priority
High - Significant impact on productivity
Feature Category
Developer tools/SDK
Use Case Example
- I ask Claude Code VS Code extension to refactor a large module — this takes ~30 seconds.
- 2. While it's running, I think of the next step: "also update the tests."
- 3. I type "also update the tests" and hit Enter.
- 4. Current behavior: Claude stops the refactoring mid-way and starts working on the tests instead.
- 5. Expected behavior: Claude finishes the refactoring first, then automatically processes "also update the tests" from the queue.
This would allow me to think ahead and queue instructions without disrupting Claude's current focus.
Additional Context
_No response_
22 Comments
Found 1 possible duplicate issue:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Queuing should be the default behavior when sending- not sure what would be causing it to interrupt- this should only be escape or similar.
+1 on this. Would also love the ability to configure this as the default behavior globally (e.g., via
settings.json), so every message typed during an active task is automatically queued rather than injected. The visual "1 message queued" indicator would make this feel much more intentional and predictable.The current workaround of waiting for Claude to finish before typing is fine but breaks flow when you think of the next instruction mid-task.
this would be very helpful. FYI, codex does this... press TAB to queue instead of ENTER to send now
+1 this is almost the default feature for other coding clis.
Yes why isn't this a thing yet?
Yeah I know I can submit a message while the model is working / reasoning and it will pick the message up once it is done reasoning, but that interrupts the current task sometimes.
This is so necessary to be able to scale up the pace while maintaining control. I want to be able to queue my routine double checking, cleaning, coverage and commiting to a full DOD.
Why do I need to monkey baby sit claude when I trust it.
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.
+1, this would be a massive quality-of-life update. The message queuing and up-arrow editing functionality in the Claude Code CLI terminal is an incredible workflow. Bringing that same non-interrupting, editable message buffer to the VS Code extension would drastically improve the developer experience and keep things consistent across interfaces.
please add +1
Strong +1 on this.
The terminal CLI already lets you park a side note without stopping the
active task (the /btw command) and supports queued messages that get
picked up at the next natural breakpoint. The VSCode extension has no
equivalent: any message I send while a task is running interrupts it.
Concrete use case: during a long task (a build, or a multi step refactor)
I regularly think of a follow up or a clarifying question. In the CLI I
can park it and let the task keep running. In the extension my only
options are to wait, or to interrupt and risk derailing the work.
Bringing CLI parity to the extension would close the gap: a queue mode
plus an optional /btw style park, with a small "1 queued" indicator near
the input box and the ability to cancel a queued message before it is
sent. Happy to test.
+5 This used to work a few weeks ago. It would be really helpful to have it back
+1. I have been using Codex for quite a while now and am painfully missing this feature from the Claude extension.
Still repro'ing on the latest build — VSCode extension
2.1.183(linux-arm64), CLI2.1.185. Sending a message while a task is running interrupts/cancels it instead of queuing; no "queued" indicator, no setting to toggle it.@blois re your comment: on this version it's a plain Enter (send) that interrupts, not Escape. I poked at the webview bundle and send-while-busy goes through
interruptClaude, and there are no message-queue strings in it (onlyinterrupt/interruptedMessage). So at least on linux-arm64 the queuing path doesn't seem wired up — possibly the regression a couple of folks above mention ("used to work a few weeks ago"). Happy to provide more repro detail / logs.Cant believe this is not implemented yet. I have migrated from GH Copilot and missing this from 1 hour of use
Yaaaaassss please
Is this feature on roadmap? A command or option to change the default behavior? Codex and Copilot can do this.
Desperately need this feature. Is it on the roadmap?
I'm hitting the same underlying problem as this thread, mid-task
steering, but from the other side, and I want to flag it here since a
number of CLI reports seem to have been consolidated into this issue.
This one is labeled
platform:vscodeand asks for messages to be heldinstead of interrupting immediately. On the CLI they're already held,
sometimes for minutes and many tool calls, so the failure mode inverts:
a correction sits unread while the task keeps running against the old
instructions, and the only way to force it through is an interrupt,
which kills in-flight bash processes and subagents.
Same gap, opposite symptom. Both come down to there being no way to
adjust a running task without either waiting or destroying it. Filing
the CLI side separately as #92899 so the two don't get conflated.
[cli] 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.
I seriously cannot believe this still an issue. With all AI at Anthropic's disposal, they still do not have this MOST BASIC feature that both Copilot and Codex had for YEARS. Each time when in Claude I habitually press Enter mid-task ( =
queue actionin all other agents), it makes my blood pressure spike, as I am not certain whether my prompt will ruin current task or not... Vibe-coding was supposed to be relaxing, not this!Are we heading to AGI or to bubble burst? Asking for a friend.
this is an economics problem. it has nothing to do with software