Codex Desktop long-running goal caused 137GB disk writes, WindowServer/FileProvider/CoreSpotlight load, and macOS hard reboot

Summary

A long-running Codex Desktop session on macOS appears to have generated extremely high local disk-write activity from the bundled codex process, followed by WindowServer / FileProvider / CoreSpotlight resource reports and a system-wide freeze severe enough that I had to force-reboot the Mac.

This does not look like memory pressure. Activity Monitor showed green memory pressure, memory_pressure reported no swap pressure, and local diagnostics show the strongest signals in disk writes, WindowServer CPU/compositing, FileProvider, and CoreSpotlight.

Environment

• App: Codex Desktop for macOS
• Codex version: 26.602.40724
• Codex build: 3593
• macOS: 26.5.1 build 25F80
• Hardware model: Mac17,6
• Architecture: Apple Silicon / arm64e
• RAM: 128 GB
• Framework observed in running process args: Codex Framework.framework/Versions/149.0.7827.54

What happened

A Codex goal/session ran for a very long time after scope/context got out of control. The UI reported the goal running for about 13h 49m.

Afterward, the whole system became severely laggy / frozen. Sometimes it recovered after quitting Codex; in this case I had to force-reboot the machine. I have seen a related symptom before where Moonlight streaming became very laggy and immediately improved after quitting Codex.

This time I inspected macOS diagnostic reports right after reboot.

Reboot / panic evidence

The forced reboot occurred around:

2026-06-07 10:04:44 +0800

last reboot recorded the reboot, but last shutdown did not record a normal shutdown. After boot, DumpPanic checked for panic data but did not find a panic log:

DumpPanic launched after boot to check for device panic data
AppleNVMeReadPanicLogData successfully extracted 3145728 bytes of data
3145728 bytes were read from the file or device, but it did not contain any paniclog data (buffer was all zeros)
No paniclog data found in local device

loginwindow also reported this was not treated as startup after panic/hard reset:

previousStartupWasPanicOrHardReset:0
This isn't a startup after panic, clear last login panic pref

So this does not look like a normal kernel panic report. It looks more like user-space/system services became unusable and the machine had to be forcibly restarted.

Codex disk-write resource report

macOS generated a resource report for the bundled codex process:

Diagnostic report:
/Library/Logs/DiagnosticReports/codex_2026-06-07-020740_MacBook-Pro.diag

Date/Time: 2026-06-06 15:40:11.272 +0800
End time:  2026-06-07 02:07:39.846 +0800
Command:   codex
Path:      /Applications/Codex.app/Contents/Resources/codex
Event:     disk writes
Action:    none
Writes:    137.44 GB of file backed memory dirtied over 37649 seconds
Average:   3650.58 KB/s
Footprint: 122.88 MB -> 158.38 MB, max 618.05 MB
Start:     2026-06-06 16:00:41.323 +0800
End:       2026-06-07 02:07:17.969 +0800

The heaviest stack in that report is dominated by write paths, including pwrite and fsync.

This is the strongest signal. The resource report spans the same overnight long-running Codex session.

WindowServer resource report before reboot

macOS also generated a WindowServer CPU resource report earlier that morning:

Diagnostic report:
/Library/Logs/DiagnosticReports/WindowServer_2026-06-07-084050_MacBook-Pro.cpu_resource.diag

Date/Time: 2026-06-07 08:37:52.970 +0800
End time:  2026-06-07 08:40:49.613 +0800
Command:   WindowServer
Event:     cpu usage
CPU:       90 seconds cpu time over 177 seconds, 51% average
Footprint: 1822.88 MB
On Behalf Of: 1 sample Codex (Service) (Codex)

The stack is in display update / Metal compositing paths, e.g. CGXUpdateDisplay, WS::Updater::UpdateDisplays, CompositorMetal::CompositeLayersToDestination, and QuartzCore rendering.

This aligns with user-visible symptoms: global macOS UI lag and Moonlight streaming lag.

FileProvider / CoreSpotlight immediately after reboot

