Repository navigation
Feature: Mid-stream context injection at natural breaks (like Claude Code) #5122
Closed as not planned
Description
Feature Request
Current Behavior
When typing while the AI is responding, messages are queued and only processed after the current response completes. This means if I remember something important mid-response, I have to wait for completion or cancel entirely.
Desired Behavior
Allow queued user input to be injected at natural breaks during response generation, similar to how Claude Code handles this:
- User types new input while AI is responding
- System detects a "natural break" (after tool result, end of text block, between reasoning steps)
- User's new input is appended to the conversation context
- AI continues but now sees the new info and can incorporate it
Why This Matters
- Sometimes you forget context and remember mid-response
- Canceling loses progress and costs tokens
- Current queue waits until completion, missing the chance to influence the current response
Implementation Notes
The agent loop would need to:
- Check for pending queued input at safe breakpoints (after tool calls complete, after text blocks)
- If input exists, append it to the conversation before continuing
- Let the model naturally incorporate the new context in its next step
This is different from interrupt (which breaks tool_use/tool_result pairing) - it's a graceful context merge at safe points.
Reference
Claude Code does this - you can type mid-response and it finds a natural break to pop in your new message before continuing.
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Dec 5, 2025
This issue might be a duplicate of existing issues. Please check:
Feel free to ignore if none of these address your specific case.
will-marella commentedon Dec 5, 2025
I think that would be pretty neat. I'm gonna take a look and see what might be feasible
will-marella commentedon Dec 5, 2025
It's very feasible. Working on implementing this.
will-marella commentedon Dec 6, 2025
I was experiencing this earlier but can't reproduce now. It seems to be working fine. Anyone else still seeing it?
henry701 commentedon Jan 12, 2026
Anyone looking at this yet? Main blocker from moving from Cursor to OpenCode.
sudoxreboot commentedon Feb 28, 2026
im actually curious too, did this get implemented?
will-marella commentedon Feb 28, 2026
I had written an implementation for this, but I ended up deciding that the current behavior works pretty well already. Have you tested it recently? What do you see as the limitations?
diogovalada commentedon Apr 4, 2026
Chiming in here because while I completely agree with the need for mid-execution steering without breaking tool-call loops, I think we need to be careful about blindly copying the Claude Code approach.
If we just change the default queue behavior to inject at the next natural break, we are going to introduce a major regression in how users queue deferred tasks.
Instead, I propose we look at how Codex handles this via a Dual-Queue System.
The Problem with a Single "Claude-Style" Queue
The OP mentioned Claude Code's approach: type mid-response, and the system finds a natural break (like a tool execution finishing) to pop the new message into context.
While this is great for course-correction, it destroys the ability to park a thought. If the agent is on step 2 of a complex 10-step refactor and I realize, "Oh, please also update the README when you finish," injecting that at step 3 is disastrous. The LLM gets distracted, drops the refactor halfway through, and starts writing documentation.
The Solution: A Dual-Queue Implementation
We shouldn't have to choose between rigid post-task queuing (OpenCode's current state) and distraction-prone mid-task injection (Claude's state). We need both, tied to explicit user intents.
I propose implementing two distinct queue behaviors:
Enter) → Post-Task QueuingCtrl+Enter/Cmd+Enter) → Boundary-Aware InjectionEscand waste tokens.Why this is better
This gives the user explicit control over the context window. It differentiates between "Here is your next task" and "Wait, you're doing this current task wrong." It solves the exact pain point mentioned in this issue (saving tokens and preserving tool-use/tool-result pairs safely), but preserves the ability to batch commands and walk away without the LLM context-switching prematurely.
Would love to hear the maintainers' thoughts on splitting the queue logic this way!
github-actions commentedon Jul 3, 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.