Desktop Code tab has no way to queue a message until the turn fully ends — Ctrl+Enter is "Interrupt", and the CLI's chat:queueSubmit has no Desktop equivalent
Environment
- Claude Desktop (Windows 11), app
1.49585.0, Code tab - Bundled CLI
2.1.260 ~/.claude/keybindings.jsonis empty (all defaults)
What I want
To send a follow-up message while Claude is working and have it wait until the entire turn finishes — not be injected at the next tool-call boundary.
What's available today in the Code tab
While Claude is working, the send button's tooltip lists exactly three options:
| Label | Key |
| --- | --- |
| Send | Enter |
| Interrupt | Ctrl+Enter |
| Send in a forked session | Ctrl+Alt+Enter |
Enterqueues, but per the interactive mode docs, a queued message is passed to Claude "as soon as those tool calls finish, within the same turn".Ctrl+Enteris Interrupt — the app's own description string is "Interrupts the current step so only this message is read now". That is the opposite of waiting.
So there is no "wait for the turn to end" option in the Code tab.
The CLI already solved this; Desktop did not
chat:queueSubmit (default Ctrl+X Enter, v2.1.247+) is documented as:
marked to wait its turn: while Claude is working, Claude Code queues it and never interrupts the turn
That action is not reachable from the Desktop Code tab — the Desktop docs state that terminal interactive-mode shortcuts do not apply there, and the Code tab's own shortcut list (Ctrl+/) has no equivalent.
The affordance appears to exist in the app but is not reachable
The desktop bundle ships a send-button option labeled "Queue for later" (message id 8RUKIaTN4d, with translations), alongside sendSteeredNow / recallSteered handling for queued rows. On my install the Ctrl+Enter slot renders "Interrupt" instead, and "Queue for later" never appears — with a mouse, no send-button dropdown is offered either. Whatever gates it is off here, and there is no user-facing setting for it: nothing in the settings JSON schema, nothing in Settings → Claude Code.
Restarting the app into a newer build (1.46388.4 → 1.49585.0) did not change this.
Request
Expose "queue until the turn fully ends" in the Desktop Code tab — as a send-button option, a keystroke, or a setting. Parity with the CLI's chat:queueSubmit would be enough.
Related
- #77724 — earlier request, closed; the fix landed in the CLI only
- #71726 — the original Desktop-vs-CLI parity gap on mid-task queue injection
7 Comments
This is a regression rather than a missing feature, and it isn't Windows only. Until 9 September, Cmd/Ctrl+Enter during a running turn queued the message until the turn ended. The same chord is now bound to Interrupt. I lost it on macOS with 1.49585.0 as well.
The change is in the claude.ai web code the Code tab loads, not in the app or the bundled CLI, which is why moving between 1.46388.4 and 1.49585.0 makes no difference. In both builds the keydown handler passes
metaKey || ctrlKeyinto the function that builds the submit options. In the build still being served at 2026-09-08 23:11 UTC that function read (minified names replaced):and in the one being served by 03:38 UTC, when this issue was filed:
Both branches send with
priority: "next". The difference is thatinterruptalso interrupts the running turn. Nothing in the composer producespriority: "later"anymore and the "Queue for later" string (8RUKIaTN4d) is gone from the build, so it isn't gated off. It was removed.It looks like steering landing for #71726 and #77724, both closed as completed on 25 August, with the option to wait for the turn dropped instead of kept beside it. The changelog has no entry for it and the desktop shortcut list has none for either key.
#93239 reports the same regression but has plain Enter interrupting too. In the client code plain Enter takes the
steerbranch and never interrupts, so that part looks like a separate problem.Another irritating change is how pressing the Escape key while the focus is on the chat box now interrupts the agent.
Edit: OK queueing messages with Ctrl + Enter works again! Styling of the UI could be better as it really looks like an already sent message.
Follow-up to my comment above: the change was reverted. In the claude.ai build served by 11 September, Cmd/Ctrl+Enter during a running turn builds
{ priority: chord ? "later" : "next" }again, and its hint reads "Queue for later" (8RUKIaTN4d) again. On macOS the message waits for the turn to end, as it did before 9 September. The Code tab can keep the web code it loaded for hours, so if you still get Interrupt, relaunch the app first.What @shinjipons noticed is the part that's left. The queued message is added to the transcript right away, looking like one that was already sent, and only moves below the response once the turn ends. Its one visible mark is a small hint next to it. The client has a specific hint for this ("Unread until the current turn ends."), but it's behind a server-side flag, and without it the hint just reads "unread", the same as for a message steered in with plain Enter. So until it lands you can't tell which of the two you sent.
#93402 reports the same regression.
Still happening on Windows as of 2026-09-14.
keybindings.jsonWhile Claude is running a turn, Ctrl+Enter sends the message right away instead of queueing it until the turn ends. The message reaches the agent mid-turn. From my side it started about two weeks ago; before that, Ctrl+Enter queued as expected.
Follow-up: I fully quit the app (including from the system tray) and started it again. Ctrl+Enter during a running turn still doesn't queue the message on Windows, same versions as above (desktop 1.52386.6.0, Windows 11 Pro 10.0.26200). So on my machine the restart doesn't bring back the reverted behavior.
@Chris-j-h-m are you sure? On my machine, its confusing because it _appears_ as if the message gets send mid-turn, while it actually moves with the turn and only gets processed after it.
Also, on my machine Ctrl/Cmd+Enter definitely doesn't interrupt anymore since that update.