[Bug] Desktop (Mac): sending a follow-up while a turn is running interrupts it, queued follow-ups are unreachable

[bunnysayzz]

Description

On the Mac desktop app, sending a message while the agent is still working on the previous one interrupts the running turn. There is no queue: the follow-up steals the turn instead of waiting behind it, so the first task never finishes.

I traced it to the app code (current dev). Queued follow-ups were removed in ae7e2eb3f (chore(app): remove queued follow-ups for now, Apr 3) and every path back to them is now hard-wired shut in packages/app/src/context/settings.tsx:

• the migration effect coerces any stored "queue" to "steer" (L353-356),
• the followup getter maps "queue" to "steer" (L372-375),
• setFollowup maps "queue" to "steer" on write (L376-378),
• the default is "steer" (L187), and the same commit removed the mode toggle from the settings UI (settings-general.tsx).

So settings.general.followup() can never be "queue", which makes queueEnabled in packages/app/src/pages/session.tsx (L1754-1758) permanently false. The shouldQueue branch in packages/app/src/components/prompt-input/submit.ts (L482) is therefore dead code: onQueue/queueFollowup and the follow-up dock never fire, and the message goes down the normal submit path while a turn is in flight (which aborts/steers it, cf. L334). All the queue machinery is still in the tree, just unreachable.

OpenCode version

Desktop Mac app, server 1.18.25

Steps to reproduce

1. In the Mac desktop app, send a prompt that starts a long-running task.
2. While the turn is still running, send a follow-up message.
3. The running turn is interrupted/steered instead of the follow-up being queued behind it. The first task never completes.

Expected

Either the follow-up is queued behind the running turn (the old followup: queue behavior), or the composer clearly offers queue-vs-interrupt so sending mid-turn does not silently kill the running work.

Related

• [FEATURE]: Web UI has no way to queue follow-up messages — steer-only since queue setting was removed #44108 (web UI has no way to queue follow-ups, steer-only since the queue setting was removed)
• [FEATURE]: Add a prompt queue and interrupt controls to the composer #37381 (prompt queue and interrupt controls for the composer)
• [FEATURE]: (Desktop Beta) add a visual indicator if the message is queued or not in the desktop app, and the right side menu, i wanna see how much tokens i used in detail rather than a circular indicator #44716 (desktop: visual indicator for queued messages)
• Queued prompt getting send before previous gets completed #46235 (queued prompt sent before previous completes, Windows/Git Bash client)

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Queued messages are silently dropped when a turn is interrupted #40955: Queued messages are silently dropped when a turn is interrupted — same root area (queue machinery unreachable after an abort/interrupt), very similar symptoms
• prompt_async into a tool-executing turn aborts it and strands the new prompt #48175: prompt_async into a tool-executing turn aborts it and strands the new prompt — same race condition between an in-flight turn and a follow-up prompt

[bunnysayzz]

Not a duplicate of either, as far as I can tell. #40955 and #48175 are both about the queue misbehaving when it exists (messages dropped on interrupt, prompt_async racing a tool call). This one is a level below that: in the app client the queue cannot exist at all. settings.general.followup() is coerced to "steer" in three places (settings.tsx L353-356, L372-375, L376-378), so queueEnabled in session.tsx is permanently false and the shouldQueue branch in submit.ts is dead code. Fixing those two would not fix this; restoring the queue path would. Happy to close this in favor of #44108 if maintainers prefer one tracking issue for the app-side queue removal, though.

[Chunai-Bboy]

Opened a PR for this: #52428

Same root cause you traced: the general.followup coercions in packages/app/src/context/settings.tsx. The PR removes them and restores the Queue/Steer row in both settings dialogs, so shouldQueue / onQueue in pages/session.tsx can be reached again.

Default remains steer; picking Queue is opt-in.