Repository navigation
[FEATURE]: inject queued messages into the next LLM call instead of interrupting the current task #16102
Description
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
Queued messages currently interrupt the running task. This causes several related issues:
- Messages lost after session interrupt ([FEATURE]: Graceful handling of queued messages after session interrupt #5333)
- Queued messages break todolist execution (Queued message interrupts todolist execution #5135)
- Users want delayed/non-interrupting queue ([FEATURE]: Delayed queue feature #5408)
The root cause: when a session is busy, SessionPrompt.assertNotBusy() throws BusyError. Queued messages either interrupt the task or wait until the session is fully idle. There's no mechanism to inject them as mid-task guidance.
Proposed solution
Drain queued messages at the start of each loop() iteration in prompt.ts and inject them as context before the next LLM.stream() call:
Current flow:
loop() → LLM.stream() → streaming → tool execution
→ user queues message → ❌ BusyError or task interrupts
Proposed flow:
loop() → [★ drain queue here] → LLM.stream() → streaming → tool execution
→ user queues message → next iteration picks it up → ✅ agent adjusts
Injection point — packages/opencode/src/session/prompt.ts, inside the loop() function's while(true), before LLM.stream() is called via SessionProcessor:
while (true) {
// ... existing message history loading ...
// ★ Inject queued messages here
if (queue.hasMessages()) {
const queued = queue.drainAll()
const injection = `\n[USER_MID_TASK_MESSAGE]\n${queued.map(m => m.text).join("\n")}\n[/USER_MID_TASK_MESSAGE]`
// append as user message content before LLM call
}
// ... existing SessionProcessor.create() + process() ...
}This approach:
- Zero overhead when no messages are queued
- Doesn't interrupt the running task
- Preserves existing Esc interrupt behavior
- Addresses [FEATURE]: Graceful handling of queued messages after session interrupt #5333, Queued message interrupts todolist execution #5135, [FEATURE]: Delayed queue feature #5408
Prior art
I've implemented this same pattern in Roo Code PR #11813 — 25 lines in their equivalent Task.ts, all tests passing. I can open a PR if there's interest.
Additional context
- Related issues: [FEATURE]: Graceful handling of queued messages after session interrupt #5333, Queued message interrupts todolist execution #5135, [FEATURE]: Delayed queue feature #5408
- Key files reviewed:
prompt.ts(loop),processor.ts(stream),session/index.ts(BusyError)
Activity
github-actions commentedon Mar 5, 2026
This issue might be a duplicate of existing issues. Please check:
The core idea in both issues is to inject queued user messages into the agent loop at a safe point (after a tool call / at the start of the next loop iteration) rather than interrupting or waiting for full completion. The proposed implementation differs in specifics, but the underlying feature request is essentially the same.
If you believe your issue covers something meaningfully different, please clarify in a comment so the maintainers can assess.
shdomi8599 commentedon Mar 5, 2026
Thanks for flagging! #5122 describes the same goal. My issue adds concrete implementation details — the exact injection point in prompt.ts, a code sketch, and a working reference implementation in Roo Code PR.
Happy to contribute this as a PR linked to either issue.
robclancy commentedon Mar 25, 2026
I used opencode for a month and this always annoyed me. Then I tried out claude code and this single change is the biggest reason I will keep using it. Currently rate limited so back for a bit but this change has instantly annoyed me again.
I also don't think it's similar to the mid stream updates.
feat: queue pending prompts when session is busy (anomalyco#16102)
shdomi8599 commentedon Mar 25, 2026
Thanks for sharing your experience! It's reassuring to know others feel the same friction.
And I agree with you — this isn't really the same as mid-stream updates. Mid-stream updates are about the AI reflecting live tool output during streaming, while this is about letting the user inject guidance between iterations without killing the whole task. The queue-drain approach I proposed specifically targets that gap.
Hopefully the maintainers can move on this — the demand seems pretty clear at this point, and the implementation footprint is genuinely small (the Roo Code version was ~25 lines).
github-actions commentedon Jul 5, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
robclancy commentedon Jul 8, 2026
god I hate auto closing bots, fuck off with this shit