Repository navigation
[Bug] Desktop (Mac): sending a follow-up while a turn is running interrupts it, queued follow-ups are unreachable #48203
Description
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
followupgetter maps"queue"to"steer"(L372-375), setFollowupmaps"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
- In the Mac desktop app, send a prompt that starts a long-running task.
- While the turn is still running, send a follow-up message.
- 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)
Activity
github-actions commentedon Sep 9, 2026
This issue might be a duplicate of existing issues. Please check:
prompt_asyncinto a tool-executing turn aborts it and strands the new prompt — same race condition between an in-flight turn and a follow-up promptbunnysayzz commentedon Sep 9, 2026
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.tsxL353-356, L372-375, L376-378), soqueueEnabledinsession.tsxis permanently false and theshouldQueuebranch insubmit.tsis 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.fix(app): restore queued follow-up (Queue/Steer) setting
Chunai-Bboy commentedon Oct 1, 2026
Opened a PR for this: #52428
Same root cause you traced: the
general.followupcoercions inpackages/app/src/context/settings.tsx. The PR removes them and restores the Queue/Steer row in both settings dialogs, soshouldQueue/onQueueinpages/session.tsxcan be reached again.Default remains
steer; picking Queue is opt-in.neriousy commentedon Oct 19, 2026
This is fixed in v2: Settings → General offers Queue and Steer for follow-up messages, and choosing Queue sends follow-ups as queued prompts rather than steering the running task. Update the desktop app to v2 to use it. If you still see this on v2, please open a new issue with the details.