You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[FEATURE]: Web UI has no way to queue follow-up messages — steer-only since queue setting was removed #44108
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
Run opencode web, open a session
Send a long-running prompt
While the agent is busy, type another message and send
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
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:
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.
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.
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.
V2 has a Follow-up behavior setting under Settings > Preferences with Queue and Steer options. While the agent is busy, the composer also shows the other option as a button (Ctrl/Cmd+Enter), so you can queue or steer a single message, and queued messages wait until the current work finishes. To get v2: npm i -g @opencode/cli@latest or curl -fsSL https://opencode.ai/v2/install | bash (desktop: update the app). If you still see this on v2, please open a new issue with the details.
Activity
chaosmanage commentedon Aug 22, 2026
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 commentedon Aug 22, 2026
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.
fix(app): restore queued follow-up (Queue/Steer) setting
Chunai-Bboy commentedon Oct 1, 2026
Opened a source-level PR for this: #52428
It restores the setting rather than hard-wiring a mode: it drops the three
queue->steercoercions inpackages/app/src/context/settings.tsx(back to the pre-ae7e2ebshape) and puts the Queue/Steer row back into both settings dialogs. Default stayssteer, 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.neriousy commentedon Oct 19, 2026
V2 has a Follow-up behavior setting under Settings > Preferences with Queue and Steer options. While the agent is busy, the composer also shows the other option as a button (Ctrl/Cmd+Enter), so you can queue or steer a single message, and queued messages wait until the current work finishes. To get v2:
npm i -g @opencode/cli@latestorcurl -fsSL https://opencode.ai/v2/install | bash(desktop: update the app). If you still see this on v2, please open a new issue with the details.