[Feature]: Queue follow-up messages while the agent is running

[RoshanMhatre]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web

Problem or use case

While the agent is running a turn, the composer is effectively locked: Enter-to-send is disabled and the send button is replaced by stop, so the only options are to interrupt or to sit and wait for the run to settle. If I notice a follow-up mid-turn ("also rename the store", "then run the tests"), I have to either kill useful in-flight work or hold the thought in my head and hope I remember it when the run finishes. Related: #4550 and #231 both touch this, but bundle it with a to-do list / steer modes / settings; this issue proposes only the minimal queue.

Proposed solution

Let the composer accept messages during an active run and queue them; drain the queue in order when the run settles.

• While a run is active, Enter enqueues instead of sending. The send button swaps to a "queue" glyph and the footer hints "Enter to queue".
• Queued messages render as a compact stack docked above the composer: one line each, ordered, with hover actions to edit, remove, or send-now (interrupt).
• When the turn settles, the first queued message is dispatched automatically as the next user message; remaining items stay queued for subsequent turns.
• Queued messages survive reload/reconnect (they are user input, losing them is data loss).
• Edge cases worth deciding up front: interaction with pending user-input questions (see [Bug]: Queued prompts seem to interact badly with questions #4673 — a queued message should not be consumed as the answer to an AskUser prompt), and behavior when the run ends in an error state (keep the queue paused rather than auto-sending into a broken session).

Cursor's queued-messages stack and Codex's queue-on-enter are the reference UX here — both are small, quiet UIs attached to the composer, not a new surface.

Why this matters

This is the standard workflow in comparable agent frontends (Cursor, Codex, Claude Code): users think ahead while the agent works, especially on long turns, and queueing means stepping away doesn't stall the thread. It also removes the most common reason for interrupting a healthy run.

Smallest useful scope

Queue-on-Enter while a run is active + a visible queued stack above the composer with remove, + auto-dispatch of the queue head when the run settles, persisted server-side. Reordering, inline edit, send-now/interrupt, and any steer mode can all come later.

Alternatives considered

• Steer/inject into the live turn (feat: add Steer and Queue follow-up modes alongside Chat/Plan #231): valuable but a different, riskier mechanism; queueing alone covers the "don't lose my follow-up" need.
• Client-only queue (compose box buffer): loses messages on reload and does nothing on mobile background ([Bug]: Mobile: message queued while agent is working is never sent if the app goes to background — only delivered on next app open #5436 shows why server-side matters).

Risks or tradeoffs

• Auto-dispatch needs a clear definition of "settled" so queued messages don't fire into approval prompts or AskUser questions ([Bug]: Queued prompts seem to interact badly with questions #4673).
• Queue UI competes for the space above the composer with existing banners (pending approvals, plan follow-up); needs a stacking order decision.

Examples or references

• Cursor: queued messages stack above the input with edit/remove/send-now.
• OpenAI Codex: Enter queues while a turn is active; queue drains on settle.
• Related issues: [Feature]: To-Do List & Queue/Steer Messages #4550, feat: add Steer and Queue follow-up modes alongside Chat/Plan #231, [Bug]: Queued prompts seem to interact badly with questions #4673, [Bug]: Mobile: message queued while agent is working is never sent if the app goes to background — only delivered on next app open #5436.

Contribution

• I would be open to helping implement this.