macOS: repeated Codex crashes, high CPU and severe heating; CPU spikes persist after updating to 26.901.51231 (8109)

What version of the Codex App are you using (From “About Codex” dialog)?

26.901.41600 (build 7982) and 26.901.51231 (build 8109)

What subscription do you have?

Pro

What platform is your computer?

Darwin 24.6.0 arm64 arm

What issue are you seeing?

macOS: repeated Codex crashes, high CPU and severe heating; CPU spikes persist after updating to 26.901.51231 (8109)

Summary

During a long-running game-development task in Codex Desktop, the app repeatedly froze or crashed. I also experienced severe system slowdown, significant heating/overheating, and occasions when the whole Mac appeared to freeze or crash.

I associate the onset with the agent starting browser/computer-use work, although this is not a confirmed root cause. Three captured native crash reports show two separate signatures: two main-app crashes on Chrome_IOThread, and one computer-use helper crash in an accessibility notification observer.

I updated from 26.901.41600 (build 7982) to 26.901.51231 (build 8109). CPU usage initially seemed better after the update, but then rose again, with Activity Monitor showing one Codex renderer at 132.8%, the main ChatGPT process at 106.2%, and another Codex renderer at 66.6% in the same screenshot. The Mac is getting very hot.

Evidence distinction: the attached application crash reports are from the previous version. High CPU and heating have recurred after updating; this report does not include a native crash log from build 8109 or a kernel panic report proving the cause of a whole-machine failure.

This report was prepared with the agent from my observations, screenshots, the supplied macOS crash reports, and lightweight local version/hardware reads. Suspected causes are labeled separately from observed facts.

Environment and versions

Item	Value	Evidence
OS at captured crashes	macOS 15.7.3 (24G419)	All three crash reports
Hardware identifier	Mac14,9	Local sysctl read
Processor	Apple M2 Pro	Local sysctl read
RAM	16 GiB / 17,179,869,184 bytes	Local sysctl read
Architecture	ARM-64, native	Crash reports
Previous app version	26.901.41600 (7982)	Both main-app crash reports
Installed app version after update	26.901.51231 (8109)	/Applications/ChatGPT.app/Contents/Info.plist
App bundle identifier	com.openai.codex	Crash reports and installed app plist
Main executable/process name	ChatGPT	Crash reports; installed under /Applications/ChatGPT.app
Computer-use helper at captured crash	SkyComputerUseService 26.831.1000926 (1000926)	Helper crash report
Helper identifier	com.openai.sky.CUAService	Helper crash report
System Integrity Protection	Enabled	All three crash reports
Time zone in captured crash reports	UTC+01:00	Report timestamps
Agent selected for the task	GPT-6 Astra	Task context; not evidence of which desktop component failed

The helper version above is the version at its recorded crash. Its version inside the updated app has not been checked.

Impact

• Repeated interruptions and loss of an active agent turn, requiring app restarts and requests to resume.
• App freezes/crashes during work, with severe slowdown affecting the rest of the Mac.
• The Mac becomes very hot; overheating is a user observation, not a recorded temperature measurement or a confirmed thermal shutdown.
• I have also reported apparent whole-computer freezes/crashes. No kernel panic log or system-wide diagnostic capture has been analyzed, so the cause and exact nature of those events remain unconfirmed.
• Continuing browser testing became impractical because of the instability.

Task and browser context

The agent was building and testing a web-based strategy game in a long, tool-heavy task with screenshots, attachments, search results, and substantial conversation history. The work included local development, browser interaction, a WebGL/Three.js scene, Blender asset creation, and deployment. Both the Codex in-app browser and external Chrome were used during the broader task. A local preview at http://localhost:3001/ was open during parts of the session.

Browser/computer-use operations encountered connection failures and interruptions during the broader session. There is not yet a timestamp-correlated browser lifecycle log establishing which operation immediately preceded each native crash.

By the latest diagnostic pass, the game had already been deployed and tested, the local development server had been stopped, and the agent did not start another build, Blender process, or browser automation session. It performed lightweight file reads and a web-search tool call. CPU spikes nevertheless recurred. That search returned a large text result shortly before I reported the renewed spike; there is no evidence proving that rendering this result caused it.

Avoiding new browser actions did not prevent the latest recurrence. This does not establish whether an existing browser surface, a lingering helper, conversation rendering, or some other component remained involved.

Timeline

Times below are from the crash reports where available. Other events are ordered from the conversation and do not have independently verified wall-clock timestamps.

1. During the broader development task, the Mac initially ran out of disk space. I freed substantial space and resumed. Available disk space at each later crash was not measured, so the earlier disk-full event should be treated as background context, not an established explanation.
2. I repeatedly reported app crashes and asked the agent to resume. I noticed a pattern of high CPU, freezing, and heating, and suspected it began with browser work.
3. 2026-09-05 23:14:59.8738 +0100: SkyComputerUseService crashed in AXNotificationObserver for pid 10069 with a null-address EXC_BAD_ACCESS.
4. 2026-09-05 23:25:33.7726 +0100: main app ChatGPT, version 26.901.41600 (7982), crashed on thread 18, Chrome_IOThread, with EXC_BREAKPOINT (SIGTRAP).
5. 2026-09-05 23:40:50.5619 +0100: another main-app instance on the same version crashed on thread 18, Chrome_IOThread, with the same exception and matching leading framework symbol offsets.
6. I updated the app. The installed plist now reports 26.901.51231 (8109). Initially I said it seemed to have stopped CPU-spiking.
7. While the agent was investigating using file reads and web search, without restarting browser automation or a build, I reported another spike and supplied the Activity Monitor screenshot summarized below.
8. The agent saved a recovery checkpoint and paused work. I then reported that the Mac was really overheating and requested this report.

