Repository navigation
[Windows][26.924.22138] Upward history pagination continues while idle, disrupts scrolling and precedes repeated renderer crashes #49255
Description
What version of the Codex App are you using (From "About Codex" dialog)?
App: 26.924.22138, build 11645, production channel.
Microsoft Store package: OpenAI.Codex 26.924.2738.0.
What subscription do you have?
Not specified in this public report. The failure occurs during desktop history navigation, not as a reported usage-limit error.
What platform is your computer?
Windows 11 Pro N, 10.0.26200, x64.
Intel Core i5-13600KF; NVIDIA RTX 4070 Ti; approximately 31.86 GiB physical RAM.
What issue are you seeing?
The conversation history keeps loading older messages upward even after I stop using the mouse and keyboard. Some of my conversations are extremely long. This also disrupts scrolling. Repeatedly, the app logo reappears and the entire UI reloads, without the outer window closing.
This is seriously disrupting work I need to perform now. A UI crash also interferes with supervising ongoing work, even when the backend stays alive.
I am filing this focused report for the idle upward-pagination / scroll behavior and its measured timing around crashes, rather than claiming a proven new root cause. Related renderer reports: #48938 (same app/package build), #37541, and #37694. Please merge or cross-reference as appropriate if engineering confirms the same cause.
Read-only evidence collected on 2026-09-29
- Six retained Crashpad sidecars have
capture_kind=crashandptype=renderer: two on September 28 and four on September 29. - Today's four artifacts were modified at 08:56:07, 09:03:57, 09:18:45 and 09:22:05, America/Santiago, UTC-03:00. These are sidecar filesystem timestamps, not native exception timestamps.
- The desktop main process and its local
codex.exe app-serverretained their September 28 06:51 start times throughout inspection. This was not a complete restart of those processes. - The session file for the conversation I identified as suspicious was 1,513,615,413 bytes, approximately 1.514 GB / 1.410 GiB, at 09:32:17 local. Its content was not exported or read in full. This is disk size, not renderer memory.
- That conversation appears in history-response activity within 30 seconds before three of today's four crashes. Other conversations also appear in one of those windows.
The following counts include only logged AppServerConnection response_routed events for the two history methods:
| Crash artifact time (local) | thread/items/list responses in prior 30 s | thread/turns/list responses in prior 30 s | ResizeObserver errors in prior 30 s |
|---|---|---|---|
| 08:56:07 | 9 | 4 | 3 |
| 09:03:57 | 0 | 0 | 0 |
| 09:18:45 | 247 | 46 | 10 |
| 09:22:05 | 42 | 8 | 10 |
These are logged responses, not unique pages, concurrent requests, or proof of repeated cursors. The 09:03:57 event does not show the same pattern in this window, so pagination has not been established as the sole cause.
The inspected main-log snapshot, 06:15:04 to 09:27:00 local, contains:
- 663 selected history responses;
- 229 occurrences of
ResizeObserver loop completed with undelivered notifications.; - 23
Conversation state not foundmessages; - 11
No promise for request IDmessages; - four
React root render requestedentries, following the four crashes.
For the 09:22 event:
- 09:21:58 through 09:22:03: repeated ResizeObserver errors during history activity;
- 09:22:05.186 approximately: renderer Crashpad sidecar;
- 09:22:07.043: React root render requested;
- 09:22:07.457: No promise for request ID;
- 09:22:08.388: Conversation state not found.
These messages do not demonstrate permanent loss of conversation data.
What steps can reproduce the bug?
This is a recurring user-observed pattern, not yet a deterministic controlled reproduction. I did not intentionally stress/restart the app during diagnosis because work was active.
- Use the Windows desktop app with a very long local conversation.
- Open or navigate toward older messages until history loading begins.
- Stop all mouse-wheel, keyboard and scrollbar input.
- Observe whether older-history loading reaches an idle state or continues automatically.
- Observe scrolling behavior and, if a reload happens, correlate renderer termination with the history/layout events.
- Compare with a short conversation and a synthetic long text-only history.
The exact initial trigger (opening, restoring position, or an initial upward scroll) remains to be isolated.
What is the expected behavior?
- Fetch a bounded page/prefetch budget and return to idle; do not involuntarily walk the entire history.
- Keep a stable visible-message anchor while prepending older messages.
- Avoid repeated-cursor / no-progress loops and duplicate in-flight loads.
- Bound retained/rendered history and memory for inactive chats.
- Keep the UI usable for supervising ongoing tasks.
- If the renderer fails, provide a supported recovery path that preserves active work.
Additional information
Uncertainty: There is no native exception stack, pre-crash renderer heap capture, or cursor trace in this evidence. OOM, a memory leak, an image-specific cause and a GPU cause are not confirmed. ResizeObserver errors may be symptoms rather than the cause.
At the initial resource sample, approximately 9.1 GiB RAM and 1832 GiB disk space were free. These were not synchronized to the crash instant and do not exclude a per-process memory limit. A later app-server sample was about 1.085 GiB private memory, so this is not a measured reproduction of the >16 GB app-server case in #37694.
No processes were killed, histories deleted, caches reset, configuration changed or third-party repair tools installed. Store update availability could not be determined by the information-only check.
Request: Please investigate the interaction between idle upward pagination, scroll anchoring/layout and renderer recovery on this build, and provide a supported immediate mitigation that preserves existing chats and running tasks. Please identify a fixed version when available.
A privacy-reviewed extended report and selected CSV/JSON evidence are available in a small local ZIP for a secure support channel. No raw rollouts, conversation titles/IDs, project paths, account details, screenshots or credentials are included here.
Activity
github-actions commentedon Sep 29, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
LuckRef commentedon Oct 11, 2026
Update: still occurring on 2026-10-11, with 32 renderer crashes in 24 hours
This is the same recurring user-observed problem reported here on September 29, not a first occurrence. It continues to cause major delays and repeatedly interrupts work and supervision of ongoing tasks.
Current environment
OpenAI.Codex: 26.1002.7124.0 (package metadata, not the About-dialog version).Measured 24-hour window
2026-10-10 17:13:29 UTC through 2026-10-11 17:13:29 UTC (14:13:29 to 14:13:29, UTC-03:00).
{"capture_kind":"crash","osarch":"x86_64","ptype":"renderer"}React root render requestedevents for the primary window (windowId=1,rendererWebContentsId=1), each approximately 1.5–2.2 seconds after a corresponding sidecar's filesystem modification time.ChatGPT.exeprocess remained alive with the same start time predating the window. These are renderer crashes/UI recoveries, not 32 full application-process restarts.Selected examples (UTC):
Several sequences recur every few minutes.
ResizeObserver loop completed with undelivered notificationsalso appears in the logs, but these errors were not counted as additional crashes and are not established as the cause.User-observed behavior and impact
Opening this very long conversation causes older history to load upward automatically without scrolling. The interface then reloads after a short time; returning to the same conversation reproduces the pattern. Other chats do not show the same user-observed behavior. This is an affected-session reproduction, not a clean-install minimal reproducer, and not every crash has been independently attributed to a specific history request.
The ongoing interruptions force repeated UI recovery, context recovery and rechecking. This has been extremely frustrating and materially delays work. Preserving the complete conversation is essential; deleting history or abandoning it is not an acceptable resolution.
A read-only
codex migrate-rolloutsinspection of the affected chat returnedalready_paginatedandbytes_processed=0; no migration was applied. OOM, GPU failure, a specific cursor loop and permanent data loss have not been established.Request
Please investigate the persistent idle-history loading/renderer recovery behavior and provide a supported mitigation or fixed version that preserves history and ongoing work. The private support case has also been escalated; account-specific usage/credit review is being kept in that private channel.
This public update excludes account email, chat/session identifiers, project details, personal paths, raw logs, transcripts, screenshots and memory dumps.
LuckRef commentedon Oct 12, 2026
Follow-up on 2026-10-12: please provide a concrete engineering response
This issue was first reported here on September 29. Yesterday's update documents 32 renderer crashes in a measured 24-hour window, followed by UI reconstruction while the main process stayed alive. There is still no human engineering response on this issue.
The repeated interruptions and recovery work have caused substantial delays. The affected conversation is needed for ongoing work, so a supported solution must preserve its history.
Please confirm:
If this belongs under another existing issue, please link the canonical issue and carry forward the October 11 crash evidence so it is not lost. A private support case has also been escalated, including the request to review usage and possible credit restoration/compensation; that account-specific decision remains in the private support channel.
Please acknowledge the longstanding disruption and provide an actionable response. No additional crash count or root cause is claimed in this follow-up.
LuckRef commentedon Oct 12, 2026
Reproducible technical evidence and collector source (2026-10-12)
This update provides the actual sanitized event dataset, machine-readable summary and complete PowerShell collector, rather than relying only on a narrative.
The two 24-hour windows overlap. Their counts must not be added. The combined collection directly counts 39 distinct retained artifacts, with no unmatched artifacts or invalid sidecars. The three extra UI initializations are not classified as crashes.
Latest observed event and version
The newest retained renderer crash artifact is dated 2026-10-12 12:02:49.208 UTC, followed by a primary-window root initialization at 12:02:51.259 UTC. Its metadata is
capture_kind=crash,ptype=renderer,osarch=x86_64.The corresponding Oct 12 UI initialization is in the log of the current main process. That process's executable package version is 26.1007.2314.0, verified from its executable path; its start time is 10:24:00.599 UTC on Oct 12. This establishes a renderer failure/UI recovery observation during the current version's run. It does not establish the native exception or that every historical event used this version. The earlier Oct 10–11 report observed package 26.1002.7124.0.
Collection and validation
Limitations: artifact times are filesystem
LastWriteTimeUtc, not native exception timestamps. Timing correlation does not identify a responsible conversation, OOM allocation, GPU failure or root cause. Error counts cover the inspected app logs rather than exclusively this conversation, and are not additional crashes. The script is a diagnostic collector, not an application patch or a synthetic minimal crash reproducer.Complete combined summary
{ "SchemaVersion": 1, "StartUtc": "2026-10-10T17:13:29.240Z", "EndUtc": "2026-10-12T12:05:10.000Z", "RendererCrashArtifacts": 39, "UniqueUIRootRenderEvents": 42, "MatchedArtifactsWithin10Seconds": 39, "UnmatchedCrashArtifacts": 0, "InvalidSidecars": 0, "LogFilesRead": 18, "AllowlistedErrorOccurrences": { "ResizeObserver loop completed with undelivered notifications": 789, "Conversation state not found": 759, "No turns for conversation": 2570, "No promise for request ID": 1 }, "EventsCsvSHA256": "D68A3F6DC78F036FB14EF1AFC1F433B97AD4D2142E75A142A12094D169E06978", "Limitations": [ "Crash artifact times are filesystem LastWriteTimeUtc, not native exception times.", "A temporal UI match does not identify the responsible conversation or root cause.", "Error occurrences are not additional crashes.", "Only retained artifacts and the specified log directories are counted.", "The collector does not inspect transcripts, credentials, native dumps or process memory." ] }Complete 39-event CSV
Complete diagnostic collector: Collect-CodexRendererEvidence.ps1
Save the source as
Collect-CodexRendererEvidence.ps1, then run:For a different installation, override
LogRootandCrashRootwith one canonical location. Do not combine mirrored Windows paths. It reads the specified logs/artifacts and writes only its own CSV/JSON output.Collector SHA-256:
06746F94EA5D97781948520485717DA3748987B67EA48E6D51BB752B1CDB3A06Combined CSV SHA-256:
D68A3F6DC78F036FB14EF1AFC1F433B97AD4D2142E75A142A12094D169E06978Please use this evidence to investigate the primary renderer failure and advise which targeted native crash capture is needed next and a secure upload channel for it. The public dataset deliberately omits full logs/transcripts and dumps.
kazuyachen1986-rgb commentedon Oct 14, 2026
Windows 26.1007: captured native dump confirms V8 main-isolate OOM during dense history loading
Submitted with the affected user's authorization. The user continues to experience white-screen reloads and changed scroll position during normal Codex work.
Environment verified locally:
A bounded local capture obtained and validated a renderer minidump at 2026-10-14 22:49:40 UTC. No live process was injected into or terminated for collection. The retained file has a valid MDMP header, 12 streams, and in-bounds stream descriptors.
Confirmed diagnostic fields from this one dump:
The desktop log recorded 109 thread/items/list response_routed events in the preceding 30 seconds for the affected conversation. These are response counts, not unique pages or proof of a repeated cursor. The main process remained alive and the primary renderer was recreated immediately afterward.
The current process was running with --disable-gpu. That mitigation therefore did not prevent this captured OOM. Official doctor checks reported state and thread-history database integrity as ok. No histories, indexes, authentication, or application binaries were changed.
Interpretation and limits: this confirms V8 memory exhaustion for the captured failure. It does not identify the exact retaining application object, prove that previews or images are responsible, or establish the exception of every earlier crash. Raising a generic heap limit should not be proposed without addressing the captured 4096MB cage limit.
Please investigate bounded history loading, retention of large JavaScript objects, and inactive-history eviction. Please provide a supported mitigation or the exact fixed Windows build that preserves complete histories and running tasks.
Only this minimized technical summary is shared. No native dump, raw log, transcript, conversation ID, private path, account information, or screenshot is attached.