anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 10:15:31 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Queued message not running #1489

New Issue
Closed
opened 2026-02-16 17:31:14 -05:00 by yindo · 3 comments
yindo commented 2026-02-16 17:31:14 -05:00
Owner
Copy Link
Copy Source

Originally created by @garrett-hopper on GitHub (Aug 25, 2025).

Originally assigned to: @thdxr on GitHub.

Note: I don't have a clean reproduction of this yet unfortunately. (Will update this if I can find more details about when it occurs or even exact steps to reproduce.)

I've run into several instances where I'll send a message which will be queued and then just sit there, despite there not being any outstanding LLM responses being waited for. (No "working..." status in bottom-left, just "enter send")
Usually I'll just say "go" and it will proceed, the old previous queued message turning from green to purple along with the new "go" message.
Occasionally, both will appear purple but only the "go" message will appear to be sent to the LLM. (It will be confused about what I'm asking it to "go" for.) Often to prevent this, I'll Ctrl+P to re-send the exact same command again which works fine usually.

I'm using Claude Sonnet 4 if that's relevant. (Haven't tested other models to see if the behavior happens for them as well.)

I think it's fair to say that the "queued" message along with non-active state should not occur? (Or perhaps there's some functionality I'm not aware of that would warrant the user having to confirm sending queued messages after reviewing the response?)

Originally created by @garrett-hopper on GitHub (Aug 25, 2025). Originally assigned to: @thdxr on GitHub. Note: I don't have a clean reproduction of this yet unfortunately. (Will update this if I can find more details about when it occurs or even exact steps to reproduce.) I've run into several instances where I'll send a message which will be queued and then just sit there, despite there not being any outstanding LLM responses being waited for. (No "working..." status in bottom-left, just "enter send") Usually I'll just say "go" and it will proceed, the old previous queued message turning from green to purple along with the new "go" message. Occasionally, both will appear purple but only the "go" message will appear to be sent to the LLM. (It will be confused about what I'm asking it to "go" for.) Often to prevent this, I'll Ctrl+P to re-send the exact same command again which works fine usually. I'm using Claude Sonnet 4 if that's relevant. (Haven't tested other models to see if the behavior happens for them as well.) I think it's fair to say that the "queued" message along with non-active state should not occur? (Or perhaps there's some functionality I'm not aware of that would warrant the user having to confirm sending queued messages after reviewing the response?)
yindo closed this issue 2026-02-16 17:31:14 -05:00
yindo commented 2026-02-16 17:31:14 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Aug 25, 2025):

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

  • #1476: Forgets queued messages - Similar issue where queued messages during tasks seem to be forgotten after task completion, with messages being ignored after certain operations
  • #2137: Message generation interrupted, stuck at Generating - Similar hanging/stuck behavior where messages get interrupted or stuck in generating state despite no active LLM responses
  • #1418: working getting stuck and double esc not exiting - Similar issue where opencode gets stuck and becomes unresponsive, requiring manual intervention like saying "go" to proceed
  • #232: Session simply stalls - Messages just sit there without processing, similar to the "queued but not running" behavior described

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

@github-actions[bot] commented on GitHub (Aug 25, 2025): This issue might be a duplicate of existing issues. Please check: - #1476: Forgets queued messages - Similar issue where queued messages during tasks seem to be forgotten after task completion, with messages being ignored after certain operations - #2137: Message generation interrupted, stuck at `Generating` - Similar hanging/stuck behavior where messages get interrupted or stuck in generating state despite no active LLM responses - #1418: working getting stuck and double esc not exiting - Similar issue where opencode gets stuck and becomes unresponsive, requiring manual intervention like saying "go" to proceed - #232: Session simply stalls - Messages just sit there without processing, similar to the "queued but not running" behavior described Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:31:14 -05:00
Author
Owner
Copy Link
Copy Source

@arsham commented on GitHub (Aug 25, 2025):

I have observed this as well. Sometimes it actually works on the first queued message but on the second one. I often have to re-send the last message to be processed.

@arsham commented on GitHub (Aug 25, 2025): I have observed this as well. Sometimes it actually works on the first queued message but on the second one. I often have to re-send the last message to be processed.
yindo commented 2026-02-16 17:31:14 -05:00
Author
Owner
Copy Link
Copy Source

@thdxr commented on GitHub (Sep 18, 2025):

this should be fixed now

@thdxr commented on GitHub (Sep 18, 2025): this should be fixed now
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#1489
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?