The helper crash report lists parent ChatGPT [2845], which is the same PID as the main app that crashed about 10 minutes 34 seconds later. This establishes a parent-process relationship for those two reports, not a proven causal chain.

Activity Monitor evidence

These are readings from two user-supplied screenshots, not a continuous profile. Exact screenshot capture times and the app version represented in the earlier screenshot are not independently verified. On macOS, process CPU percentages can exceed 100% when more than one CPU core is used.

Process	Earlier screenshot: CPU	Latest screenshot, supplied after update: CPU
Codex (Renderer), PID 40161	98.8%	132.8%
ChatGPT, PID 39056	69.1%	106.2%
Codex (Renderer), PID 40096	43.3%	66.6%
BDLDaemon	97.0%	51.1%
contactsd	65.2%	Not visible in supplied crop
AddressBookManager	45.4%	Not visible in supplied crop
WindowServer	Not visible in supplied crop	46.7%
kernel_task	Not visible in supplied crop	22.4%
Codex (Service)	Not visible in supplied crop	9.0%
Google Chrome Helper (Renderer)	Not visible in supplied crop	4.6%

The latest screenshot also shows WindowServer at 23.2% GPU and Codex (Service) at 12.3% GPU. Other processes were consuming appreciable resources too, so this evidence does not attribute every aspect of the system load or heating exclusively to Codex.

The same main-app/renderer PIDs appear in both screenshots. They should not be presented as a controlled before/after-update comparison. What is established is that the latest screenshot was supplied after I reported updating, and the installed app version was then verified locally.

Native crash evidence

A. Main app — first captured crash

Process:            ChatGPT [2845]
Identifier:         com.openai.codex
Version:            26.901.41600 (7982)
Code Type:          ARM-64 (Native)
Parent Process:     launchd [1]
Date/Time:          2026-09-05 23:25:33.7726 +0100
OS Version:         macOS 15.7.3 (24G419)
Crashed Thread:     18  Chrome_IOThread
Exception Type:     EXC_BREAKPOINT (SIGTRAP)
Exception Codes:    0x0000000000000001, 0x0000000118f6540c
Termination Reason: Namespace SIGNAL, Code 5 Trace/BPT trap: 5

B. Main app — second captured crash

Process:            ChatGPT [13053]
Identifier:         com.openai.codex
Version:            26.901.41600 (7982)
Code Type:          ARM-64 (Native)
Parent Process:     launchd [1]
Date/Time:          2026-09-05 23:40:50.5619 +0100
OS Version:         macOS 15.7.3 (24G419)
Crashed Thread:     18  Chrome_IOThread
Exception Type:     EXC_BREAKPOINT (SIGTRAP)
Exception Codes:    0x0000000000000001, 0x000000011cf4140c
Termination Reason: Namespace SIGNAL, Code 5 Trace/BPT trap: 5

Both main-app crashed-thread stacks begin with these same reported symbol offsets (absolute addresses differ):

Codex Framework
node::inspector::protocol::BinaryValue::asBinary(node::inspector::protocol::Binary*) const
  frame 0: + 17628168
  frame 1: + 17628192
  frame 2: + 17628220
  frame 3: + 17640960
  frame 4: + 17629444
cxxbridge1$string$ptr
  frame 5: + 24148
  frame 6: + 19316

The very large offsets mean these reported symbol names should not be treated as precise source-level attribution. The matching thread, exception, and leading offsets are useful for crash grouping; they do not demonstrate that the named inspector function is the actual defect. Later stack frames differ.

C. Computer-use helper

Process:            SkyComputerUseService [3910]
Identifier:         com.openai.sky.CUAService
Version:            26.831.1000926 (1000926)
Code Type:          ARM-64 (Native)
Parent Process:     ChatGPT [2845]
Date/Time:          2026-09-05 23:14:59.8738 +0100
OS Version:         macOS 15.7.3 (24G419)
Crashed Thread:     10  AXNotificationObserver for pid 10069
Exception Type:     EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:    KERN_INVALID_ADDRESS at 0x0000000000000000
Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11

Leading crashed-thread frames:

0  ???                 0x0 ???
1  HIServices          _XPostNotification + 352
2  HIServices          mshMIGPerform + 208
3  CoreFoundation      __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 60
4  CoreFoundation      __CFRunLoopDoSource1 + 508
5  CoreFoundation      __CFRunLoopRun + 2200
6  CoreFoundation      CFRunLoopRunSpecific + 572
7  CoreFoundation      CFRunLoopRun + 64
8  SkyComputerUseService  0x104f50000 + 7652440
9  SkyComputerUseService  0x104f50000 + 7652504
10 Foundation          __NSThread__start__ + 732
11 libsystem_pthread   _pthread_start + 136
12 libsystem_pthread   thread_start + 8

