read_when:

- Explaining how steer behaves while an agent is using tools

- Changing active-run queue behavior or runtime steering integration

- Comparing steer, queue, collect, and followup modes

- Comparing steering with followup, collect, and interrupt queue modes

title: "Steering queue"

---

When a message arrives while a session run is already streaming, OpenClaw can

send that message into the active runtime instead of starting another run for

the same session. The public modes are runtime-neutral; Pi and the native Codex

app-server harness implement the delivery details differently.

When a normal prompt arrives while a session run is already streaming, OpenClaw

tries to send that prompt into the active runtime by default when the queue mode

is `steer`. No config entry and no queue directive are required for that default

behavior. Pi and the native Codex app-server harness implement the delivery

details differently.

## Runtime boundary

then lets the next model call see the latest user input.

The native Codex app-server harness exposes `turn/steer` instead of Pi's

internal steering queue. OpenClaw adapts the same modes there:

- `steer` batches queued messages for the configured quiet window, then sends a

single `turn/steer` request with all collected user input in arrival order.

- `queue` keeps the legacy serialized shape by sending separate `turn/steer`

requests.

- `followup`, `collect`, `steer-backlog`, and `interrupt` stay OpenClaw-owned

queue behavior around the active Codex turn.

internal steering queue. OpenClaw batches queued prompts for the configured

quiet window, then sends a single `turn/steer` request with all collected user

input in arrival order.

Codex review and manual compaction turns reject same-turn steering. When a

runtime cannot accept steering, OpenClaw falls back to the followup queue where

that mode allows it.

runtime cannot accept steering in `steer` mode, OpenClaw waits for the active

run to finish before starting the prompt.

This page explains queue-mode steering for normal inbound messages. For the

explicit `/steer <message>` command, see [Steer](/tools/steer).

This page explains queue-mode steering for normal inbound messages when the mode

is `steer`. If the mode is `followup` or `collect`, normal messages do not enter

this steering path; they wait until the active run finishes. For the explicit

`/steer <message>` command, see [Steer](/tools/steer).

## Modes

| Mode | Active-run behavior | Later followup behavior |

| --------------- | ---------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |

| `steer` | Injects all queued steering messages together at the next runtime boundary. This is the default. | Falls back to followup only when steering is unavailable. |

| `queue` | Legacy one-at-a-time steering. Pi injects one queued message per model boundary; Codex sends separate `turn/steer` requests. | Falls back to followup only when steering is unavailable. |

| `steer-backlog` | Same active-run steering behavior as `steer`. | Also keeps the same message for a later followup turn. |

| `followup` | Does not steer the current run. | Runs queued messages later. |

| `collect` | Does not steer the current run. | Coalesces compatible queued messages into one later turn after the debounce window. |

| `interrupt` | Aborts the active run, then starts the newest message. | None. |

| 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:

- `steer`: the active runtime receives all four messages in arrival order before

its next model decision. Pi drains them at the next model boundary; Codex

receives them as one batched `turn/steer`.

- `queue`: legacy serialized steering. Pi injects one queued message at a time;

Codex receives separate `turn/steer` requests.

- `collect`: OpenClaw waits until the active run ends, then creates a followup

turn with compatible queued messages after the debounce window.

- With default behavior, the active runtime receives all four messages in

arrival order before its next model decision. Pi drains them at the next model

boundary; Codex receives them 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

multi-user channels, inbound prompts already include sender and route context, so

the next model call can see who sent each message.

Use `collect` when you want OpenClaw to build a later followup turn that can

coalesce compatible messages and preserve followup queue drop policy. Use

`queue` only when you need the older one-at-a-time steering behavior.

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

`messages.queue.debounceMs` applies to followup delivery, including `collect`,

`followup`, `steer-backlog`, and `steer` fallback when active-run steering is not

available. For Pi, active `steer` itself does not use the debounce timer because

Pi naturally batches messages until the next model boundary. For the native

Codex harness, OpenClaw uses the same debounce value as the quiet window before

sending the batched `turn/steer`.

`messages.queue.debounceMs` 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`. For Pi, active steering itself does not use

the debounce timer because Pi naturally batches messages until the next model

boundary.

## Related