Affected area
Agent sessions / streaming
Version or commit
main@62959218
Environment
OS: Windows desktop application (version not recorded)
Deployment: desktop app
Model provider: Custom OpenAI Responses-compatible provider
The issue is not limited to a permanent network outage. It can also occur when a provider stream accepts a request but does not emit an event or close, or when a local memory/index IPC operation remains pending.
Steps to reproduce
- Start a desktop chat conversation and send a message.
- While the conversation is waiting in the
Vibing... state, click Stop.
- Type a follow-up message while the previous turn is stopping or still appears active.
- Try to send the follow-up message.
For a deterministic reproduction, use a Responses-compatible proxy that accepts the request but keeps the stream open without emitting events or closing it. An equivalent local reproduction is to keep the memory/index overview operation pending before the provider runtime starts.
Expected behavior
Stop should promptly release the active conversation from the running state, even when a local pre-runtime operation or provider stream is pending.
After stopping, the user should be able to send a new message or add it to the queue. The Stop action should remain available while a follow-up draft is being composed.
A late completion, failure, or cleanup callback from the cancelled turn must not change the state of a newer turn.
Network recovery should not require reloading the application window before the conversation becomes usable again.
Actual behavior
The conversation can remain stuck in Vibing... after Stop.
The input may remain unavailable or the follow-up message may not visibly enter the queue. In some cases, typing a draft changes the primary action and the red Stop action is no longer available, so the user cannot issue a second force-stop.
The issue may recover after waiting for an indeterminate amount of time. If the provider stream or a local operation never settles, the conversation can remain stuck until the window is reloaded.
A network disconnect can also leave the conversation unusable after connectivity returns, requiring an application reload.
Logs / screenshots
No reliable user-facing error is shown when this happens. The visible symptom is a conversation that remains in Vibing... after Stop while subsequent input cannot proceed.
Attach a screenshot showing the stuck Vibing... state and the follow-up draft if available.
Remove provider API keys, access tokens, authorization headers, request payload secrets, and private conversation content before attaching logs or screenshots.
Pre-submit checklist
Affected area
Agent sessions / streaming
Version or commit
main@62959218
Environment
OS: Windows desktop application (version not recorded)
Deployment: desktop app
Model provider: Custom OpenAI Responses-compatible provider
The issue is not limited to a permanent network outage. It can also occur when a provider stream accepts a request but does not emit an event or close, or when a local memory/index IPC operation remains pending.
Steps to reproduce
Vibing...state, clickStop.For a deterministic reproduction, use a Responses-compatible proxy that accepts the request but keeps the stream open without emitting events or closing it. An equivalent local reproduction is to keep the memory/index overview operation pending before the provider runtime starts.
Expected behavior
Stopshould promptly release the active conversation from the running state, even when a local pre-runtime operation or provider stream is pending.After stopping, the user should be able to send a new message or add it to the queue. The
Stopaction should remain available while a follow-up draft is being composed.A late completion, failure, or cleanup callback from the cancelled turn must not change the state of a newer turn.
Network recovery should not require reloading the application window before the conversation becomes usable again.
Actual behavior
The conversation can remain stuck in
Vibing...afterStop.The input may remain unavailable or the follow-up message may not visibly enter the queue. In some cases, typing a draft changes the primary action and the red
Stopaction is no longer available, so the user cannot issue a second force-stop.The issue may recover after waiting for an indeterminate amount of time. If the provider stream or a local operation never settles, the conversation can remain stuck until the window is reloaded.
A network disconnect can also leave the conversation unusable after connectivity returns, requiring an application reload.
Logs / screenshots
No reliable user-facing error is shown when this happens. The visible symptom is a conversation that remains in
Vibing...afterStopwhile subsequent input cannot proceed.Attach a screenshot showing the stuck
Vibing...state and the follow-up draft if available.Remove provider API keys, access tokens, authorization headers, request payload secrets, and private conversation content before attaching logs or screenshots.
Pre-submit checklist