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?)
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?)