Repository navigation
ChatGPT macOS 26.915.31945: Codex renderer repeatedly white-screens; Renderer reaches ~120% CPU #46641
Description
Summary
The current ChatGPT desktop app on macOS repeatedly gets stuck in the Codex view with a white page / centered logo. This happens frequently enough to block normal work.
Force-quitting only the high-usage Codex (Renderer) process in Activity Monitor immediately restores the Codex UI. The main ChatGPT app does not need to be quit.
Environment
- ChatGPT desktop app: 26.915.31945
- macOS: 26.6.2 (25G83)
- Apple Silicon / ARM64
- Codex Renderer identifier:
com.openai.codex.helper.renderer - Codex Framework / Renderer version: 153.0.8010.48 (8010.48)
Observed behavior
While the UI is stuck on the white page / centered logo, Activity Monitor has shown:
Codex (Renderer)sometimes reaching ~120% CPUCodex (Service)around 37.5% CPU- other renderer processes around 26.2% and 10.5% CPU
Codex (Service)around 11% GPU
A macOS process sample taken from the affected renderer reported:
- Physical footprint: 3.2 GB
- Peak physical footprint: 4.7 GB
- Renderer had been running for only a few minutes when sampled
The sample shows heavy Chromium/V8 renderer activity, including V8 serialization/deserialization, compositor activity, GC/finalizer paths, PNG/EXIF-related work, etc.
Reproduction
- Open the current ChatGPT desktop app.
- Switch to / work in Codex normally.
- After some use, the Codex page frequently becomes white with the centered logo and never finishes loading.
- Leave the ChatGPT app open.
- Open Activity Monitor.
- Force quit only the active/high-usage
Codex (Renderer)process. - The Codex page immediately returns to normal.
The problem then comes back again later during normal use.
Expected behavior
Codex should not enter a renderer state where the UI stops painting and remains on a white/logo screen.
If the renderer encounters an unrecoverable UI state, it should restart/recover automatically instead of requiring the user to kill the renderer process manually.
Impact
This happens repeatedly and makes the desktop Codex workflow unreliable for sustained work.
Diagnostic signal
The strongest signal is that killing only Codex (Renderer) fixes the UI instantly, while the rest of ChatGPT/Codex stays alive.
Combined with:
- renderer CPU sometimes reaching ~120%
- 3.2 GB current / 4.7 GB peak renderer memory footprint
this looks consistent with a renderer-side hang and possibly a runaway loop and/or memory-growth issue.
A full macOS sample report is available if maintainers want it.
Activity
github-actions commentedon Sep 19, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Bibbo24 commentedon Sep 19, 2026
Update: the problem has escalated beyond renderer white-screen hangs.
On the same affected setup (ChatGPT desktop 26.915.31945, macOS 26.6.2, Apple Silicon), the entire ChatGPT app has now unexpectedly quit/crashed 3 times during normal use.
This is in addition to the previously reported recurring Codex Renderer hangs where the UI turns white / shows the centered logo and the Renderer can reach ~120% CPU.
The app-level crashes make the desktop workflow significantly more disruptive because they terminate the whole ChatGPT process rather than only leaving the Codex renderer stuck.
If maintainers need it, we can provide the macOS crash report / DiagnosticReports entry from one of these unexpected quits.
Bibbo24 commentedon Sep 19, 2026
Additional discriminator from the affected user: the issue reproduces on the Mac mini, but not on the MacBook. This makes the problem look more machine/environment-specific rather than purely account/model/server-side.
On the affected Mac mini, the renderer has shown the previously reported high CPU / memory growth and white-screen recovery when only Codex (Renderer) is killed. The user's MacBook does not show the same behavior.
This may be useful for narrowing investigation toward local renderer/compositor/GPU/display state, machine-specific app state, or hardware/OS differences. Exact MacBook hardware/app-version comparison can be provided if needed.
Bibbo24 commentedon Sep 19, 2026
Further comparison: the user's MacBook is running the exact same ChatGPT desktop build, 26.915.31945 (released Sep 18, 2026), but does not reproduce the white-screen / high-CPU renderer problem. The issue currently reproduces only on the Mac mini. This strongly suggests a machine-specific trigger (local profile/state, display/GPU/compositor, or hardware/OS environment) rather than the app build alone.
Bibbo24 commentedon Sep 19, 2026
New local-profile diagnostics from the affected Mac mini show a very large Codex state directory:
~/.codex/sessions/2026/05/03/rollout-2026-05-03T21-42-53-019def5d-79ac-72f2-8205-f89243e2f2bc.jsonl), modified again on Sep 19 during the incident windowthread_history_1.sqlite: 1.5 GBlogs_2.sqlite: 234 MB~/Library/Caches/Codex: 595 MBOther rollout files are much smaller (roughly 55–314 MB), so the 5.7 GB rollout is a strong outlier. System memory at the time showed no swap use and no obvious global memory-pressure signal. Two ChatGPT crash reports were also generated on Sep 19 within minutes of each other.
This may explain why the issue is Mac-mini-specific despite the MacBook running the exact same ChatGPT build: the affected Mac mini has unusually large local Codex state/history. Next diagnostic step is to temporarily move the 5.7 GB rollout out of ~/.codex (reversible backup) and retest.
Bibbo24 commentedon Sep 19, 2026
Correction/clarification: the 5.7 GB rollout JSONL in
~/.codex/sessions/...was intentionally created/maintained by the user to support working on the same projects across multiple computers. It should therefore not be treated as an unexplained Codex-generated growth anomaly by itself. Moving it out caused the app to show an 'unable to restore' error because the current session still references it, so it has been restored to its original location. The renderer white-screen / high-CPU / crash issue still reproduces on the Mac mini and not on the MacBook running the same app build.Bibbo24 commentedon Sep 19, 2026
Crash-report analysis from the affected Mac mini adds a reproducible crash signature.
Two ChatGPT crash reports from Sep 19:
Both are ChatGPT 26.915.31945 (build 9922) on macOS 26.6.2 (25G83), Apple Silicon, and both terminate with:
EXC_BREAKPOINTSIGTRAPTrace/BPT trap: 5The two crashes have the same top Codex Framework stack signature, including identical offsets through:
ares_llist_replace_destructorreading_mode...parse_distilled_htmlv8::Isolate::Enter()ChromeMainThis is not a generic macOS out-of-memory termination; it is a deliberate breakpoint/trap in the Chromium/Codex main-thread path.
The user has also just reproduced the white screen with centered logo again, after a full Mac mini shutdown/restart and launching only ChatGPT. The same app build on the user's MacBook does not reproduce the issue.
The raw .ips reports are preserved and can be supplied if maintainers want them.
Bibbo24 commentedon Sep 19, 2026
Additional reproduction result: the affected Mac mini has now been upgraded to macOS 27, and the same Codex white-screen / centered-logo failure still occurs. The user's MacBook does not reproduce the issue. Both machines are using ChatGPT desktop 26.915.31945. This makes the prior macOS 26.6.2 installation very unlikely to be the root cause and further points to a Mac-mini-specific local profile/state, display/GPU/compositor, or machine-specific trigger.
Bibbo24 commentedon Sep 19, 2026
Strong isolation result: on the same affected Mac mini, a newly created macOS user account runs ChatGPT/Codex normally using the exact same ChatGPT account. Returning to the original macOS user reproduces the white-screen problem. This strongly localizes the trigger to per-user local state/profile data on the Mac mini (Electron/Chromium profile, caches, local storage, persisted UI state, etc.), rather than the ChatGPT account, model selection, macOS version, or Mac mini hardware itself.
Bibbo24 commentedon Sep 19, 2026
Further isolation: moving
~/Library/Application Support/OpenAI/Codexout of the original macOS user profile did not fix the issue; the Codex view still white-screened. Earlier resets of the main Codex Application Support/Caches/Preferences also did not fix it. A fresh macOS user on the same Mac mini still works normally with the same ChatGPT account and same app build. The remaining high-value suspect is per-user state under~/.codex(especially.codex-global-state.json/ persisted UI state), which has not yet been reset because the user relies on the session files for cross-computer work.Bibbo24 commentedon Sep 19, 2026
Correction to the previous update: after moving
~/Library/Application Support/OpenAI/Codex, the Codex view did show the white/logo screen, but it recovered by itself after a few seconds. This may have been transient first-launch/profile-rebuild behavior rather than the same persistent hang. Need to observe whether the repeated long white-screen / high-CPU / crash behavior returns during normal use before concluding that this reset did not help.Bibbo24 commentedon Sep 19, 2026
Follow-up: after moving
~/Library/Application Support/OpenAI/Codex, the white/logo screen initially recovered once, but the persistent failure returned immediately afterward and has now remained stuck for >30 seconds. So the profile-support reset did not resolve the underlying issue. Given that a fresh macOS user on the same Mac mini works with the same ChatGPT account/build, the next isolation target is per-user persisted Codex state under~/.codex, especially.codex-global-state.json/.bakand stale temp state files, while preserving the user's large session/project files.Bibbo24 commentedon Sep 19, 2026
New per-user state analysis strongly narrows the suspect area.
~/.codex/.codex-global-state.jsonis ~1.2 MB and itselectron-persisted-atom-statealone is ~1.28 MB. Two persisted atoms account for ~90% of that state:mcp-extension-sidebar-catalog~620.9 KB andmcp-server-tools-cache-v2~528.8 KB. The next targeted test is to back up the global-state files and remove only those two cache-like persisted atoms, preserving sessions/projects and all other state.Bibbo24 commentedon Sep 19, 2026
Targeted removal of
mcp-extension-sidebar-catalogandmcp-server-tools-cache-v2from~/.codex/.codex-global-state.jsondid not resolve the issue; the persistent white/logo hang returned. Since a fresh macOS user on the same machine works and multiple per-user Application Support/cache/global-state resets have failed, the next decisive A/B test is a completely fresh~/.codexdirectory (temporarily renaming the existing one intact), then restoring it afterward.Bibbo24 commentedon Sep 19, 2026
Important A/B result: after temporarily replacing the original
~/.codexwith a completely fresh empty~/.codex(old folder preserved intact as~/.codex-backup-test), Codex on the affected macOS user now appears to be working normally. This strongly points to something inside the original~/.codexstate/data as the trigger, rather than the account, app install, OS, or hardware. We are keeping the old folder untouched for controlled recovery of projects/sessions.Bibbo24 commentedon Sep 19, 2026
Confirmed: with a freshly created
~/.codexon the original affected macOS user, Codex is now stable and functioning normally. The failure is therefore isolated to something inside the previous~/.codexcontents. The old folder remains preserved as~/.codex-backup-testfor selective recovery; we will avoid restoring global/UI/runtime temp state wholesale.Bibbo24 commentedon Sep 19, 2026
Additional timing clue from the preserved failing
~/.codex: the only top-level items modified immediately before the reported onset on Sep 18 werepluginsat 21:02:20 andchrome-native-hosts-v2.jsonat 21:02:21. Most Sep 19 timestamps are from subsequent troubleshooting/rebuild activity. This lines up with the user's recollection that the problem began after a credits/limit-related reinitialization and further strengthens suspicion around per-user plugin/browser/computer-use state rather than the core runtime (which diagnosed cleanly).Bibbo24 commentedon Sep 19, 2026
Stronger correlation found in the preserved failing profile: the very large rollout
sessions/2026/05/03/rollout-2026-05-03T21-42-53-019def5d-79ac-72f2-8205-f89243e2f2bc.jsonlis ~6.12 GB and was still being modified on Sep 19 at 23:24. The same conversation ID019def5d-79ac-72f2-8205-f89243e2f2bcappears in persisted thread-tab routing state and in earlier browser-use logs where the app reportsTimed out waiting for the Browser webview to attach for this browser-use page. This makes that giant long-lived thread/browser state a prime suspect. Separate short ~30 KB rollout files begin at 21:02 on Sep 18, immediately afterpluginsandchrome-native-hosts-v2.jsonwere modified, matching the user's recollection of a credits/limit reinitialization.xiaoxiaozhutizi commentedon Sep 20, 2026
我也遇到了类似的问题，APP卡死了三次了。
monterourena commentedon Sep 20, 2026
Still occurring for me as of September 20, 2026. I am also experiencing recurring white/blank screens and UI hangs in the ChatGPT/Codex macOS desktop app, disrupting normal use.
Environment available for this report: macOS, arm64. My desktop client metadata identifies
Codex Desktop/26.915.31945; the separate build number and exact macOS version have not been checked in About.This confirms the user-visible symptoms, not the original report's CPU/memory measurements, crash signature, or recovery result from terminating the renderer. I have not independently collected those diagnostics or validated the workarounds discussed above on my machine.
I also encounter disappearing conversation content (#46424) and unstable scrolling/large blank areas (#37849). Their co-occurrence does not establish a shared root cause.
Please advise on a supported recovery procedure that preserves existing conversations and project state, and identify any desktop release containing a fix. What minimal diagnostics should be submitted through the private feedback channel? No private conversation content, session files, or logs are attached here.
xiaoxiaozhutizi commentedon Sep 20, 2026
haltlos commentedon Oct 17, 2026
Additional evidence: sustained >200% CPU and 3.2 GB footprint after ChatGPT Work completion (macOS)
I'm seeing a related but not identical problem: the ChatGPT UI remains usable, but Codex (Renderer) continues using >200% CPU for at least 30 minutes after a Work task is marked finished. This has happened repeatedly after Work tasks; I do not yet have deterministic reproduction steps.
Environment
26.1013.4093426.7.1 (25G241)155.0.8059.80(com.openai.codex.helper.renderer)Observed (October 17, 2026)
20463, parentChatGPTPID20436; started22:31:41 +0200; sampled23:40:33 +0200.DedicatedWorker threads (21373794and21373796) were active across all 2,138 samples in the call graph, with stacks passing through V8 into unsymbolicated code. The main thread was predominantly waiting inmach_msg2_trap. This is consistent with persistent worker activity, but the sample does not identify the exact task or prove a memory leak.Workaround / outcome
I terminated only the high-CPU
Codex (Renderer)process in macOS Activity Monitor (after the Work task had completed). It restarted automatically; the main ChatGPT app remained running:This resolved the excessive resource use immediately without restarting ChatGPT. The similarity to this issue is the high renderer footprint and successful recovery after restarting the renderer, not a white-screen UI failure (I did not observe one).
I captured a complete macOS Activity Monitor
samplereport and can provide it if maintainers would find it useful.Expected: Once a Work task is finished, workers no longer needed should settle to idle and unnecessary memory should be released.
Update — October 18, 2026: When generated workbook cards are omitted from completion messages in ChatGPT Work, I no longer observe the persistent rise in Codex Renderer CPU and memory usage. The workbook files are still generated and saved.
This suggests that workbook cards or their previews may be involved, but it is an informal observation, not a controlled test or a confirmed cause. No new CPU or memory measurements were collected.
xiaoxiaozhutizi commentedon Oct 17, 2026