Repository navigation
[macOS] Whole-window freezes recur after immediate relaunch; persistent access-denied chat hydration #53707
Description
Environment
- Codex desktop / ChatGPT macOS app, version 26.1007.30912, build 20156.
- macOS 27.2, build 26B5101f, Apple Silicon. Verified platform:
Darwin 27.2.0 arm64 arm. - Subscription tier: not collected for this report.
- Observations and local log review: October 13, 2026, Europe/Prague (UTC+2).
What happens
The entire application content window becomes unresponsive: typing and navigation stop working, while the native macOS menu bar remains usable. This occurs during chat use and with the integrated browser active. The expected behavior is for the content window to remain interactive, or to recover and display an error if a background operation fails.
The issue is intermittent and has required repeated app restarts on the same day. Relaunching immediately can result in another freeze. The user observes that waiting approximately 30 seconds before relaunching often helps, but this is not a controlled reproduction or proof that background processes are responsible.
The user progressively closes extra windows because he suspects they might contribute. Freezes continue despite closing them. This report does not establish a window-count threshold or a reliable workaround.
Reproduction
- Use the app normally for chats, sometimes with the integrated browser active.
- At an intermittent point, all content-window input and navigation stop responding.
- Terminate the app and relaunch. An immediate relaunch can become unresponsive again.
No deterministic trigger has been isolated. The exact onset of each freeze was not recorded, so log boundaries below must not be treated as freeze timestamps or a one-to-one count of incidents.
Focused findings from local logs
Two short app runs on October 13 have these first/last log timestamps:
| First log | Last log | Observed log span |
|---|---|---|
| 14:25:15.809 | 14:25:45.792 | About 30 seconds |
| 18:01:30.124 | 18:01:54.726 | About 25 seconds |
All times in this table are Europe/Prague (UTC+2). Both runs connect the local and remote app-server transports and end with explicit stop_process entries. Neither contains a ResizeObserver error or an iab backend request entry in the reviewed main-process logs. Their durations describe logged activity, not measured freeze durations.
A separate recurring finding is repeated background hydration of the same set of 16 conversations, rejected with thread access denied:
| Run, identified by first log time | Failed hydration requests | Distinct request IDs |
|---|---|---|
| 10:16:26.460 | 10,027 | 10,027 |
| 14:25:56.214 | 3,968 | 3,968 |
These counts cover each complete run's reviewed main-process logs, including rotated files. They are distinct failed requests, not duplicate log lines for one request. All counted failures have method=thread/read, source=thread_hydration, and error code -32003. The same 16 conversations also appear in both short runs and the subsequent functioning run. The reason for access denial is unknown.
Sanitized excerpt retaining only relevant fields; timestamp is UTC, equivalent to 14:25:33.228 Prague time:
2026-10-13T12:25:33.228Z
Request failed
method=thread/read
source=thread_hydration
error={"code":-32003,"message":"thread access denied"}
queueWaitMs=0
For these denied hydration requests, queue wait is almost always 0–1 ms, and the pending count is usually 1, falling to 0 at the end of a batch. This does not demonstrate an accumulating request backlog. Other startup requests wait several seconds, but comparable waits also occur during a functioning startup.
ResizeObserver loop completed with undelivered notifications appears in longer runs and in the later functioning run. Its absence from both short runs means it cannot currently be identified as the common cause. IPC/socket and checkout-webview errors cluster near shutdown and may be teardown effects.
Evidence limits and next diagnostic
- No main-process or renderer stack sample was captured during an actual freeze. Native-menu availability alone does not identify which process or thread is blocked.
- No concurrent record establishes that old app/helper processes overlap the next launch. The observation about waiting before relaunching remains unverified.
- A local resource monitor was restarted at 18:03:57 Prague time, after the earlier incidents; its subsequent measurements cannot establish resource pressure at those freezes.
- Existing older process samples were taken while the app was functioning and are not freeze evidence. They are not attached.
- No raw logs are attached. Conversation, account, and request identifiers, local paths, and authentication data have been omitted.
The next useful capture is a main-process and renderer sample while the content is frozen, before quitting, correlated with the exact time and the last UI action. The hydration retries are a concrete additional finding worth investigating, but this report does not establish that they cause the freezes.
Related reports
- [macOS] Desktop 26.1007.21159 repeatedly freezes; renderer at 100% CPU with live V8 stack sample #52532 describes overlapping macOS whole-window freezes in an earlier desktop build and includes a live renderer sample. This report adds October 13 observations from build 20156, short relaunch runs, and quantified hydration retries.
- [macOS Desktop] Orbit catalog treats access-denied hydration as retryable and repeatedly reloads 65 chats #53677 and [macOS Desktop] Persistent access-denied background hydration retries alongside high renderer CPU; restart does not resolve #53178 describe persistent access-denied hydration retries on macOS. The retry pattern overlaps; a shared cause of this report's whole-window freezes is not established. Please consolidate with an existing issue if appropriate.
Activity
github-actions commentedon Oct 13, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
alecvse commentedon Oct 15, 2026
Follow-up: samples captured during a real freeze on October 15
The user captured the app while its content window was frozen, before restarting it, twice approximately 18 seconds apart.
Environment and capture
Main-thread observations
These figures are the proportion of main-thread stack observations ending in
mach_msg2_trap, not CPU percentages. The application's dominant path passes through the native AppKit event loop (NSApplication run, event retrieval and Mach-message wait). The other sampled renderers also predominantly wait: at least 99.5% in seven of eight renderers in the first capture; the least-idle renderer in the second capture waits in 92.35% of its observations.There is no sustained CPU-bound JavaScript loop demonstrated on these sampled main threads. Mach-message waits also occur in normal idle event loops; they do not prove a deadlock, IPC failure or a specific blocked dependency. Exported framework symbol names with large offsets were not treated as reliable attribution of internal functions.
Important coverage limits
The capture script has now been expanded to include all renderers and GPU processes present at capture start, alongside the main app, with explicit success/failure records. A verification capture taken after restart is a healthy baseline, not additional freeze evidence.
Please investigate the whole-window input/state/rendering path with these waiting-thread observations in mind; the current samples do not identify a root cause.
alecvse commentedon Oct 19, 2026
October 19 follow-up: all renderers and GPU captured
Repeated serious UI stalls continued today. Logs through approximately 10:29 Europe/Prague show six fresh app starts after 09:15 (09:15:56, 09:22:46, 09:31:02, 10:03:54, 10:18:55 and 10:28:28). Start counts are not a measured freeze count.
A capture associated with the reported problems ran 10:28:00.924–10:28:05.197 CEST (UTC+2), before the latest restart:
This corroborates the October 15 waiting-thread pattern with fuller process coverage, in a newer app build. It does not show a sustained CPU-bound JavaScript loop or active GPU computation. Normal idle event loops also wait in these functions: the stacks do not establish deadlock, a GPU-driver fault, or which input/UI-state boundary is failing.
No explicit modal-dialog stack frames were found, but an asynchronous sheet, disabled UI state or input-routing failure is not excluded. The precise freeze onset and a timestamped input attempt were not recorded.
Next diagnostic preparation is a short passive macOS input/window-metadata probe, correlated with a click and modifier-key attempt. It will not read typed text or inject input. Observation at the macOS session boundary cannot itself prove delivery to or handling by the renderer; application-side instrumentation may still be necessary.
Only sanitized findings are included here; no raw samples, private paths, account/chat identifiers or conversation content are attached.