[FEATURE]: Web UI has no way to queue follow-up messages — steer-only since queue setting was removed

[chaosmanage]

Summary

On OpenCode Web (opencode web), sending a message while the agent is busy always steers it into the active turn. There is no option to queue the message as the next normal turn after the current run finishes. The previous General → Follow-up Message Behavior (Queue/Steer) setting is gone from the web UI.

Environment

• OpenCode version: 1.18.21
• Interface: Web (opencode web)
• OS: Linux

Steps to reproduce

1. Run opencode web, open a session
2. Send a long-running prompt
3. While the agent is busy, type another message and send
4. Observe: there is no Queue/Steer choice anywhere in the composer; the message is steered into the current run immediately

Expected behavior

A way to deliver a busy-session follow-up as a queued next turn (FIFO) that runs after the current run finishes — without interrupting or redirecting the active run. This matches the semantics the V2 session runner already specifies (specs/v2/session.md): steer inputs promote at the next safe provider-turn boundary, queue inputs stay FIFO and are promoted only when the session would otherwise go idle.

Actual behavior

Steer-only. Even queue-like behavior behaves as "wait & steer" — injected at a safe boundary inside the current turn — never as an independent next turn.

Context

• The Queue/Steer setting was intentionally removed in commit ae7e2eb (Apr 2026), apparently pending a proper reimplementation
• Restore attempts were closed unmerged: fix(app): restore queued follow-up setting #29110, fix(app): restore queued follow-up setting #29265
• A comprehensive fix (true final-token Queue + edit/cancel + wrap/halt-steer) is pending in feat: Add queued message editing, wrap & steer, and halt & steer #33247
• The V2 backend already models both delivery modes server-side (GET /session/{id}/pending, POST /session/{id}/pending/{inputID}/queue) — the gap is purely web-composer exposure

Requested solution

Expose a Queue option in the web composer for busy sessions (per-message override plus a default in settings), backed by the existing V2 delivery: "queue" support.

Verification

☑ I have searched existing issues and believe this specific gap (no queue option at all in the current web UI) is worth tracking alongside:

#5408 #6942 #8685 #12707 #16102 #18713 #20245 #21445 #22284 #24580 #32157

[chaosmanage]

Opened a minimal fix: #44117 — restores the General → Follow-up behavior (Queue/Steer) setting and un-blocks the queue machinery that already exists in packages/app (queue store, flush-when-idle, dock). It reverts the coercion introduced in ae7e2eb and adds the missing row to the v2 settings tab. Broader per-message modes remain covered by #33247.

[chaosmanage]

Update: a minimal fix is up for review in #44117 (restores the Follow-up behavior Queue/Steer setting disabled in ae7e2eb; the queue machinery itself still ships and works). If this affects you, a 👍 on the PR helps it survive the automated cleanup bot and reach a maintainer faster.

[Chunai-Bboy]

Opened a source-level PR for this: #52428

It restores the setting rather than hard-wiring a mode: it drops the three queue -> steer coercions in packages/app/src/context/settings.tsx (back to the pre-ae7e2eb shape) and puts the Queue/Steer row back into both settings dialogs. Default stays steer, so nothing changes unless you pick Queue.

The queued-messages dock strings (session.followupDock.*) are still in every locale, so no i18n work is needed.