Repository navigation
[Windows Desktop] Streaming response disappears from chat; complete response returns after update/restart #52398
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Affected desktop session: 26.1002.6548.0.
After the user-initiated update/restart: 26.1002.7124.0.
Bundled/local app-server: codex-cli 0.162.0-alpha.2 before and after restart.
Versions were verified from the affected session's startup/update logs, the restarted session's logs, and the installed Windows package/runtime, rather than the About dialog.
What subscription do you have?
ChatGPT Pro ($200/month).
What platform is your computer?
Windows 11 Pro, version 25H2, OS build 26200.9457, x64.
Packaged application: OpenAI.Codex; desktop executable: ChatGPT.exe.
What issue are you seeing?
On October 8, 2026, I watched a response being actively written in a desktop chat, then stepped away. When I returned after an unspecified interval, the response was entirely missing from the chat, not merely paused partway through writing.
I also noticed that Claude's attempt to run a delegated review had failed. I switched back to ChatGPT/Codex and clicked the app's update button. The application updated and restarted; logs place the new desktop process start at 20:33:56 MST (America/Phoenix).
After restart, the full response was present. I did not send another message to the session to make it appear.
The update button worked, so this report does not assert that the entire application UI was unresponsive. The exact time the response disappeared is unknown. Because the desktop build changed during this restart, the evidence cannot distinguish recovery due to the update from recovery due to restarting/reloading conversation state. It also does not establish when generation completed.
A read-only investigation found continued successful backend response routing before shutdown. This suggests a possible display or conversation-state synchronization problem, but the root cause is unconfirmed. A routed response does not prove renderer receipt or display, and the successful requests below are background/configuration requests, not proof that the affected response completed before restart.
What steps can reproduce the bug?
No deterministic reproducer is available. No reproduction was attempted during the investigation.
Observed sequence:
-
Use an existing desktop chat on build 26.1002.6548.0 and observe a response actively being written.
-
Step away for an unspecified interval.
-
Return and find that the previously visible response is entirely absent.
-
Click the app's update button; the app updates and restarts into build 26.1002.7124.0.
-
Observe the full response in the same chat without sending another message.
The exact disappearance time, affected-turn token/context utilization, and completion time were not established. Session identifiers and conversation content are omitted for privacy.
What is the expected behavior?
A response that has already appeared should remain visible while generation continues and after generation completes. The desktop should reconcile the displayed conversation with stored/backend state without requiring an update or restart, and should show an actionable status if synchronization fails.
Additional information
Timeline and diagnostic evidence
All times below are October 8, 2026, MST (America/Phoenix). Log timestamps have been converted to local time; identifiers, private paths, and unrelated fields are omitted.
| Time (MST) | Observation |
| --- | --- |
| 08:16:09 | Affected desktop session started; its logs identify build 26.1002.6548.0 and local app-server 0.162.0-alpha.2. |
| 18:36:50 | First of five evening renderer ResizeObserver errors. |
| 18:42–19:25 | Four located Claude-delegated Codex CLI review sessions started, but execution tools failed during Windows sandbox setup. Details below. |
| 19:38:30–19:38:32 | The durable websocket disconnected with code 1006 and reconnected. This transient event does not establish a local app-server crash. |
| 20:14:14 | Last recorded evening ResizeObserver error. |
| 20:30:43 | Successful configuration responses still routed to desktop windows. |
| 20:33:38.997 | Desktop recorded update_resume_state_saved. |
| 20:33:50.131 | Last recorded pre-restart successful skills/list response; duration 1,127 ms, queue wait 0 ms. |
| 20:33:50 | Windows recorded the Codex sandbox service being asked to stop and stopping. |
| 20:33:56 | New desktop process started; sandbox service restarted. |
| 20:33:59–20:34:03 | New launch logged; successful backend requests followed. New desktop build was 26.1002.7124.0. |
| After restart; exact time unrecorded | User observed the full response without submitting another message. |
Selected sanitized excerpts:
2026-10-08 18:36:50.168 MST
[desktop-notifications][global-error]
ResizeObserver loop completed with undelivered notifications.
2026-10-08 20:33:38.997 MST
update_resume_state_saved threadCount=0
2026-10-08 20:33:50.131 MST
[AppServerConnection] response_routed
method=skills/list durationMs=1127 queueWaitMs=0
errorCode=null targetDestroyed=false
2026-10-08 20:33:59.680 MST
Launching app ... packaged=true platform=win32
2026-10-08 20:34:00.075 MST
Current reported app-server version:
currentVersion=0.162.0-alpha.2 hostId=local
The inspected evening desktop main log, from approximately 17:00 through shutdown, contains 475 routed responses, all with errorCode=null; recorded queue waits were 0–11 ms. Five ResizeObserver errors were recorded, but their relationship to the missing response is unknown.
No mcp_request_timeout, turn/start, spawn_agent, six-slot queue-rejection/queue-expiration signature, or renderer-process termination was found in that evening main-log window. Absence from these logs does not rule out an unlogged failure.
No matching Application Hang, Application Error, or Windows Error Reporting record was found in the inspected evening window, and no relevant crash/hang dump was found. The sandbox-service events numbered 1000/1001/1002 were service lifecycle messages, not Windows application-crash events.
Separate, confirmed failure in delegated reviews
The delegated Codex CLI sessions started, but command creation failed during sandbox provisioning. This is not a recorded spawn_agent failure. The sandbox log contains 36 runtime-validation failures between 18:42:08 and 19:24:57 MST, all targeting the same bundled node_repl.exe:
2026-10-08 18:42:08.985 MST
runtime read/execute validation failed:
validate runtime read/execute access on
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime>\bin\node_repl.exe:
open ACL target for root-only update:
The process cannot access the file because it is being used
by another process. (os error 32)
2026-10-08 18:42:09.015 MST
exec_command failed: CreateProcess
Rejected("Failed to create unified exec process:
helper_unknown_error: setup refresh had errors")
This closely matches #51634, #52389, and #51590. It is included only because the user noticed both symptoms during the incident. There is no established causal link between these sandbox failures and the response disappearing, and their order relative to the disappearance is unknown. No historical blocking-handle trace identifies the particular holder.
Related issues and limitations
-
[Windows Desktop] GUI stops accepting messages; successful backend replies time out in renderer #43460 is potentially related because backend replies can succeed while the desktop does not reflect them. This incident lacks that report's matched request/renderer-timeout pairs, so a duplicate is not established.
-
[Windows Desktop][26.803.10989.0] Six stuck app-server requests freeze every window and remove Fast mode #38385 describes six stuck requests and queue starvation; its defining signatures were not found here.
-
[Windows][Desktop 26.707.9981.0] Post-merge thread switching and prompt submission freeze with thread/resume latency and ResizeObserver errors #33524 shares ResizeObserver errors, but slow
thread/resumeevidence was not found here. -
[Windows] Repeated UI freezes on focus and chat switching after updates: cua_node rename_staging EPERM retry loop (26.928.2636.0) #49611 describes runtime relocation failures; its
rename_staging/EPERMsignatures were not found here.
Accessible evidence included desktop logs, read-only app-server log-database queries, Codex session events, Claude delegation diagnostics, sandbox logs, Windows Application events, and WER/Crashpad/CrashDumps locations. Missing evidence includes a live hang capture, renderer-delivery trace, historical resource measurements, and the exact disappearance timestamp.
The investigation itself was read-only and did not change configurations, modify repositories, delete logs, restart processes, or attempt reproduction. The update/restart described above was performed by the user before the investigation. No raw logs, transcripts, source code, credentials, or identifying session data are attached.
Activity
github-actions commentedon Oct 9, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
xdy-js commentedon Oct 9, 2026
I can reproduce the same issue in the Windows desktop application in normal Chat mode (GPT-6, High thinking setting), including during an active conversation on October 9, 2026.
Observed behavior:
Expected: Once a streamed final answer becomes visible, it should remain visible after the turn completes, without a client restart.
Additional observation: Chat mode also feels unusually slow. The incident above displayed 1m 14s of thinking with High selected; I cannot tell whether this latency is related to the missing-answer bug, and I am not claiming that the thinking time alone proves a performance regression.
I am providing this report as text only, without screenshots, attachments, private conversation contents, or logs. I do not have a verified desktop build number or diagnostic trace to add.
soup31314 commentedon Oct 9, 2026
I can confirm that I have independently encountered disappearing assistant responses in the Windows ChatGPT/Codex desktop experience. Responses that I expected to remain visible have gone missing from the conversation. This is a first-hand report, not a claim that my case has the same root cause as the original reporter.
I have not captured a diagnostic trace establishing whether the failure is in rendering, synchronization, or persistence, and I cannot confirm that the update/restart recovery described above works in every case. Please include this additional affected-user report when investigating #52398.
ansasar commentedon Oct 16, 2026
Hi, I have the same issue on MAC and Windows, but online and in ChatGPT classic on window it works fine