[FEATURE] VS Code Extension: Support queued message sending instead of interrupting current task

Status Open
Maintainer reply ✓ Yes — blois
Activity 17 comments · opened Mar 4, 2026
💡 Likely answer: A maintainer (blois, collaborator) responded on this thread — see the highlighted reply below.

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

  1. I ask Claude Code VS Code extension to refactor a large module — this takes ~30 seconds.
  2. 2. While it's running, I think of the next step: "also update the tests."
  3. 3. I type "also update the tests" and hit Enter.
  4. 4. Current behavior: Claude stops the refactoring mid-way and starts working on the tests instead.
  5. 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_

View original on GitHub ↗

17 Comments

github-actions[bot] · 5 months ago

Found 1 possible duplicate issue:

  1. https://github.com/anthropics/claude-code/issues/25845

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

blois collaborator · 5 months ago

Queuing should be the default behavior when sending- not sure what would be causing it to interrupt- this should only be escape or similar.

nitaiaharoni1 · 5 months ago

+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.

earonesty · 4 months ago

this would be very helpful. FYI, codex does this... press TAB to queue instead of ENTER to send now

callzhang · 3 months ago

+1 this is almost the default feature for other coding clis.

2-click · 3 months ago

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.

Nucs · 3 months ago

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.

Masterxilo · 3 months ago

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.

NeekNegoer · 3 months ago

+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.

nikjay69 · 3 months ago

please add +1

ezwep · 2 months ago

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.

dami-gupta-git · 2 months ago

+5 This used to work a few weeks ago. It would be really helpful to have it back

shurkanTwo · 2 months ago

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

tfbecker · 2 months ago

Still repro'ing on the latest build — VSCode extension 2.1.183 (linux-arm64), CLI 2.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 (only interrupt / 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.

cdiazal · 1 month ago

Cant believe this is not implemented yet. I have migrated from GH Copilot and missing this from 1 hour of use

lunatiqqc · 1 month ago

Yaaaaassss please

4piu · 13 days ago

Is this feature on roadmap? A command or option to change the default behavior? Codex and Copilot can do this.