Claude Code queue message: what pressing Enter does while Claude works

Find the situation you are in

• I typed while Claude was working and I want to know what happened to my message.
• It has not been read yet and I want to know when it will be.
• I want to force it into the queue rather than affect the current turn.
• I want it sent now, or Claude stopped doing what I asked.
• I queued the wrong thing and want it back.
• I backgrounded the session and want to know where the queue went.
• I want to change the keys, or find a setting for this.

Most of these end in one keypress. The queue itself is small: a message goes in when you press Enter while Claude is busy, it comes out at a documented moment, and four keys move it along. If your question is about interrupting a turn rather than queueing one, the plan mode guide covers approving and declining what Claude proposes mid-turn.

What the queue is

Claude Code keeps one queue per session. While Claude is working, anything you type and submit joins that queue instead of interrupting the turn, and the queued entries are listed in the conversation until Claude Code sends them. Both the messages you have sent and the ones still waiting show in gray until Claude starts responding to them, so the colour tells you what is still outstanding.

A queued entry is not only prose. You can queue ! shell commands and most slash commands the same way, with the exception of commands such as /status that Claude Code runs as soon as you send them. The two kinds behave differently once the turn ends: messages go to Claude, while commands and shell commands are held until the turn finishes and then run one at a time, in the order you queued them.

Two details are easy to miss. If you queue a message with a selection attached from a connected IDE, it keeps the selection you had when you pressed Enter, whatever you select afterwards. And this is the same mechanism Anthropic describes under the heading "Interrupt and steer": pressing Enter without stopping Claude is one of the two documented ways to redirect a turn before it finishes.

One scope note before the mechanics. The queue itself is not a terminal-only feature. The desktop app's page documents the same move in its own words, that you type a correction and press Enter to send it without stopping the running action, and that Claude reads it as soon as the current action completes. The app has a queue and a send-now action too; its changelog records a fix to send-now when a message was already waiting. The VS Code extension announces "Message queued." and keeps the selection you had when you queued the message. What is particular to the terminal is the keyboard control: Ctrl+X Enter to queue a message, Ctrl+Enter to release the queue, and Up to take a message back and edit it. That last one is exactly what the desktop app does not have yet.

When your queued message is read

When a queued message reaches Claude depends on what Claude was doing at the moment you pressed Enter. If Claude is running tool calls, Claude Code passes your message to it as soon as those calls finish, within the same turn. If the turn ends with messages still queued, they go out without another keypress, in the order you typed them.

That first case is what people mean by steering. A message queued behind a running tool call does not wait politely for the whole task: it arrives inside the turn, after the current call returns, and Claude adjusts before its next step. Anthropic's own walkthrough says the same thing in its own words, that Claude reads the message as soon as those calls finish and adjusts before its next step.

The timing has a visible cost, and one open report walks through it step by step. A queued message cannot be read in the middle of a tool call, so behind a long build or test suite it waits for that call to return, however long that is. The documented alternative is to empty the queue now, and what that costs depends on the work: anything that can move to the background moves there and keeps running while Claude reads your messages in the same turn, while a turn that is only writing a response is interrupted.

Force a queue rather than a steer

The explicit queue key is Ctrl+X Enter, bound to the action chat:queueSubmit. Anthropic describes it as submitting the message marked to wait its turn: while Claude is working, Claude Code queues it and never interrupts the turn. It also submits while an autocomplete suggestion is highlighted, which the ordinary submit key does not do. It requires Claude Code v2.1.247 or later.

Here is the honest limit of that key. chat:queueSubmit guarantees the message does not interrupt the turn; it does not change the moment Anthropic documents for reading it, so behind a running tool call it is still read inside that turn. The limit is narrower than it sounds. If nothing was running when you queued the message, it is still queued when the turn ends, and Anthropic documents that messages still queued then go out without another keypress. What no key and no setting does is keep a message out of a turn that is already running tool calls. The reports section lists the open requests asking Anthropic for a way to choose between the two.

Send the queue now

Press Ctrl+Enter to send what you have queued without waiting, together with your draft behind it. That binding is chat:sendNow, and it has a second form, Ctrl+X Ctrl+S, for terminals that do not report extended keys and therefore deliver Ctrl+Enter as a plain Enter. In shell mode the key only queues your command.

One condition comes before every other: if you queued a ! shell command ahead of your messages, the key interrupts the turn. Otherwise what it does depends on the work, and this is the detail that surprises people. Work that can move to the background, such as shell commands or subagents, moves there and keeps running while Claude reads your messages in the same turn. Work that cannot move, or a response that is only being written, is interrupted, and your messages go next. Anthropic changed the background case in v2.1.281: before that release the key interrupted the turn either way, instead of letting backgroundable work carry on.

The key is recent, and its history explains a stale habit. It arrived in v2.1.275, which is also the release that made queued messages show in gray until the model receives them. Until v2.1.309, pressing it before the response had started only queued the message, so older advice that calls it unreliable is describing a bug that has since been fixed.

