Repository navigation
Windows 26.928.2636.0: Repeated renderer V8 OOM crashes reload the UI while background tasks continue #49666
Description
環境
Windows 11 x64，32 GB RAM。
應用程式 26.928.21956，build 12404，prod。
Microsoft Store 套件 OpenAI.Codex 26.928.2636.0。
現象
介面每隔數分鐘突然消失，出現載入圖示後回到首頁；主程序與部分背景工作仍持續，Dot 語音通話中斷。使用者表示沒有再次點擊聊天也可能發生。
14 秒錄影顯示：從一個正在工作的聊天切至另一個聊天後，約第 4–5 秒開始整個介面重新載入，約第 9 秒回到首頁。錄影沒有可核對的時鐘，未將它強行對應某一筆崩潰時間。
已確認的原生崩潰資料
2026-09-30 23:24:08 UTC+08:00 捕捉到 renderer minidump：
例外碼 0xe0000008。
ptype=renderer。
v8-oom-location=CALL_AND_RETRY_LAST。
v8-oom-last-few-messages 包含 allocation failure、GC in old space requested、last resort。
最後兩次回收後 JavaScript heap 約 2562.3 MB、2561.5 MB；配置仍失敗。
這證實當次的直接故障為 V8 記憶體配置失敗，但未辨識到具體 JavaScript 呼叫者。
其他觀察
23:42:06.509 又新增 renderer 崩潰 sidecar；23:42:06.171 的取樣顯示該介面程序私有記憶體 4578.6 MiB、工作集 4085.6 MiB，整機 RAM 使用率 63.5%。不能用整機實體 RAM 用盡解釋這次觀察。
23:44:52.911 再次新增 renderer 崩潰 sidecar。這兩筆 sidecar 本身不含例外碼，未假設全部崩潰都有相同原生堆疊。
同一大型本機聊天的 thread/items/list 回應曾每分鐘達 300–500 多筆。聊天歷史檔約 38.61 GiB；這是磁碟檔案大小，不等同介面記憶體或每次回應大小。
切走聊天後仍觀察到歷史回應；未證明游標重複，也尚未建立受控最小重現。
Codex Doctor 的安裝、設定載入、桌面 app-server 握手、HTTP/WebSocket 可達性，以及已檢查資料庫完整性均通過。診斷中的一般性警告未證明與這次 OOM 有關。
相關公開案例
#49255
#46690
#48938
#47793
這些是比對線索，沒有宣稱它們均為同一根因。
請協助
確認是否與已知 Windows renderer／歷史分頁問題相關。
提供能保留執行中任務與聊天資料的受支援暫時處理方式。
指出已修復的具體版本，或需要追加的診斷資料與安全提交管道。
隱私
此摘要未包含帳號、電子郵件、聊天識別碼、專案名稱、檔案路徑、對話內容或憑證。原生 dump 與錄影保留在本機，尚未公開；原生 dump 可能含程序記憶體內容。
Activity
[-]Windows 26.928.2636.0 反覆 renderer V8 OOM，介面重新載入而背景任務繼續[/-][+]Windows 26.928.2636.0: Repeated renderer V8 OOM crashes reload the UI while background tasks continue[/+]github-actions commentedon Sep 30, 2026
English translation:
Environment
Windows 11 x64, 32 GB RAM.
Application 26.928.21956, build 12404, prod.
Microsoft Store package OpenAI.Codex 26.928.2636.0.
Symptoms
Every few minutes, the UI suddenly disappears, shows a loading icon, and returns to the home page; the main process and some background tasks continue running, while the Dot voice call disconnects. The user reports that this can happen even without clicking the chat again.
A 14-second recording shows that after switching from a chat with work in progress to another chat, the entire UI starts reloading around seconds 4–5 and returns to the home page around second 9. The recording has no clock that can be cross-checked, so it has not been forcibly matched to a specific crash timestamp.
Confirmed native crash data
A renderer minidump was captured at 2026-09-30 23:24:08 UTC+08:00:
Exception code 0xe0000008.
ptype=renderer.
v8-oom-location=CALL_AND_RETRY_LAST.
v8-oom-last-few-messages includes allocation failure, GC in old space requested, and last resort.
After the last two garbage collections, the JavaScript heap was approximately 2562.3 MB and 2561.5 MB; allocation still failed.
This confirms that the immediate failure in that instance was a V8 memory allocation failure, but the specific JavaScript caller has not been identified.
Other observations
Another renderer crash sidecar was created at 23:42:06.509; a sample taken at 23:42:06.171 showed that the UI process had 4578.6 MiB of private memory and a 4085.6 MiB working set, with overall system RAM usage at 63.5%. Exhaustion of the system's physical RAM cannot explain this observation.
Another renderer crash sidecar was created at 23:44:52.911. These two sidecars do not themselves contain exception codes, so it has not been assumed that all crashes have the same native stack.
For the same large local chat, thread/items/list responses have at times reached 300–500+ items per minute. The chat history file is approximately 38.61 GiB; this is its size on disk, not the UI's memory usage or the size of each response.
History responses were still observed after switching away from the chat; duplicate cursors have not been proven, and a controlled minimal reproduction has not yet been established.
Codex Doctor checks for installation, settings loading, the desktop app-server handshake, HTTP/WebSocket reachability, and the database integrity checks performed all passed. The general warnings in the diagnostics have not been shown to be related to this OOM.
Related public cases
#49255
#46690
#48938
#47793
These are leads for comparison; there is no claim that they all share the same root cause.
Requested assistance
Confirm whether this is related to known Windows renderer/history pagination issues.
Provide a supported temporary workaround that preserves running tasks and chat data.
Identify the specific version containing a fix, or specify any additional diagnostic data needed and a secure submission channel.
Privacy
This summary contains no account details, email addresses, chat identifiers, project names, file paths, conversation content, or credentials. The native dump and recording remain local and have not been made public; the native dump may contain process memory contents.
github-actions commentedon Sep 30, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
ankiygoescrazy commentedon Oct 1, 2026
I can reproduce a severe Windows desktop memory-growth problem that does not require the originally suspected project/task.
Reproduction / timeline
Windows 11 desktop app. I initially suspected one specific task because memory usage exploded while it was running, but a controlled follow-up showed the same behavior with an unrelated task.
Approximate observations from Task Manager screenshots taken on 2026-10-01 (local time UTC+05:30):
At ~13:40 Codex was also using ~29% CPU. The central conversation pane was stuck on a loading spinner while the task card still indicated activity.
Why this seems important
The original suspected task is not required to reach the pathological memory state. A different task caused the Codex desktop process group to grow from roughly 1.2–1.5 GB to nearly 10 GB over ~20 minutes.
This makes an app/renderer/session memory problem much more likely than a project-specific workload alone. It may also be related to the UI/chat-loading failure: while memory was high, the conversation view repeatedly remained on a spinner.
Additional observations
Privacy / evidence
I am not uploading the raw screenshots here because they contain account/project-identifying information. I can provide redacted screenshots or additional diagnostics if maintainers specify what would be most useful.
Request
Could maintainers confirm:
This report is intended as additional reproduction evidence for the same class of Windows desktop OOM/memory-growth issue.