[FEATURE]: Graceful handling of queued messages after session interrupt

[thoughtlesslabs]

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Problem

When a user sends multiple messages while an operation is in progress, the messages are queued. However, if the current operation is interrupted (aborted), the queued messages are silently rejected and lost rather than being processed. This creates a poor user experience, especially when iterating quickly with the AI assistant.

Current behavior:

current-queue-system.mp4

• User sends message A (starts processing)
• User sends message B while A is processing (queued)
• User interrupts message A
• Message B is silently discarded ❌

Expected behavior:

• User sends message A (starts processing)
• User sends message B while A is processing (queued)
• User interrupts message A
• Message B begins processing automatically ✅

Proposed Solution

This feature adds graceful queue handling with full visibility and control:

Screen.Recording.2025-12-10.at.1.47.19.PM.mov

1. Queue Persistence After Interrupts

Queued messages remain in the queue and are processed in order after an interrupt, rather than being rejected.

2. Cancel Individual Queued Messages

Users can remove specific messages from the queue via the message action dialog (click on a queued message to see the "Cancel" option).

3. Separated Queue Display

Queued messages are pinned in a dedicated section above the input prompt, visually separated from the scrolling conversation. A "Processing next task..." separator shows when tasks transition.

Implementation

A working implementation is available in the fork branch:

🔗 https://github.com/thoughtlesslabs/opencode/tree/feat/queued-message-interrupt

Key Changes

File	Description
packages/opencode/src/session/prompt.ts	Queue handling logic with loopId tracking to prevent race conditions, cancelQueued() and getQueuedMessageIds() functions
packages/opencode/src/cli/cmd/tui/routes/session/index.tsx	Visual queue separation with queuedMessages and activeMessages memos, pinned queue section
packages/opencode/src/cli/cmd/tui/routes/session/dialog-message.tsx	Cancel action for queued messages in the message dialog

Technical Details

• Added loopId tracking using ulid() to prevent race conditions when canceling/restarting loops
• Queue callbacks now include userMessageID for proper tracking
• processQueuedCallbacks() handles ordered queue processing after interrupts
• UI uses SolidJS reactive memos for efficient queue state management

Why It Belongs in OpenCode

1. Improves UX - User input is never silently discarded
2. Provides transparency - Users can see exactly what's queued and processing
3. Gives users control - Ability to cancel individual queued messages
4. Common workflow - Users frequently iterate quickly, sending follow-up messages before the AI finishes
5. No breaking changes - Backward compatible enhancement to existing behavior

---

This feature request follows the CONTRIBUTING.md guidelines for net-new functionality.

[github-actions]

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

• [FEATURE]: Add ability to unqueue messages #4821: Add ability to unqueue messages
• Queued message interrupts todolist execution #5135: Queued message interrupts todolist execution
• Bug: When aborting and sending a new message the agent ignores the new message and starts processing the previous user message. #2270: When aborting and sending a new message the agent ignores the new message and starts processing the previous user message
• Queued message not running #2246: Queued message not running
• Forgets queued messages #1476: Forgets queued messages

Feel free to ignore if none of these address your specific case.

[thoughtlesslabs]

I do understand that there are some other related issues raised, but i put this as a new one because it provides a comprehensive solution and I wanted to submit this is a feature request instead of a bug fix because it introduces updated ui/ux elements

[rekram1-node]

I see...

[thoughtlesslabs]

Hey @rekram1-node what would next steps be on this? Push as a pr?

[rekram1-node]

The proposal sounds a bit more complicated than what i'd expect but I havent looked into this particular issue enough.

It seems like there is prolly a simple fix so that a queued message would be persisted to disk