The observed target process for PID 10069 has not been identified. This is direct evidence of an accessibility-observer crash in the computer-use helper, not proof that a particular browser tab or website caused it.

Reproduction status

No safe, minimal, deterministic reproduction has been isolated. The observed sequence is:

1. Run a long Codex Desktop coding task on this Mac.
2. Include browser/computer-use work against a local web application and external pages.
3. Continue the task through browser operations and substantial conversation/tool output.
4. Observe high CPU, severe heating, UI slowdowns, and intermittent native crashes.
5. Restart and resume; the problem can recur.
6. Update to 26.901.51231 (8109); an initial apparent improvement is followed by renewed high CPU, including during a pass with no new browser automation.

This is an observed workflow, not a claim that every step is necessary or sufficient. No deliberate stress reproduction was run after the overheating report.

Mitigations and other relevant history

• Restarted the app repeatedly, including after granting requested permissions.
• Freed disk space after an earlier disk-full interruption.
• Updated the desktop app to 26.901.51231 (8109). This has not eliminated the observed CPU spikes.
• Stopped starting new browser automation, Blender work, or builds during investigation. The latest CPU spike still occurred.
• Saved the project state and paused the active task to avoid adding load.
• Did not disable SIP/Gatekeeper, remove quarantine attributes, apply broad permission changes to computer-use directories, wipe app caches, or kill the current app-server as a diagnostic workaround.

There was also an earlier, separate macOS warning that a codex executable contained malware and had been moved to Trash. The affected Homebrew-prefix npm CLI was old (0.114.0); it was replaced with the official npm CLI 0.153.4 and the replacement binary passed code-signature verification. The desktop app also passed signature/notarization checks before the latest update. These checks do not prove the cause of the earlier warning, and the original removed executable was unavailable for independent analysis. No causal link between that warning and the CPU/native crash problem has been established. OpenAI's macOS signing incident explanation is relevant background, not a diagnosis of this machine.

Related issue and release-note status

openai/codex#32399 describes a browser-attachment crash on an older desktop build. It is marked closed. Its documented main-app signature is EXC_BAD_ACCESS on CrBrowserMain, whereas my two main-app reports show EXC_BREAKPOINT on Chrome_IOThread. My separate helper crash is also in a different process/thread. The browser context makes the issue relevant, but these should not be assumed to be identical defects.

An exact-version search of OpenAI documentation/help domains did not locate release notes identifying a CPU or crash fix in 26.901.51231. This is an inability to verify a fix, not evidence that the release contains no fixes.

What is still unknown / requested investigation

• What caused the matching Chrome_IOThread traps in build 7982?
• Is the helper's null-address accessibility callback failure related to the later main-app crashes?
• Which components account for the persistent renderer/main-process CPU use after updating?
• Could an existing browser surface, helper lifecycle issue, or rendering of a long task contribute? These remain hypotheses; no thread-leak, retry-loop, or out-of-memory cause has been demonstrated.
• Does build 8109 contain a relevant fix, and is this a known unresolved or separate problem?
• What targeted, low-overhead diagnostic would help maintainers most without repeatedly exposing the machine to severe load and heating?

No temperature trace, continuous CPU profile, current hot-process stack sample, full memory-pressure trace, or kernel panic analysis is included. These limits matter when interpreting the observations.

Supporting files

Three macOS crash reports and two relevant Activity Monitor screenshots are available locally. This report includes selected technical excerpts and omits the local username, personal project paths, session identifiers, and complete raw diagnostic dumps. A companion CODEX-CRASH-EXCERPTS.txt contains the selected headers and complete crashed-thread stacks from all three reports. The original screenshots contain the account username in Activity Monitor, so I have not included them in the shareable report bundle.

Prepared 2026-09-06. Nothing has been posted to GitHub by the agent.

What steps can reproduce the bug?

Reproduction status

No safe, minimal, deterministic reproduction has been isolated. The observed sequence is:

1. Run a long Codex Desktop coding task on this Mac.
2. Include browser/computer-use work against a local web application and external pages.
3. Continue the task through browser operations and substantial conversation/tool output.
4. Observe high CPU, severe heating, UI slowdowns, and intermittent native crashes.
5. Restart and resume; the problem can recur.
6. Update to 26.901.51231 (8109); an initial apparent improvement is followed by renewed high CPU, including during a pass with no new browser automation.

This is an observed workflow, not a claim that every step is necessary or sufficient. No deliberate stress reproduction was run after the overheating report.

What is the expected behavior?

App not crashing

Additional information

No response

Read the captured native crash reports and /Applications/ChatGPT.app/Contents/Info.plist first, then compare the 7982 and 8109 evidence while profiling the ChatGPT, Codex Renderer, and SkyComputerUseService processes in Activity Monitor. Done means a safe, deterministic reproduction and evidence that the recurring crashes and post-update CPU and heating behavior are resolved.