[Windows] Codex Desktop severe UI lag, input delay, and intermittent Not Responding while browser version remains responsive #43726

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   performance

   on Sep 8, 2026
2. github-actions commented on Sep 8, 2026

   

   github-actionsBot

   on Sep 8, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • Windows: severe slowdown after extended use with high memory usage in cua_node and codex background processes #43405
   • [Windows][Codex Desktop 26.901.6511.0] ~25s UI freeze during D3DCompile of ChatGPTAvatar Horizon shader #43583

   Powered by Codex Action
3. aglsv commented on Sep 9, 2026

   

   aglsv

   on Sep 9, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   I reviewed the two potential duplicates suggested by the bot (#43405 and #43583). At this point I do not think this issue can be confirmed as a duplicate of either one.

   • Windows: severe slowdown after extended use with high memory usage in cua_node and codex background processes #43405 focuses on severe slowdown after extended use together with very high memory consumption in cua_node/node.exe and codex.exe (multi-GB to 10+ GB private committed memory). I have not observed or confirmed that same extreme memory pattern in my case.
   • [Windows][Codex Desktop 26.901.6511.0] ~25s UI freeze during D3DCompile of ChatGPTAvatar Horizon shader #43583 captures a specific intermittent ~25–30 second freeze caused by a long D3DCompile stall for the internal ChatGPTAvatar/Horizon shader. My main symptom is broader and more persistent UI/input latency: delayed typing, slow button clicks, slow thread switching, taskbar restore/minimize problems, and occasional Not Responding states.

   A particularly useful distinction is that the browser version on the same machine and network remains responsive, while the Windows Codex Desktop app exhibits the lag.

   So there may be overlap with the same general Windows desktop performance area, especially #43405, but there is not enough evidence yet to conclude that this is the same root cause. I would prefer to keep this issue open unless maintainers can confirm a duplicate/root-cause match.
4. qqqzhH commented on Sep 10, 2026

   

   qqqzhH

   on Sep 10, 2026

   More actions

   Additional reproduction with main-thread evidence: the Desktop main process blocks 3–26 s on a synchronous IPC every 20–40 s, with no CPU/GPU/disk load

   Environment

   • Windows 11 (10.0.22621), AMD iGPU + NVIDIA RTX 3060 Laptop GPU
   • OpenAI.Codex_26.901.6511.0_x64__2p2nqsd0c76g0 (bundled codex-cli 0.153.4), Microsoft Store build
   • ChatGPT Pro auth, model gpt-6-astra
   • 15.2 GB RAM

   Symptoms
   The Desktop window shows Not Responding for 3–26 s at a time, roughly 1.5 times per minute (measured with a 1 s responsiveness probe over ~3 hours: 40 / 27 / 32 stalls in three consecutive windows, across app restarts). CPU, GPU and disk all stay idle while it is frozen.

   Evidence captured while Responding=False (4 samples, identical distribution)

   36 x Wait, UserRequest
   12 x Wait, EventPairLow     <-- the main thread is blocked here (sync IPC)
    8 x Wait, Unknown
    1 x Wait, Executive
   main thread id=7688  wait=EventPairLow
   

   Per-process CPU sampled at t0 and t+3 s during one stall — nothing is running:

   MAIN        63.77s -> 64.62s   (+0.85 s)
   renderer    9.41s  -> 9.41s    (unchanged)
   gpu-process 4.36s  -> 4.36s    (unchanged)
   codex.exe   4.11s  -> 4.11s    (unchanged)
   

   Main-process working set jumps ~+300 MB at stall start (e.g. 520 -> 882 MB, peak 1269 MB observed) and drops back on recovery.

   The 10 s of Desktop log immediately before every stall is empty — no app-server request, no plugin/marketplace activity, no error. Nothing is logged while it is frozen.

   Ruled out by measurement (not by guesswork)

   • Responses WebSocket — disabled via a custom HTTP-only provider (supports_websockets = false); stalls unchanged. codex doctor reports "Responses WebSocket is not enabled for the active provider"; CLI runs report transport="responses_http".
   • Remote-control WebSocket — wss://chatgpt.com/backend-api/wham/remote/control/server did fail once with os error 10060 after 7 retries and took the app-server down (exit code 1, app fatal + GPU child killed, WER Application Hang at the same second). After clearing the enrollment the app re-enables it at startup but logs no WS error — and the stalls continue unchanged.
   • In-app browser (IAB) — opening the browser sidebar produced one 26 s stall (webview create/attach/teardown, with a ResizeObserver error flood). Disabled via [features] in_app_browser = false + browser_use = false (log confirms browser_use_availability_resolved available=false reason=browser-pane-disabled) — the stalls continue.
   • All MCP servers and plugins — disabled for a test round; stalls unchanged.
   • HID enumeration — custom P/Invoke probe (SetupAPI + HidD_Get*String) against every HID interface: all string-descriptor queries < 40 ms. No slow/wedged device.
   • AV kernel drivers (360 Total Security, 8 resident drivers incl. a file-system filter) — process creation measured the way Node/Electron does it (CreateNoWindow + redirected pipes): 22–32 ms. Normal.
   • Disk — SSD, 1 MB write = 0 ms, queue near zero.
   • Large threads — a 285M-token thread made it noticeably worse (archiving it removed a whole cluster of stalls for 25 min), but stalls persist on a small thread too.
   • DWM resource accumulation (the cause fixed in 26.825.32147) — dwm.exe stays at 79 MB / 0 s CPU, no accumulation. This build is newer than that fix.
   • WMI — Win32_PerfFormattedData_PerfProc_Process query ≈ 520 ms, WmiPrvSE idle. No WMI storm.

   Related existing reports

   • [Bug] Windows Desktop 26.715.4045 freezes during bundled-plugin reconcile; plugin/list blocks for ~61s #34244 — same main-process RSS spike (419 MB -> 1.07 GB) and the same "repair/reset/reinstall and archiving the large thread did not help" outcome; that report is attributed to the bundled-plugin reconcile path, but here plugin/list / mcpServerStatus/list only take 2–5 s once at startup, while the stalls recur every 20–40 s afterwards.
   • Codex desktop app intermittently freezes Windows shell/UI; opening Codex Settings stops the freeze #16374, Windows app hangs ("not responding") after launch — main process blocks forever in HID device enumeration (HID.node → hid.dll) when one HID device doesn't respond #33780, [Windows] Codex Desktop renderer allocates to ~4.7 GB and hangs ~20s after launch on 26.803.5235.0 - reproduces with zero conversations #37829, [Windows][26.820.9563.0] Resuming one specific 18.49 MB thread reproducibly leaves Desktop UI stuck #41097.

   Ask
   Is the Desktop main process expected to make a synchronous IPC call on a 20–40 s cadence? If you can tell me either (a) which switch enables the built-in performance-trace recorder, or (b) what you would like captured, I will collect a native trace / ETW capture during a stall and attach it. I can reproduce this on demand (it happens ~1.5x per minute), so any instrumentation you want can be gathered quickly.
5. Meganezaru commented on Sep 25, 2026

   

   Meganezaru

   on Sep 25, 2026

   More actions

   I’m seeing what appears to be a related issue when using Codex from the ChatGPT desktop app on Windows.

   The sequence in my case is as follows:

   1. I branched from a main task and created separate worktree-managed tasks.
   2. While I was working only inside those individual tasks, I did not notice any keyboard input latency.
   3. In one of the individual tasks, I instructed Codex to delegate part of the work to a lighter model — specifically, to run tests using the Luna model.
   4. Codex then began spawning sub-agents for that delegated work.
   5. I started another separate individual task and performed similar work there as well.
   6. Shortly after multiple individual tasks had begun using sub-agents, noticeable keyboard input latency started occurring across the entire Windows system.

   The latency is system-wide rather than limited to the ChatGPT/Codex window, and it affects typing in unrelated applications as well.

   I also see another possibly related symptom involving sub-agent completion reports. A sub-agent spawned from an individual branched task reports its completion not only to that individual task, but also to the original parent task from which the worktree-managed task was branched.

   In other words, the completion report appears in both:

   • the individual task that actually spawned the sub-agent, and
   • the original main task that served as the branching source.

   This happens even though the sub-agent was created as part of work being performed only inside the individual branched task.

   The important distinction in my case is that simply using multiple worktree-managed tasks did not appear to cause the problem. The keyboard latency only started after those tasks began spawning sub-agents to delegate work to another model.
6. zekai7261-stack commented on Oct 3, 2026

   

   zekai7261-stack

   on Oct 3, 2026 – with ChatGPT Codex Connector

   More actions

   Additional measured evidence: ChatGPT-mode sidebar family-key serialization hotspot

   This is a separate affected installation, providing a narrower profiling lead for the Windows desktop UI lag described here. It does not establish that every report in this issue has the same cause.

   Environment at capture: Microsoft Store package OpenAI.Codex 26.928.4866.0, Windows 10 Pro 10.0.19045 x64, i7-10700, 32 GB RAM, RTX 2070 SUPER, client/system on SSD. Measurements were taken on 2026-10-03. No reinstall or permanent source patch has been performed.

   Reproduction and comparison

   In ChatGPT mode, repeatedly select existing conversations from Recents. Hover/wheel feedback and sometimes typing freeze along with navigation, commonly for 4–10 seconds, sometimes longer. Codex mode is substantially faster. Collapsing Recents sometimes helps temporarily, but does not reliably eliminate this ChatGPT-mode issue.

   On the same machine/account, a short web-interface comparison with the sidebar expanded switched the same three conversations in approximately 1 second. On a second consecutive warm pass, click plus accessibility-observation calls returned in 1143 / 1082 / 1011 ms, with the corresponding conversation body visible after each call. These are automation-return times, not exact presentation latency, and this is not a prolonged input/usage benchmark.

   Recorded evidence and integrity limits

   • An unprofiled 90-second window contained user-confirmed continuous lag. The busiest renderer averaged 1.59 core equivalents, about 2 in the final minute. Its working set grew 1662 → 3054 MiB; minimum available physical RAM was 11810 MiB. Disk queue samples were all zero. This does not exclude transient I/O, database locks or a longer-term leak.
   • A separate CPU-profile capture recorded three main-thread tasks with wall/CPU times of 3767/3629 ms, 11039/10678 ms, 9065/8777 ms. User-reported freezes occurred in the same approximate window; clicks were not precisely timestamped. Profiling adds overhead and is not a before/after speed benchmark.
   • Strict whole-profile validation did not pass: automatic cutoff omitted End records and the main profile had 100 small negative time deltas, maximum magnitude 18 µs, sum of magnitudes 763 µs. This is not presented as a fully valid completed CPU profile.
   • A separate analysis restricted to the already recorded task windows retained signed deltas without clamping. Sample-node/parent references and samples/timeDeltas pairing are complete; the three windows are covered by recorded samples and contain zero negative-delta samples.
   • In these three windows, Vst + Hst account for 86.86% / 86.48% / 86.54% of self sample counts. These are sample proportions, not precisely measured per-function CPU seconds.
   • Of the four highest-self-count Vst nodes examined per task, 11 of 12 complete ancestor chains reach sidebar component Jcs. A direct chain is Jcs → vA → family key/resolve → Vst/Hst. The remaining chain reaches a layout-effect callback/React commit path without Jcs; the entire serialization proportion must not be attributed to Jcs.

   Installed-code lead

   app-shared-19f7cd6bb8b6.js: trace zero-based line 289, columns 118457 (Vst) and 118661 (Hst). Hst recursively maps arrays and copies object fields in sorted-key order; Vst JSON-stringifies the result unless a custom key is supplied. The eA family factory computes this key before its Map lookup, including cache hits. The vA hook also computes the key and resolves the family before useMemo.

   app-initial-9e0f03d3c485.js: Jcs at trace zero-based line 4589, column 68387. The sidebar builds parameters containing chatGptSource with chatTargets, pinnedTargets, pinnedProjects and projects, then calls If($0n, parameters). Import mapping is If=vA, Ta=aA. $0n uses the two-argument Ta factory without a custom key/excludeFieldsFromKey. Mode-dependent filtering occurs inside the derived callback, after key construction. Nls likewise receives the expansion-group array without a custom key. ct/dt already have compiler-generated memoization; the concern is repeated structural key calculation even on family cache hits, not an unproven claim that they are always new objects.

   No argument payloads were captured, so actual input size, growth cause and precise contribution by family remain open. This does not prove that full chat transcripts are serialized or that specific conversations are corrupted.

   Suggested investigation

   Please measure payload shape/size, key recomputation count and time for $0n/Nls. Consider stable identifiers plus versioned store dependencies instead of serializing a growing source object for family lookup. Identity-only/global WeakMap caching is not a validated drop-in fix: immutability, invalidation, equal-content distinct objects, in-place updates and disposal must be checked.

   Existing user conversations, projects, sidebar organization, plugins and skills need to remain intact. A reset/purge is not an acceptable permanent workaround for this installation. Raw traces, transcripts, account/conversation IDs, credentials, local paths and screenshots with private chat titles are deliberately not attached. Please investigate the measured code path and provide a fix or a data-preserving workaround.
7. zekai7261-stack commented on Oct 4, 2026

   

   zekai7261-stack

   on Oct 4, 2026 – with ChatGPT Codex Connector

   More actions

   Consolidated follow-up (2026-10-05): startup improved after local-data reduction, but cumulative UI stalls remain

   This combines the earlier renderer/code-path findings in my previous comment with new user observations and a separate local storage analysis by DeepSeek Harness (DSH). The desktop performance problem remains unresolved.

   Environment: Windows 10 Pro 10.0.19045 x64, i7-10700, 32 GB RAM, RTX 2070 SUPER, system/client on SSD. Installed package OpenAI.Codex 26.928.4866.0, rechecked on October 5. The affected surface is primarily ChatGPT mode inside the desktop app; Codex mode was substantially faster in the earlier comparison.

   1. New reproduction: degradation accumulates across opened conversations and affects Settings too

   The user reports this sequence after the local-data reduction:

   1. Restart the desktop client: initially reasonably responsive.
   2. Open/switch among approximately 5–6 distinct conversations: slowdown becomes noticeable.
   3. After approximately 8–9 distinct conversations: severe, effectively unusable lag.
   4. Open Settings: each subsection selection takes approximately 4–5 seconds, with audible CPU-fan acceleration.
   5. Restart: responsiveness temporarily returns; repeated conversation switching brings the lag back.

   These are user-observed thresholds and timings, not instrumented click-to-paint measurements. The new report describes approximately single-core saturation; the earlier independent trace below directly recorded almost one full CPU core for a 4.9-second main-thread task. We have not captured a new timestamp-aligned CPU trace of the October 5 Settings clicks.

   The Settings symptom establishes that the slowdown affects navigation outside the conversation body. It strengthens the case for shared UI/main-thread or shared-state work, and for accumulation within a client run. It does not by itself prove that every interaction synchronously recomputes all loaded conversations; that precise scope still needs instrumentation.

   2. Renderer evidence, with the existing corrections preserved

   October 2 event trace: the longest recorded renderer-main-thread task was 4,896.835 ms wall time, with 4,858.061 ms thread CPU time (99.2%). Identified GC scopes occupied 340.858 ms and Layout/Paint 83.822 ms (scope unions, overlapping with JavaScript; do not add them as separate CPU components). Seven tasks exceeded one second. The user subsequently confirmed repeated Settings/Voice/Settings switches and 4–5-second stalls during this capture, but individual clicks were not timestamp-aligned to individual tasks.

   October 3 CPU-profile task windows: recorded wall/CPU times were approximately 3,767/3,629 ms, 11,039/10,678 ms, and 9,065/8,777 ms. In those three windows, canonical-key functions Vst + Hst represented 86.86% / 86.48% / 86.54% of self samples; GC was approximately 7–10%. These are sampling proportions, not precise per-function CPU seconds.

   The whole profile failed strict completion validation: automatic cutoff omitted End records, and there were 100 small negative deltas outside the selected windows (maximum magnitude 18 µs; total magnitudes 763 µs). The three reported windows had complete node/parent references, matched samples/timeDeltas, recorded coverage, and zero negative-delta samples, using signed deltas without clamping. Profiling overhead prevents treating this as an unprofiled speed benchmark.

   Ancestor-chain correction: of the four highest-self-count Vst nodes examined per task, 11 of 12 complete chains reach sidebar component Jcs. One does not: it reaches a layout-effect/React commit path. The entire serialization share must not be attributed exclusively to Jcs.

   An earlier unprofiled 90-second lag window averaged 1.59 renderer core equivalents, with working set 1662 → 3054 MiB, at least 11810 MiB available RAM, and zero sampled disk queues. This supports CPU-heavy UI work in that window; it does not prove absence of locks, transient I/O, or leaks.

   3. Installed-code lead: cache hits still pay for canonical JSON keys

   In app-shared-19f7cd6bb8b6.js, trace zero-based line 289, columns 118457 (Vst) and 118661 (Hst):

   • Hst recursively visits arrays and copies object fields in sorted-key order; the relevant Vst path JSON-stringifies that canonicalized structure unless a custom key is supplied.
   • The family factory eA calculates the key before its Map lookup, including cache hits.
   • The hook vA invokes [Uot] / [xk] before useMemo; a layout-effect path also resolves through [xk]. Memoizing downstream work therefore does not remove the preceding key cost.

   In app-initial-9e0f03d3c485.js, Jcs at trace zero-based line 4589, column 68387:

   • The sidebar passes parameters containing chatGptSource with chatTargets, pinnedTargets, pinnedProjects, and projects into If($0n, parameters); imports map If=vA, Ta=aA.
   • $0n and Nls use two-argument family-factory calls, without a custom key/excludeFieldsFromKey option.
   • Mode-dependent filtering/sorting occurs inside the derived callback, after key construction. Reducing that callback's sorting/filtering alone cannot remove serialization of its incoming parameters.
   • ct/dt already have compiler-generated memoization. We are not claiming that their references are always recreated or that family caches never hit.

   No runtime argument payloads were captured. Their actual size, growth with opened conversations, and the respective costs of $0n/Nls remain unmeasured; this is not proof that complete chat transcripts enter these keys.

   4. Independent storage findings and intervention result

   DSH supplied aggregate measurements from local SQLite/rollout analysis. Scripts were reviewed locally; the original pre/post experiment was not independently rerun for this comment.

   Local store	Before	After
   ~/.codex/thread_history_1.sqlite	approximately 1066.8 MiB	183.1 MiB
   ~/.codex/logs_2.sqlite	220.6 MiB	129.4 MiB
   %APPDATA%/Codex/web/Codex profile directory	1431.8 MiB	821.6 MiB

   The database baseline varies slightly by snapshot (another retained pre-trim copy was 1067.1 MiB). These binary units correct the scripts' original “MB/GB” labels. The web-profile total includes retained business storage; it is not all disposable cache. The logs reduction was VACUUM, with reported free-page ratio 31% → 0.

   DSH's pre-trim thread_items analysis reported 58,746 rows / 199 threads, approximately 17.1 KiB per item:

   • mcpToolCall: 8,755 items, reported size 500.6 MiB; result.content[].text blocks reached a reported 1024 KiB. This is an observed size, not a verified universal limit.
   • imageGeneration: 233 items, reported size 325.7 MiB, with inline base64 images.
   • commandExecution / userMessage / fileChange: 78.0 / 38.3 / 28.8 MiB.
   • Largest 500 / 1,000 rows accounted for approximately 51% / 64% of item JSON. In a 6,000-row field sample, result accounted for 89.7% of serialized field bytes.

   The item-type totals use SQLite LENGTH(TEXT)/2^20, so they are character-count-based size estimates, not exact UTF-8 byte totals.

   The sessions directory was 3.36 GiB / 183 files. Among the 40 largest files (2.80 GiB), 84.4% of bytes matched long base64-like runs. This was a regex estimate with image signatures, not complete image decoding/classification. The largest rollout was 303.9 MiB, with 2,127 Screenshot and 610 Snapshot string occurrences; these are marker counts, not unique image/event counts. The next was 242.9 MiB, with a 95.3% base64-like fraction.

   Large payload representations were observed in both rollout files and the history projection. No effective size/retention bound was evident in this sample; the analysis does not establish that every payload is duplicated or that the product has no retention policy anywhere.

   Outcome: the user estimates roughly 50% improvement immediately after launch, but after opening multiple conversations the lag remains approximately 80–90% of its previous severity. These are subjective estimates. History truncation, logs VACUUM, and cache reduction were combined, so this is not a controlled single-variable benchmark.

   The history reduction was not lossless: tool-output records were truncated, and DSH's recursive pass also shortened four old tool-call argument fields. Pre-trim backups and original rollouts were retained; sessions were not stripped. DSH reported quick_check=ok, which establishes structural integrity, not unchanged content. This is diagnostic evidence, not a recommended purge/truncation workaround. Reduced file size persisted during observed subsequent use; that does not guarantee no future backfill/migration.

   5. Interpretation and engineering request

   There are two distinguishable observations: reduced local-data size improved initial responsiveness, while severe within-run degradation and Settings delays persisted. Reduced read/parse burden is a plausible explanation for the initial improvement, but read costs were not instrumented. Repeated synchronous key/state computation is a measured runtime lead; its precise accumulation mechanism remains open. The storage and computation factors may interact.

   Please instrument the 1st, 5th, and 9th opened-conversation stages, including a Settings subsection click at each stage, and correlate each interaction with:

   • $0n/Nls key-call count, total time, cache hit/miss, parameter node/byte count, resulting key length, and triggering component/store update;
   • loaded-conversation count, retained subscriptions/family bindings, and disposal after navigation;
   • main-thread long tasks, GC/heap, plus database read/parse time separately.

   Please investigate bounded stable-ID/version-based family keys and proper invalidation/disposal. Identity-only global WeakMap caching is not a validated drop-in fix.

   A reinstall workflow was prepared and tested for data preservation, but stopped while waiting for normal client exit; no uninstall, reinstall, or live restore occurred. It is currently shelved and supplies no performance A/B result. Earlier web comparisons were briefly responsive but are not prolonged benchmarks.

   Please provide a fix or a supported workaround that preserves conversations, projects, sidebar organization, plugins, and skills. Only aggregate evidence and installed bundle references are included here; no account identifiers, private chat contents, personal absolute paths, raw traces, or backup contents are attached.
8. zzzuuunnn6 commented on Oct 7, 2026

   

   zzzuuunnn6

   on Oct 7, 2026

   More actions

   Additional first-hand report: severe sidebar conversation-switching lag remains a separate unresolved problem on Windows, app 26.1002.52244 / build 13536.

   The affected user explicitly asks that general UI sluggishness be investigated independently of renderer crashes. Clicking between long-running development conversations is severely delayed, while other applications on the same computer behave normally. This is the user's observation; mouse-click-to-paint latency has not yet been instrumented.

   The earlier crash escalation already mentioned switching lag: #51313 (comment) . That report does not establish that every UI stall is an OOM event. I am adding this to the performance issue because the continuing interaction delay also needs its own diagnosis.

   Current environment and new observations

   • Windows 11 x64, version 10.0.26200; approximately 32 GB physical RAM and 16 logical processors.
   • Microsoft Store package OpenAI.Codex 26.1002.7124.0; installed package.json app version 26.1002.52244, codexBuildNumber=13536, prod.
   • The main desktop process has remained alive since 2026-10-07 20:53:55 UTC+08:00; the primary app-server since 20:54:06. The newest renderer started at 2026-10-08 00:27:13, immediately after another retained Crashpad sidecar.
   • New sidecars observed since the earlier escalation: October 7 at 23:30:39 and 23:40:03, October 8 at 00:16:19 and 00:27:13. Each says capture_kind=crash, ptype=renderer, osarch=x86_64. These are filesystem observation times, not native dump timestamps; no new current-build native OOM stack was obtained.

   Finite passive resource sample, October 8 00:29:24.527-00:29:57.549 UTC+08:00 (33.02 seconds):

   • Available physical memory: 14,476-14,552 MiB, approximately 14.14-14.21 GiB.
   • Largest sampled machine-wide physical disk read rate: 0.48 MiB/s.
   • Recently restarted renderer: private memory 574.7-581.9 MiB; average CPU approximately 48.5% of one core, or 0.49 core equivalents. This is not 48.5% of the whole 16-processor machine.
   • Main desktop process: approximately 472 MiB private memory; average 4.4% of one core; logical reads about 0.03 MiB/s.
   • Primary app-server: approximately 671 MiB private memory; average 3.9% of one core; logical reads about 1.10 MiB/s.

   This particular post-reload window did not show the earlier multi-GiB renderer pressure or a sustained physical-disk read loop. It also did not measure the user's clicks, so it cannot identify the blocking function or rule out transient stalls, GC, locks, network delays, or GPU/composition problems. A low average total CPU percentage does not exclude a blocked renderer main thread.

   Installed-source leads to profile, not claimed causes

   Read-only inspection of current app-shared-40678a67f0e3.js still finds:

   1. Mct computes JSON.stringify(Nct(parameters,...)) for array/plain-object family keys unless a custom key is supplied. Nct recursively copies objects in sorted-key order. Fct computes that key before checking its Map cache. This matches the general synchronous canonical-key pattern described in the separate October 5 follow-up here, but I have not captured this user's runtime arguments, call counts, or CPU profile. It is not established that this user's sidebar passes entire transcripts into those keys.
   2. A transcript-notification buffering path still uses JSON.stringify(e).length before deciding whether to clear the queued data after crossing its 262144 threshold. Native dumps from older builds pointed to transcript serialization, as documented in the linked escalation. That does not establish a current-build stack or a shared cause for the persistent switching lag.

   The installed UI includes Start Performance Trace / Stop Performance Trace and the native recorder enables the V8 CPU-profiler categories. Please confirm the supported recording procedure and what to capture while switching among existing long conversations and opening Settings. We need a safe procedure that does not restart or terminate active development tasks.

   Requested help

   Please investigate click-to-usable-content latency separately from renderer OOM recovery, correlating renderer long tasks and CPU stacks, canonical family-key calls/cache hits, retained conversation/view subscriptions, history read/parse time and GC. Please identify a build with a verified fix or a supported mitigation that preserves ongoing work and conversation history.

   The user authorized seeking official help. No conversation deletion/truncation, profile reset, live database write/VACUUM, signed-bundle modification, forced app restart, or active-task termination has been performed for this follow-up. Raw conversation content, account/thread identifiers, personal filesystem paths, credentials and native dumps are excluded from this public comment. New finite sample artifacts and source observations are retained locally.
9. Pao070707 commented on Oct 14, 2026

   

   Pao070707

   on Oct 14, 2026

   More actions

   Additional Windows reproduction: Recents → Chat causes global UI lag (6.6 s renderer stall)

   I reproduced a specific variant of this issue on the unified ChatGPT/Codex Windows desktop app.

   Environment

   • Windows 11 x64
   • Microsoft Store package: OpenAI.Codex 26.930.3930.0
   • ChatGPT in a browser and ChatGPT Classic are responsive.
   • The unified desktop app is severely sluggish when Chat items are displayed in the Recents sidebar.

   Reproduction / controlled comparison

   Sidebar configuration	Observed result
   Recents → Work only	Fast and responsive
   Recents → Chat only	Severe global UI lag
   Recents → All	Severe global UI lag
   Sidebar hidden	Much faster
   Project groups collapsed	Partial improvement
   Both project groups and Recents collapsed	Still slow

   Selecting Recents → Chat slows the whole app, including typing, scrolling, changing conversations, and other UI interactions. Switching back to Work-only restores responsiveness. Thus it is not limited to loading the body of a specific conversation.

   Built-in Perfetto performance trace

   I captured a trace using Help → Start Performance Trace while testing the fast/slow states. The local trace is about 227 MiB. A renderer main-thread input task contains:

   Nested event	Duration
   WidgetBaseInputHandler::OnHandleInputEvent	6,600.9 ms
   EventHandler::handleMouseReleaseEvent	6,600.8 ms
   EventDispatch	6,554.8 ms
   v8.callFunction	6,553.8 ms
   JavaScript FunctionCall	5,664.7 ms
   Following RunMicrotasks	889.1 ms

   These are nested events, not independent durations to add together. This provides direct evidence of a roughly 6.6-second renderer-main-thread input stall, with most time inside JavaScript dispatch/execution. GC also occurs, but is not sufficient to explain the majority of the stall.

   Other checks

   • App repair, application restart, and Windows restart did not resolve the issue persistently.
   • Microsoft Store offered no update.
   • The sampled processes did not show sustained CPU saturation.
   • No matching application crash/hang entries (event IDs 1000/1001/1002) were found in the inspected Windows Application log period.

   Interpretation and maintainer request

   This is consistent with a costly Chat-conversation sidebar render/state-processing path, potentially related to the serialization/sidebar behavior discussed earlier in this issue. However, the captured slices alone do not identify an application-level JavaScript function, so the exact root cause is not proven.

   Please investigate why displaying Recents → Chat makes the entire interface sluggish while Recents → Work remains fast, ideally without requiring deletion of history, projects, custom sections, or Codex sessions.

   I have not uploaded the raw .pftrace publicly because performance profiles may contain sensitive data. I can provide additional sanitized measurements or follow maintainer guidance for secure diagnostics.