If you want to stop the turn and let the queue go next, Esc is the separate key. It stops the current response or tool call, keeps the work done so far, and leaves your draft unsubmitted. Any messages you had queued are sent next, so an interrupt is also a way to promote the queue.

Take a queued message back

Press Up from the first line of the input box. Claude Code pulls the queued messages and commands out of the queue and puts them in the input box, one per line, ahead of anything you had typed. Edit the text and press Enter to queue it again as a single entry, or clear the box to drop it.

Shell commands come back on a narrower condition: only when the input box is empty and you have nothing else queued, and Claude Code switches the box into shell mode when it does. Otherwise they stay in the queue, listed with their ! prefix, and run after the turn ends.

There is one collision worth knowing. If you take back queued text while ← is waiting to move the session to the background, the text stays in the input box and Claude Code cancels the switch. If you take it back at the exact moment the session moves, the text disappears with the foreground screen: it was never sent. Each message you take back is saved as its own entry in command history, and you can recover one by reopening the session and pressing Up on an empty prompt with nothing queued.

Queue and background

When a session moves to the background after you press ←, the messages you had queued move with it, and Claude reads them there in the order you sent them. Two things refuse to travel. Commands and ! shell commands cannot move, and neither can some messages, such as one with an IDE selection attached. Press ← while one of those is queued and the session stays in the foreground with a notice that begins Cannot open agents. Typing into the prompt input cancels it too, for its own reason: unsent text lives in your terminal's input box and cannot move to a background session.

The queue also runs the other way, from agent view. A reply typed into a working session's peek panel joins that session's message queue instead of interrupting the response, though /model, /effort, /rename and /usage run right away, and other commands wait for the turn to end. A reply that is exactly /stop is not delivered at all: it stops the session at once. Running several sessions this way is the subject of the parallel agents guide.

The documented ways to change it

There is no setting for this. The settings reference says nothing about the prompt queue, so no configuration file changes whether a message queues or steers. What you can change is the key, in the keybindings file, which is an object holding a bindings array of per-context blocks. Changes are applied without restarting Claude Code.

{
  "$schema": "https://www.schemastore.org/claude-code-keybindings.json",
  "bindings": [
    {
      "context": "Chat",
      "bindings": {
        "ctrl+q": "chat:queueSubmit",
        "ctrl+enter": "chat:sendNow"
      }
    }
  ]
}

Both actions live in the Chat context: chat:queueSubmit for a message that never interrupts the turn, and chat:sendNow for sending the queue at once. Moving them is the only lever Anthropic documents. If your terminal does not report extended keys, keep a chord such as Ctrl+X Ctrl+S on send-now rather than Ctrl+Enter, because that terminal will read Ctrl+Enter as a plain Enter and queue your draft instead.

Commands that skip the queue

A command sent while Claude is responding is queued and runs after the current turn finishes, but a few run immediately without interrupting: /status, /tasks and /usage are Anthropic's examples. In fullscreen rendering, dialog commands such as /theme and /help also open at once; before v2.1.234 those were queued until the turn ended.

Three commands that change a setting run as soon as you send them instead of queueing, and each reaches the running turn differently. /model applies to the next request Claude Code makes in that turn, once you confirm the cache warning if one appears. /effort takes effect on the next message you send, and the documented way to start it inside the turn Claude is already on is to queue a message while it is running tool calls. /fast keeps the setting that was active when the turn started, so a speed change applies from your next turn.

What people are reporting

These are open reports in Anthropic's issue tracker as we write this, not Anthropic statements, and none of them describes something this page can fix. They are worth reading because between them they describe the gap this page has to keep saying no to: no way to keep a queued message out of a turn already running tool calls, and a desktop app whose queued messages cannot be corrected from the keyboard.

• Issue 98493, open since 2026-09-30: the reporter found that in the desktop app's Code tab a new message steered the current turn with no way to queue, and asks for a choice between the two. 3 reactions, 2 comments.
• Issue 98415, open since 2026-09-30: a request for Enter on a transcript annotation to add it to the prompt instead of sending it, with Ctrl+Enter for sending. 1 reaction, no comments.
• Issue 98013, open since 2026-09-28: a queued message is delivered only after the running tool call finishes, so behind a long build it waits that whole time. The reporter reproduces it on 2.1.284 and asks for something between queueing and interrupting. 2 reactions, 1 comment.
• Issue 104294, open since 2026-10-22: a request to queue a message while the session is paused on a usage limit and have it delivered first when the limit resets. 1 reaction, no comments.
• Issue 105411, opened 2026-10-27: a request to edit queued messages from the keyboard in the desktop app's Code tab. No reactions or comments yet.
• Issue 100003, open since 2026-10-06: a bug report that messages queued during a running turn are lost when the session exits and is resumed. No reactions, 1 comment.

Five of those are requests rather than defects, and reading one as a fault will send you looking for something that is not broken: the desktop app's reading of a correction, the annotation key, the tool-call wait, the paused-session wait and the missing keyboard edit are all how it works today. The sixth is different: it reports messages lost when a session exits and is resumed.

Where this page stops

