Steering Queue in OpenClaw

When a prompt arrives in the middle of an ongoing session run and the queue mode is steer (the default, requiring no configuration), OpenClaw attempts to route that prompt into the currently active runtime. The delivery mechanics differ between OpenClaw and the native Codex app-server harness.

This page explains queue-mode steering for regular inbound messages in steer mode. In followup or collect mode, standard messages bypass this route and hold off until the active run concludes. For the explicit /steer <message> command, refer to Steer.

Runtime boundary

Steering never interrupts a tool call that is already executing. The OpenClaw runtime performs checks at tool-launch points and model boundaries:

The assistant requests tool calls.
In sequential mode, OpenClaw verifies right before each call begins, including after asynchronous resolution, validation, and pre-execution hooks.
An in-flight call completes. If a steer is pending afterward, the unstarted sequential remainder gets skipped.
In parallel mode, OpenClaw assembles calls first, then verifies once right before launching the assembled set. Calls that have passed that checkpoint proceed together.
Every skipped call receives paired tool start/end events and a synthetic error result (Skipped due to queued user message.), in assistant source order.
OpenClaw appends the exact drained steering message before the next LLM call.

This guarantees each requested tool call pairs with a result, while accepted steering becomes visible to the model before any later tool starts.

The native Codex app-server harness exposes turn/steer instead of the OpenClaw runtime's internal steering queue. OpenClaw batches queued prompts for the configured quiet window, then dispatches a single turn/steer request containing all collected user input in arrival order. Codex's upstream turn scheduler manages its own tool scheduling and consumes accepted steering at the next model boundary; OpenClaw adds no per-tool preemption to that runtime.

Codex review and manual compaction turns reject same-turn steering. When a runtime cannot accept steering in steer mode, OpenClaw holds off until the active run finishes before launching the prompt.

Tool launch boundaries

OpenClaw separates started work from requested work:

A sequential call that is already running completes. Later calls have not started, so OpenClaw returns synthetic skipped results for them and lets the model reconsider with the steer visible.
A parallel batch has one atomic launch checkpoint. A steer present before it suppresses all prepared calls; a steer arriving after it does not recall any of them.
Validation or policy outcomes finalized before the parallel checkpoint remain truthful. Only executable calls that did not start receive the steering skip result.
The transcript stays append-only and structurally paired: assistant tool calls, real or synthetic tool results, then the steering user message.

Stopping already-running work is a different intent from redirecting future work. Use /queue interrupt (or /stop) when the newest message should abort the active run instead of steering it.

Modes

Mode	Active-run behavior	Later behavior
`steer`	Steers the prompt into the active runtime when it can.	Waits for the active run to finish if steering is unavailable.
`followup`	Does not steer.	Runs queued messages later after the active run ends.
`collect`	Does not steer.	Coalesces compatible queued messages into one later turn after the debounce window.
`interrupt`	Aborts the active run instead of steering it.	Starts the newest message after aborting.

Burst example

If four users send messages while the agent is executing a tool call:

OpenClaw preserves the runtime's configured steering drain mode and FIFO order. One-at-a-time consumers keep later messages for later boundaries; all consumers inject the queued FIFO batch together. Codex receives messages collected during its quiet window as one batched turn/steer.
With /queue collect, OpenClaw does not steer. It waits until the active run ends, then creates a followup turn with compatible queued messages after the debounce window.
With /queue interrupt, OpenClaw aborts the active run and starts the newest message instead of steering.

Scope

Steering always targets the current active session run. It does not create a new session, change the active run's tool policy, or split messages by sender. In multi-user channels, inbound prompts already include sender and route context, so the next model call can see who sent each message.

Use followup or collect when you want messages to queue by default instead of steering the active run. Use interrupt when the newest prompt should replace the active run.

Debounce

The built-in queue debounce applies to queued followup and collect delivery. In steer mode with the native Codex harness, it also sets the quiet window before sending batched turn/steer. OpenClaw active steering does not use the debounce timer; at tool-launch and model boundaries it drains FIFO according to the runtime's configured steering drain mode.