[FEATURE]: Add a prompt queue and interrupt controls to the composer

[AndreLCanada]

Description

Currently, when a response is streaming, the only way to send a follow-up is to interrupt it. There is no way to queue a message for after the current turn, or to inject it into the current stream without stopping it.

I would like to add a behind-the-toggle "Prompt queue" feature that shows a per-message dropdown when the session is busy:

• Send now - interrupt the current response and send immediately.
• After current stream - inject the prompt into the current response without stopping it.
• After this turn - queue the message and send it when the session becomes idle.
• Sub-session - queue the message, then fork it into a new tab when idle.

This would also include a small dock for queued messages with drag-to-reorder and repository congruent tooltips and cycle hot key assignments.

The legacy general.followup setting is not exposed in the current UI and appears to be dead code, so this feature would replace it.

Working Example Found At

I have a working implementation in a branch at AndreLCanada/opencode/prompt-queue-controls if the team is interested in looking at the approach. Continuing to use the branch myself incase any edge cases remain.

Preview

[github-actions]

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

• [FEATURE]: Add messages to queue in the opencode app #36373: Add messages to queue in the opencode app — requests the same core queuing behavior
• [FEATURE]: Delayed queue feature #5408: Delayed queue feature — requests queuing prompts to send after the current run finishes
• [FEATURE]: Add ability to unqueue messages #4821: Add ability to unqueue messages — directly related; requests dequeuing queued messages
• [FEATURE]:Configurable mid-run prompt delivery: queue vs steer, with compaction-aware steer semantics #32157: Configurable mid-run prompt delivery: queue vs steer — covers the same queue/steer/interrupt taxonomy and semantics in detail

If your request is meaningfully different from the above, please clarify what distinguishes it.

[AndreLCanada]

In response to the Github-Actions above, this is far more feature rich and actually exposed in the new v2 desktop application.

[AndreLCanada]

Hey @Hona!

Let me know if there's any changes you'd like to make here to make it more acceptable. I have the feature ready to go on a local branch I am using.

I am interested in contributing to the desktop app on a more regular basis as I primarily use it and I know you all are focus on the TUI and headless experiences. Happy to take on a few tasks from the team now and again as well if needed. So open to any requests/suggestions/tips on how the team prefers os contributions to be handled.

Looking forward to contributing!