TL;DR:
ChatGPT freezes/hangs across Web, Windows, and Android apps. It happens in both short and long chats, but is far more likely when my account has very long chats in history. Reloading from the tray only works if the model is mid-generation; otherwise only fully exiting the app gives me a brief window of usability. Reproducible across fresh Windows installs (before/after an MBR wipe) and on Android. Looks like a rendering/state management bug tied to long conversation trees and lazy loading.
Summary
Chats intermittently freeze or become extremely sluggish across the web, Windows desktop, and Android apps. The issue is reproducible in both long and short chats, but seems more likely when the account has one or more very long (“heavy”) chats in history that may be partially/lazily loaded. Once a freeze occurs, right-click → “Reload” in the Windows tray only helps if the assistant is still actively generating; otherwise the session remains hung. Fully quitting and relaunching sometimes restores limited responsiveness for 1–2 messages, but freezes often recur—especially if the user opens or scrolls near a heavy chat.
Environment
-
Account: Single user account with multiple long chats (thousands of lines each).
-
Platforms observed:
-
Web: Chrome on Windows 11 Pro (Build 26100) and latest stable. Also seen in other Chromium-based browsers.
-
Windows Desktop App: Current public build (Electron/Chrome shown in UA: Electron/37.2.6, Chrome/138.0.7204.185).
-
Android App: Current public build on recent Android (exact version not critical; happens across devices).
-
-
Network: Stable broadband; no VPN required to reproduce.
-
Assistant behavior: Large message streams (code blocks, long text), multi-turn chats.
Severity / Priority
-
Severity: High — frequent hangs block use across all clients.
-
Priority: P1 — core messaging is unreliable; users lose work time and trust.
Frequency
- Several times per day during active sessions. Repro rate increases with presence of long chats in history.
Steps to Reproduce (representative)
-
Use an account that contains at least one very long chat (thousands of lines, multiple large code blocks).
-
Open the app on any client (Web/Windows/Android).
-
Start a new chat and send a normal prompt (can be short).
-
Observe rendering: the typing indicator appears, then the UI begins to stream output slowly line-by-line.
-
During or after generation, navigate back to the conversation list, then:
-
Scroll the list so heavy chats come into viewport (triggering lazy-load),
-
Or click into a heavy chat and back out, then return to the new chat.
-
-
Send another message in the new chat.
Result: The UI intermittently locks up or becomes unresponsive (scroll jank, delayed keystrokes, stalled rendering). In Windows app, right-clicking the tray icon and selecting Reload only helps if the model is still generating; otherwise the freeze persists. Fully exiting and relaunching may restore responsiveness for 1–2 messages before freezing again, particularly if the heavy chat is visible or recently accessed.
Expected Behavior
-
Smooth, non-blocking rendering of streamed messages regardless of chat history size.
-
Conversation list virtualization should prevent old heavy threads from affecting current chat performance.
-
“Reload” should reinitialize the renderer/process reliably even when not actively generating.
Actual Behavior
-
UI freezes/hangs across platforms; keystrokes get “eaten”; scrolling and rendering stall.
-
Long chats in the account appear to impact performance even when the current chat is short.
-
“Reload” in tray is unreliable; only full app restart sometimes helps, temporarily.
Suspected Root Causes (hypotheses)
-
Inefficient virtualization/lazy loading of long conversation lists or message DOM trees causing main-thread work spikes when heavy chats enter viewport or are re-opened.
-
Large DOM / reconciliation churn from streaming long messages (e.g., per-token updates, syntax highlighting, math/code rendering) without batching or off-main-thread processing.
-
Renderer memory pressure (Electron/WebView/Android) leading to GC thrash or layout thrash when multiple large chats are in memory.
-
State hydration costs: rehydrating big chat trees on navigation may block the main thread.
-
Tray “Reload” not performing a full renderer reset in certain hung states.
Impact
-
Core messaging workflows are unreliable; users lose edits, can’t continue work, and must constantly restart.
-
Perceived instability reduces confidence in the product.
Temporary Workarounds (partial)
-
Avoid opening/scrolling near heavy chats; keep the conversation list filtered/short.
-
Use brand-new chats and resist navigating back to heavy threads during a session.
-
Fully exit the app (tray → Quit on Windows, force stop on Android, close all web tabs) and relaunch; may buy one or two usable messages.
Attachments / Diagnostics to Collect (suggested)
-
Web (Chrome): Performance profile (.json) 30–60s capturing freeze onset; Console logs;
chrome://gpureport. -
Windows app: Crash dumps if available; GPU/process info; Electron renderer logs; any
--enable-loggingoutput. -
Android: Logcat during freeze window; ANR traces; memory stats.
-
Account context: Count/size of the heaviest chats (rough order of magnitude) and whether frozen states correlate to viewing them.
Proposed Engineering Checks
-
Verify list virtualization for conversation sidebar and message panes; ensure unmounted items truly free memory.
-
Batch stream updates (debounce DOM writes; prefer innerHTML chunking over per-token node updates).
-
Move syntax highlighting/markdown/math to Web Workers/off-main-thread where possible.
-
Cap message render window (only N recent messages mounted); offer “Load older” with true unmount.
-
Instrument time-to-first-paint and long task (>50ms) metrics around navigation and stream rendering.
-
Ensure Reload does a full renderer teardown and state reset, not a light refresh.
-
Add “Safe Mode” toggle to disable heavy features (animations, code highlighting) for large threads.
Acceptance Criteria (fix validation)
-
Opening/scrolling past heavy chats no longer degrades a separate new chat.
-
No UI long tasks >50–100ms while streaming typical responses, even with heavy history.
-
“Reload” reliably restores an interactive session from a hung state.
-
Memory usage remains bounded and stable over a 30-minute active session involving 1–2 heavy chats.
Notes
User observation: “Completely exiting the web, Android or Windows app sometimes marginally improves performance for a chat message or two… coming back into new chats without clicking into a heavy chat performs marginally better, but sometimes also freezes in the early stages of the new chat.” This suggests lazy-loaded history or global state touching long threads is a contributing factor. Also: “Right clicking on tray icon and clicking reload only works if the chat hasn’t truly frozen and you are actually still thinking.”
Additional Context
-
The issue has been observed consistently across multiple Windows installations. It was present both on the user’s current Windows 11 Pro build (26100) and on the previous OS version before a major system event (“deleted my MBR” incident) that required a fresh reinstall.
-
This suggests the problem is not specific to local corruption, drivers, or one-time OS instability, but is instead inherent to the app’s rendering/state management.
System Specs (primary workstation)
-
OS: Windows 11 Pro build 26100 (also reproducible on prior Windows install, before MBR corruption/reinstall)
-
CPU: AMD Ryzen 5 3600X
-
Motherboard: ASUS PRIME X570-P
-
RAM: 128 GB DDR4
-
GPUs: NVIDIA RTX 5060 Ti + AMD RX 6700 XT (XFX Speedster SWFT 309 12GB)
-
Storage: Multiple NVMe + HDD, plenty of free space
-
Network: Stable broadband
Cross-device notes
-
Also reproducible on Android (current app build, recent OS)
-
Also reproducible in Chrome (latest stable) on Windows, not just the desktop app