Within about one minute after the reboot, macOS generated disk-write reports for CoreSpotlight and FileProvider.

CoreSpotlight:

Diagnostic report:
/Library/Logs/DiagnosticReports/corespotlightd_2026-06-07-100857_MacBook-Pro.diag

Date/Time:      2026-06-07 10:05:34.957 +0800
End time:       2026-06-07 10:08:56.733 +0800
Event:          disk writes
Writes:         2147.50 MB over 202 seconds, 10.64 MB/s average
Time Since Boot: 61s
Total CPU Time: 407.884s
On Behalf Of:   7 samples fileproviderd

FileProvider:

Diagnostic report:
/Library/Logs/DiagnosticReports/fileproviderd_2026-06-07-101040_MacBook-Pro.diag

Date/Time:      2026-06-07 10:05:35.168 +0800
End time:       2026-06-07 10:10:39.466 +0800
Event:          disk writes
Writes:         2147.48 MB over 304 seconds, 7057.17 KB/s average
Time Since Boot: 62s
Total CPU Time: 728.829s

Live process sampling after reboot also showed high CPU in:

corespotlightd  ~93-96% CPU
mds             ~44-46% CPU
WindowServer    ~40-44% CPU
fileproviderd   ~22-25% CPU

This looks like the system was doing heavy post-reboot cleanup/indexing/sync work after the Codex session.

Computer Use service crashes in the same session

There were also repeated Codex Computer Use service crash reports around midnight:

~/Library/Logs/DiagnosticReports/SkyComputerUseService-2026-06-07-000545.ips
~/Library/Logs/DiagnosticReports/SkyComputerUseService-2026-06-07-000617.ips
~/Library/Logs/DiagnosticReports/SkyComputerUseService-2026-06-07-000627.ips
... many more between 00:05 and 00:11

Representative metadata:

procName:      SkyComputerUseService
bundleID:      com.openai.sky.CUAService
parentProc:    Codex
coalitionName: com.openai.codex
exception:     EXC_BREAKPOINT / SIGTRAP
termination:   Trace/BPT trap: 5

The faulting thread includes AppKit/window APIs such as -[NSWindow windowNumber]. This may be a separate instability in Computer Use / Accessibility / window tracking, but it occurred during the same long-running Codex session.

Memory pressure was not the issue

During inspection after reboot:

Memory size: 128 GB
memory_pressure: System-wide memory free percentage: 66%
Swapins: 0
Swapouts: 0
Compressor pages: very low

So the failure mode appears to be disk writes / system service churn / WindowServer or UI compositing pressure rather than RAM exhaustion.

Expected behavior

A long-running Codex Desktop goal/session should not:

• dirty 137 GB of file-backed memory from the bundled codex process;
• keep system services such as FileProvider, CoreSpotlight, and WindowServer in high-load states;
• cause macOS-wide UI lag or Moonlight streaming lag;
• leave the machine in a state where force reboot is required;
• repeatedly crash SkyComputerUseService during the same long-running session.

Actual behavior

After a long-running Codex session:

• Codex generated a macOS disk-write resource report for 137.44 GB over ~10.5 hours.
• WindowServer generated a CPU resource report with Metal/compositing stacks and a large footprint.
• FileProvider and CoreSpotlight generated disk-write reports immediately after reboot.
• The system became severely laggy/frozen; force reboot was required.
• Memory pressure remained green / non-critical.

Related issues

This seems related to, but more severe than:

• #23026 - Codex Desktop long session keeps GPU process and WindowServer high
• #24185 - sustained high CPU/GPU/WindowServer load
• #25744 - Computer Use / MCP helper accumulation and WindowServer/TCC stalls
• #26795 - macOS system slowdown involving security/system services

This report adds a concrete Codex disk writes resource report (137.44 GB) tied to an overnight long-running goal, followed by hard-reboot-level system instability.

Privacy / attachments

I am not attaching raw diagnostic reports publicly because they may include local usernames, paths, process inventory, and private workspace details. I can provide redacted excerpts or raw reports privately if maintainers need them.