This page owns the message queue: what goes into it, when it is read, the keys that force it, empty it or take it back, and what happens to it when a session moves to the background. Three neighbours own the rest.

• Stopping or redirecting a turn by hand, and the permission modes that decide what Claude may do mid-turn, belong to the plan mode guide.
• Going back to a checkpoint before a prompt is the subject of the checkpoints guide, which also covers the double-Esc rows this page leaves alone.
• Spreading work across sessions, worktrees and terminals belongs to the multiple sessions guide.

Anything else about a session, from context to cost, is covered by the other Claude Code guides.

Omniscio's message queue

Omniscio is the desktop app we make for running many Claude Code sessions at once, and it has a message queue of its own. It works in the opposite direction from the Claude Code terminal, so the first thing to know is the default: pressing Enter in an Omniscio session sends the message now and interrupts a running turn. Queueing is the deliberate alternative there, not the automatic behaviour.

While the agent is working, open the Send Later picker by holding the Send button or clicking its caret, and pick After the agent finishes, which is the first option and only appears while the agent is running. Your message joins the session's queue and a single line reading N messages queued appears at the foot of the conversation. Click that line to open the ordered list, where each row has its own Edit, Reorder and Remove controls.

The delivery rule is the interesting part for anyone who arrived here wanting a message that does not steer. Delivery rides the same path a normal send uses, fired the instant a turn completes and the session goes idle, so it never interrupts a running step. Each session holds up to 200 queued messages, a queue held for a paused or unavailable session waits at most 24 hours before the message is set aside as undelivered, and a message that has been delivered or removed is kept for 7 days and then deleted.

An ended or archived session refuses a new queued message outright rather than accepting it and dropping it a moment later, and it names the state so you can pick another route. The detail, including how several waiting messages go over together in one turn, is in the Queue a message library page. To see what else the app does, the features page has the list and the download page has the installers.

Sources

Every Claude Code behaviour on this page rests on one of these pages, and each was read on the date beside it.

• Interactive mode, for the queue section, when queued entries are sent, the background and take-back behaviour, and every keyboard row quoted here. Read October 27, 2026.
• Keybindings, for chat:queueSubmit and chat:sendNow, their default keys, their version requirements and the file format. Read October 27, 2026.
• How Claude Code works, for the "Interrupt and steer" walkthrough. Read October 27, 2026.
• Commands, for commands that queue, commands that run immediately, and the three that change a setting. Read October 27, 2026.
• Agent view, for replies from the peek panel joining a working session's queue and the /stop reply. Read October 27, 2026.
• Settings reference, searched for any setting that changes how a queued message is delivered. Read October 27, 2026.
• Claude Code in the desktop app, for the prompt-box behaviour in the Code tab. Read October 27, 2026.
• VS Code extension, for the queued-message announcement and the selection a queued message keeps. Read October 27, 2026.
• Changelog, for v2.1.275, v2.1.281, v2.1.292, v2.1.309 and the v2.1.234 dialog note. Read October 27, 2026.
• The six issue pages linked above, each read on October 27, 2026, with its state, reaction count and comment count taken from the issue itself.
• Omniscio's own Queue a message library page, read on October 27, 2026, and the source files named in the fact ledger for the numbers it quotes.
• One capture run on this machine on October 27, 2026: claude --version, which printed 2.1.311 (Claude Code), and a text search of that installed build for the two action names.

This area moves with releases: the queue gained a send-now key in v2.1.275, changed how it treats background work in v2.1.281, and had a send-now bug fixed in v2.1.309. If a release note mentions the queue, re-read the interactive mode page before trusting a copy of this one from last month.

Common questions

Does Claude Code queue messages or send them immediately?

It queues them. Type a message and press Enter while Claude is working, and Claude Code queues the message instead of interrupting the turn, then lists the queued entries in the conversation until it sends them. Queued and sent messages show in gray until Claude starts on them. The desktop app reads a correction the same way, and what it lacks is the terminal's keyboard control: you cannot pull a queued message back with Up and edit it there.

How do I make a message queue instead of interrupting the turn?

Press Ctrl+X Enter. That binding is chat:queueSubmit, which submits the message marked to wait its turn: while Claude is working it queues the entry and never interrupts the turn, and it submits even while an autocomplete suggestion is highlighted. It needs Claude Code v2.1.247 or later. If you came here to release a message that is already queued, press Ctrl+Enter instead.

How do I stop a queued message from steering the current turn?

Nothing documented does. If Claude is running tool calls when you queue a message, Anthropic says it passes the message to Claude as soon as those calls finish, within the same turn, and neither a key nor a setting changes that. A message still queued when the turn ends goes out then, which Anthropic documents. Removing it from the queue is the only way to keep it out of a turn that is already running.

How do I send the queue right now?

Press Ctrl+Enter, or Ctrl+X Ctrl+S in a terminal that does not report Ctrl+Enter. That sends everything you queued, and your draft with it, right away. What happens to the turn Claude is on depends on what it is doing: work that can move to the background moves there and keeps running, while a response that is only being written is interrupted.