Queue and steer messages while a session is running #122

Problem

The chat composer cannot usefully accept another message while a session is running. I have to wait for the agent to finish before sending anything else.

This blocks two distinct workflows:

• I want to batch several independent messages and let the agent handle them in order.
• I notice missing context or a wrong direction and want the agent to see my correction between its steps, without cancelling its current work.

Cancel and resend is not an adequate substitute. It discards progress, wastes model usage, and can leave tool work partially completed.

Desired behavior

Keep the composer enabled while the session is running and support two explicit delivery modes.

Queue

Use this for a complete follow-up task such as "After this, update the README."

• Persist the message as pending work.
• Do not expose it to the active run.
• Deliver queued messages as normal user turns after the current run finishes.
• Preserve FIFO ordering when several messages are queued.
• Show accepted queued messages in the chat immediately with a clear pending state.

Steer

Use this for a correction or constraint on the active task such as "Use the v2 API, not v1."

• Persist the message against the active run.
• Inject it at the next safe boundary, such as after the current tool call and before the next model call.
• Do not cancel completed work or break tool-call and tool-result pairing.
• Show when the message has been accepted and when it has been delivered to the active run.

The UI should make the distinction clear at submission time. A default action plus a keyboard-modified alternative would be sufficient, provided both actions are discoverable.

Acceptance criteria

• The composer remains usable while a session is processing.
• A user can submit a message as either queue or steer.
• Queued messages run in FIFO order only after the active run completes.
• Steer messages reach the active agent at the next safe step boundary.
• Neither mode silently discards a submitted message.
• Pending messages and their delivery mode are visible in the chat.
• Failures leave the message visible with a retryable error state.
• Refreshing or reconnecting does not lose accepted pending messages.

Related work

• OpenCode #32157 tracks explicit queue, steer, and break semantics.
• OpenCode #37381 tracks prompt queue and interrupt controls in its composer.
• OpenCode #5122 describes Claude Code-style injection at natural breaks.
• This repository's Fail prompts that never receive a sandbox connection #15 concerns messages sent before sandbox connection and is a separate failure mode.