Repository navigation
Windows app: conversations appear hung after agent completion; replies surface only after reopening / Could not load messages #49062
Description
Summary
Windows desktop conversations intermittently appear hung, looping, or unresponsive while the underlying agent has apparently completed its response. The completed answer does not appear in the visible conversation. Closing and reopening the conversation can reveal a completed response or an agent saying it had finished and was waiting for the user.
Brent reports this across Chat conversations, Work-side tasks, and Codex agents, including a hang while attempting to submit this bug report. Please triage the Codex desktop manifestation here and route any shared Chat/Work failure to its engineering owner.
Version and environment
- Windows desktop app; last verified version in this reporting session: 26.924.2738.0 (not freshly reconfirmed for this occurrence).
- Windows 10.0.26200.0, x64, from the earlier environment check.
- ChatGPT Pro, $200/month, user-reported.
- Supplied screenshot shows GPT-6 Astra Medium and Full access.
Steps / observed sequence
- Open a conversation and submit a normal prompt.
- The conversation intermittently appears to remain active, hang, or loop without displaying a usable final response.
- Wait; the visible screen still does not expose the completed result, so the user cannot reliably tell whether work is running or complete.
- Close and reopen the conversation.
- The conversation can then show that the agent finished and was awaiting the user's reply, despite that completion never having appeared on screen before reopening.
Frequency: recurring/intermittent, reported in multiple conversations and surfaces; no claim that every prompt triggers it.
Direct screenshot evidence
The supplied screenshot shows a completed-looking response region beneath 'Worked for 23s', followed by an error banner reading exactly 'Couldn't load messages' and a 'Retry' button above the composer. This directly documents a message-loading failure. The wider hang/reopen sequence above is the user's account, not something the single screenshot alone proves. The screenshot contains private work details and is not attached publicly; the relevant UI evidence is transcribed here.
Expected behavior
Completed responses must reliably appear in the active conversation. The displayed running/completed state must agree with actual execution. Recovery from a connection or loading failure should preserve messages and restore the conversation without requiring repeated close/reopen cycles. An actionable error should replace an indefinite apparent hang.
Business impact and escalation request
This is a serious recurring reliability defect, not a cosmetic annoyance. It disrupts business work, hides deliverables, makes users wait on work that has already finished, and forces repeated recovery actions just to communicate with their agents. It creates uncertainty about whether to wait, retry, or repeat instructions, increasing the risk of duplicate work.
The user strongly objects to having to repeatedly close and reopen conversations to discover whether paid work is finished. This level of interruption is unacceptable for a business workflow. Please assign an engineering owner, investigate response delivery/rendering and execution-state synchronization, provide a concrete recovery path, and track a verified fix rather than treating this as routine user troubleshooting.
Related report
#49027 concerns answered prompts remaining in the queue and blocking later prompts. This report concerns missing completion visibility/apparent hangs and message-loading errors. They may share a cause, but that is not established. Please cross-link without losing the distinct reproduction symptoms.
Activity
github-actions commentedon Sep 28, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
tomhda commentedon Oct 2, 2026
Same symptom here on Windows (26.928.40906 and 26.930.21537). I traced it to the host→window channel: the desktop log shows each reply routed to the window (
response_routed ... targetDestroyed=false), but the window receives nothing until a reload or reopen. A likely cause is the main process's chunked sender. Messages over 4 MiB are sent in parts, and each part waits for the renderer's acknowledgement with no time limit. Meanwhile every other message to that window waits behind it, so one missing acknowledgement hides all later progress and completions. Details and measurements: #50203drewclifton commentedon Oct 8, 2026
Cross-linking a related macOS report: #52204 documents ordinary Chat mode intermittently omitting the entire final response below a correctly rendered
Worked foractivity section, even though the sidebar previews the answer. On macOS app 26.1002.52244, File → New Window then reopening the conversation restores the response without restarting the app. This resembles the missing-completion visibility in this Windows report, but noCouldn't load messageserror or agent hang was observed, and a shared root cause is not established. The macOS report preserves that distinct reproduction and workaround.Hoje-Yu commentedon Oct 9, 2026
Adding a Windows reproduction/confirmed non-destructive workaround to this existing issue (rather than opening a duplicate).
Environment
Observed behavior
Recovery attempts with no effect in the affected window
This appears to be a window-local conversation display/state synchronization failure, not proven message loss; that is an inference, not a diagnosed root cause. The symptom plus New Window workaround particularly resembles #52204 (macOS Chat), while this confirms a similar manifestation on Windows. It may overlap with #49062, but this case involved text initially rendering and then disappearing, without a visible "Couldn't load messages" banner.
Screenshots were reviewed privately; none are attached to avoid exposing personal chat/project content. No local profile, permissions, cache, or app data were deleted. Please investigate affected-window response projection/state refresh and identify a fixed Windows build when available.
miphorez commentedon Oct 9, 2026
Adding a related Windows 11 reproduction in the separate Quick Chat window (observed on 2026-10-09).
Observed sequence:
The attached screenshot directly shows the completed activity duration and blank answer area. The streaming visibility and later spontaneous recovery are the user's observations; the single screenshot does not establish those transitions. No "Couldn't load messages" banner is visible in this screenshot.
Expected: the completed answer should remain visible immediately after generation finishes.
This appears related to the missing-response visibility reported here, particularly the initially visible response subsequently disappearing described above. This occurrence is specifically in Quick Chat and recovered spontaneously; a shared root cause has not been established. The exact app version was not verified for this occurrence.
Screenshot (reviewed for private data):
KirkPete commentedon Oct 12, 2026
I have repeatedly experienced a similar problem with long answers appearing briefly, then disappearing entirely, leaving behind only the query and a note that the app worked for 13 seconds, or however long.
I am using a ChatGPT Plus for $20 a month with a standalone app, which has the following text on the About page:
ChatGPT
Powered by Codex & OWL
Version 26.924.22138
Released Sep 26, 2026
© OpenAI
KirkPete commentedon Oct 12, 2026
Addendum to above: This has happened three times this morning, and on earlier days. Each time, I tell the app that the response disappeared, and the app regenerates the response.