OpenClaw Queue Modes Guide: steer vs followup vs collect vs interrupt, and Why Your Correction Arrived Late

A message you send while an OpenClaw agent is busy goes through the command queue, and the queue mode decides what happens to it. The default, steer, injects your message into the running turn after the current tool batch finishes. followup holds it for a separate turn, collect merges a burst into one turn, and interrupt aborts the run and answers your newest message. None of them stop a tool that is already running; for that, send /stop.

You asked the agent to clean up a branch. Two seconds later you see it is the wrong branch, and you type "stop, wrong one" into Telegram. The agent finishes the delete anyway, then reads your message and apologizes. Nothing was broken. That is steer mode doing exactly what the docs say it does, and most people only learn the rule the day it costs them something.

I worked from the official Command queue page as published on November 3, 2026. Everything below about defaults and keys comes from there. The opinions are mine.

One turn per session, and everything else waits

OpenClaw runs one turn at a time per session. CLI, embedded and Codex runs share a single session controller mailbox, so switching runtimes can't start a second turn alongside the first. Anything that arrives while a turn is running has to go somewhere, and messages.queue is where you decide where. (The same serialization is why a fixed hooks.defaultSessionKey lines every webhook up behind the slowest run, which the webhooks guide covers.)

The four modes compared

What steer does at a tool boundary

Steering never aborts a tool in flight. OpenClaw checks for steering after each tool batch settles, and your message shows up before the model decides what to do next. Parallel tool batches are never skipped halfway.

Sequential calls are the subtle part. If the model has queued several calls in one assistant message, the first executable one may already be running when your message arrives. The ones after it that have not started get skipped, and each receives a synthetic error result so the transcript stays valid. In the branch example, that is the difference between losing one branch and losing four.

If the runtime can't accept steering at all, your message waits for the run to end. In practice it then behaves like a followup, which is confusing if you don't know it happened.

One cosmetic trap. With partial or block streaming, a steered run can look like several short replies in a row. Easy to mistake for the agent answering twice.

/stop is the brake

No queue mode is a brake. When you need the current run to end now, use /stop (or Esc in a Gateway-backed client), which aborts for that session. I would teach every person who talks to your agent that one command before anything else, because "stop" typed as a sentence is just another message to steer with, and the tool you were worried about has usually finished by the time the model reads it.

/queue interrupt is a different thing: a stored mode that aborts the active run every time a new message comes in. Cancelling a queued request with chat.abort and a runId removes only that request and leaves the active turn alone.

Setting the mode in config

messages: {
  queue: {
    mode: "steer",
    allowCollaborativeSteering: false,
    cap: 20,
    drop: "summarize",
    byChannel: { discord: "collect", x: "followup" },
    debounceMsByChannel: { discord: 1000, x: 500 },
  },
}

That is close to the example on the official page. The built-in defaults are steer, a 500 ms debounce, a cap of 20 queued messages, drop: "summarize", and allowCollaborativeSteering: true. Run openclaw config validate after editing, then restart the Gateway.

Mode precedence runs from narrow to broad: a session's /queue override, then byChannel, then mode, then the built-in steer. Options follow a similar order: inline or stored /queue options first, then channel debounce, then plugin defaults, then built-ins.

Changing it per session with /queue

/queue followup
/queue collect debounce:0.5s cap:25 drop:summarize
/queue default
/followup Also check the staging branch when you are done.

/queue <mode> stores the mode for that session only. Options combine on one line. Debounce accepts bare milliseconds or a unit (ms, s, m, h, d), and a cap below 1 is ignored. /queue default and /queue reset both clear the override.

/followup is the one I use most. It sends a single message as a new turn without touching the stored mode, so you can stay on steer and still say "after this, do the other thing" without that sentence getting pulled into the current run.

Collect does nothing on Discord and Telegram

Channels that use durable ingress admission keep every message as its own followup turn. The docs name Discord and Telegram. So byChannel: { telegram: "collect" } gives you followup behavior, and the burst of five short messages you hoped to merge becomes five turns. Raising the debounce won't change that.

The upside of durable ingress is that retained messages stay retryable if the turn is abandoned before adoption, and by default a message only becomes eligible for dead-lettering after eight failed attempts and 24 hours.

Where collect does apply, messages merge only when they share routing, authorization and execution settings, with compatible operator sources and tool permissions. The page does not say whether two different senders count as compatible, so I wouldn't build anything that depends on it.

Group chats and collaborative steering

By default anyone in a shared channel can steer your run. You ask the agent to draft release notes, a teammate types "also mention the API change", and that lands inside your turn as if you had said it. Sometimes that is the point. In a channel with more than three or four active people it gets chaotic fast, and I would set allowCollaborativeSteering: false for any agent that sits in a team channel. Other people's messages then queue as new turns. Add collaborativeSteeringFallback: "reject" if you want them to type /followup explicitly. The multi-channel messaging guide covers the routing side of shared channels.

cap and drop, for when the queue fills

Twenty messages is a lot for a person and very little for an alert channel. When the queue is full, drop decides who loses. summarize keeps compact summaries of dropped entries and injects them as one synthetic followup. old discards the oldest with no summary, and new rejects the newest message.

Keep summarize. Losing a message silently is worse than reading a compressed version of it, and for a monitoring feed that can flood, the better fix is filtering upstream with a webhook transform so the agent never sees most of it.

Codex runs steer a little differently

On the Codex runtime, steer mode sends one batched turn/steer that applies at the next model boundary, and debounce sets the quiet window for that batch. Codex-native subagents use Codex's own scheduler, outside OpenClaw's subagent lanes (which default to 8 concurrent per spawning session). If you mix runtimes in a multi-agent setup, don't expect one concurrency setting to govern both.

When a message seems stuck

Turn on verbose logs and look for queued for ...ms lines; OpenClaw notes runs that waited more than about 2 seconds. A lane wait exceeded line with activeAhead=1 activeNow=0 can appear right after a task finishes and does not by itself mean a slot leaked. Diagnostics label stalled sessions session.long_running, session.stalled or session.stuck, and a message waiting for admission shows as waiting. After a stall aborts an interactive turn, OpenClaw tries one continuation before asking you to retry. The logging guide shows how to tail and filter that stream.

Interrupted runs stay interrupted

Restart recovery will not resume a run that interrupt cancelled, so whatever the agent was halfway through when your new message arrived is now yours to finish by hand.

Where each mode fits (and where it does not)

steer fits a one-person direct chat, which is most installs, and it is the right default. It does not fit anyone who expects "stop" to stop something. Pair it with /stop.

followup fits channels where each message is an independent request, like a shared support inbox or the x example in the docs. It is a poor fit for your own chat, where half your messages are corrections.

collect fits people who split one thought across several lines, on a channel outside the durable-ingress group. The docs name Discord and Telegram there, and on those two it buys you nothing.

interrupt fits a lookup bot where answers are fast and only the latest question matters. I would never use it for an agent that edits files or runs shell commands, since every new message abandons whatever was half done.

Final verdict

Leave the global mode on steer, teach everyone /stop, and use /followup when you want to add work instead of redirecting it. Set allowCollaborativeSteering: false for any agent in a team channel, keep drop: "summarize", and skip collect on Discord and Telegram because it quietly behaves like followup there.