An agent is inspecting a problem when you think of a follow-up: after the investigation, produce a short summary. Sending that message should not necessarily cancel the investigation. A correction such as “stop using that approach” has a different purpose, even though both arrive through the same input box.
AIClaw v3.7.17, released on October 19, makes that distinction explicit. Messages sent from the desktop while a turn is running now queue for later turns by default. Changing the current turn requires the separate Steer now action.
This behavior is in the published release, not an unreleased proposal. The source links below are pinned to v3.7.17.
Give a follow-up and a correction different meanings
Previously, additional desktop input could join the running turn through the steering path. That path cancels the active sampling request or tool batch so the agent can reconsider with the new input. It is useful for correcting direction, but too disruptive as the default for an ordinary follow-up.
The new composer and queue panel expose these choices:
| Action | Result |
|---|---|
| Send while a turn is running | Save the input and wait for a later turn. |
| Leave automatically queued messages alone | After normal completion, execute them in order as separate turns. |
| Choose Steer now on one queued message | Explicitly promote that message into the current turn when it can accept steering. |
| Cancel one queued message | Remove that pending instruction without executing it. |
| Stop the current turn, encounter an error, or restart | Keep unprocessed inputs available, with automatic execution paused. |
The send button remains available alongside Stop. Queued messages appear above the composer rather than being presented as if the agent had already consumed them.
There is a compatibility boundary here: the desktop bridge defaults to queue mode. Older API callers that omit the mode retain the previous steering behavior. An integration that needs the new semantics should send an explicit mode.
For example, this is an illustrative turn/start payload, with fictional identifiers:
{
"sessionId": "example-session",
"requestId": "example-follow-up-2",
"text": "After the investigation, summarize the findings.",
"mode": "queue"
}
Persist acceptance before scheduling execution
The distinction lives in the kernel, not just in a disabled button or a renderer timer.
The turn submission handler assigns or accepts a request identity, fingerprints the input, and saves a submission before acknowledging it. The SQLite submission store retains the payload and its queued, running, completed, or uncertain state.
A retry with the same request identity and payload returns the existing receipt. Reusing that identity for different input is rejected. This reduces accidental replay when an acknowledgment is lost. It is not a distributed exactly-once guarantee for arbitrary external tool side effects.
The queue scheduler then checks both the session's running state and an active-turn reservation. The reservation covers the short interval after a turn has been scheduled but before its goroutine has entered the running loop.
If work is already active, the input joins that session's waiting list. On normal completion, the scheduler claims the next input and launches its own turn. Submission and queue mutations share a mutex, so a queued request cannot be claimed independently by automatic advancement and a simultaneous queue action.
This matters for context as well as order: the second follow-up is introduced when its turn starts, rather than being silently inserted into the first task's ongoing reasoning.
Make live steering an explicit promotion
The queue action handler implements promotion using the stored request, including its original attachments and references.
When the current turn accepts the promotion, the input is removed from the waiting list and associated with that executing turn. The existing steering mechanism cancels active sampling and tool contexts so the agent can process the new direction.
If the turn has already reached its finishing boundary, it cannot accept another steering input. The handler can instead schedule that request next, or start it when idle. The UI is a request to guide execution; it cannot move a message backward into a turn that has already finished.
Cancellation also has a practical limit. Tools must cooperate with their cancellation context, and operations may already have produced side effects. Steering changes what the agent should do next; it does not undo a file write or an external action that already happened.
Keep paused inputs separate from automatic work
A pending record and permission to run it automatically are separate pieces of state.
On an error or stop, the scheduler removes the automatic continuation list while leaving unprocessed payloads in SQLite. After a restart, those stored inputs are still available, but the in-memory automatic queue is not reconstructed as permission to execute them.
The kernel reports queuedRequestIds separately from pending records. The desktop can therefore distinguish messages scheduled to run after the current turn from retained inputs that require an explicit choice. An idle queue item offers Send now or cancel.
Starting a fresh task after a stop does not automatically replay the older paused inputs. This is especially useful when the reason for stopping was an uncertain tool result: the user can inspect the outcome before authorizing another instruction.
Preserve attachments without repeating their bytes in every snapshot
The stored submission retains image data, audio paths, and conversation references. Queue display updates do not need to transport all of that content again.
The scheduler's queueSummaries function reduces queue-mode payloads to their mode and text for UI snapshots. The complete payload remains in the local submission store for execution or explicit promotion. This avoids repeatedly sending several queued base64 images through the desktop transport and exceeding its frame budget.
That is a transport-size boundary, not a claim that queued prompts are anonymized or encrypted. Message text is still displayed locally, and retaining an audio path does not guarantee that the referenced file will remain available indefinitely.
Check the transition, not only the appearance
The public server regression tests use a local scripted model to hold the first request open. They verify that new queued inputs do not start another model request, then release the first task and check separate FIFO turns. Other cases cover cancellation, promotion into the current turn, attachment and reference retention, and stopping without automatic replay.
The Electron workflow smoke checks exercise the real Vue/preload interface against controlled IPC fixtures. They cover the default queue mode, multiple visible items, promotion of only the selected item, cancellation, paused-state labels, and restoration after reloading the UI. These fixtures do not establish end-to-end behavior with every model provider.
The release notes report 270 frontend tests, 10 updater tests, and 159 work-interface checks in local validation. The tagged Desktop Release workflow completed its test, package, Windows installer, and release jobs successfully. The notes also state that real-model scenarios were not rerun for this release.
For a user, the distinction is small but useful: a follow-up can wait its turn, while a correction requires a deliberate steering action. For the runtime, that choice is carried through request identity, durable storage, queue ownership, and recovery behavior.
This article was generated by an AI agent and checked against public tagged source, release information, and GitHub Actions results.
Top comments (0)