Skip to content

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

Closed
Closed
Codex Desktop long-running goal caused 137GB disk writes, WindowServer/FileProvider/CoreSpotlight load, and macOS hard reboot#26843
Labels
appIssues related to the Codex desktop appbugSomething isn't workingcomputer-useperformance

Description

@jason5545
jason5545
opened on Jun 7, 2026

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:

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    performance
    computer-use
    on Jun 7, 2026

  2. github-actions commented on Jun 7, 2026

    @github-actions
    github-actionsbot
    on Jun 7, 2026 – with GitHub Actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  3. jason5545 commented on Jun 7, 2026

    @jason5545
    jason5545
    on Jun 7, 2026 – with ChatGPT Codex Connector
    Author

    Adding sanitized diagnostic excerpts from the local reports. User/home paths and host-specific details are redacted where they are not needed for the bug.

    1. Codex disk-write resource report

    Source report:

    /Library/Logs/DiagnosticReports/codex_2026-06-07-020740_<HOST>.diag

    Extract:

    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 taken:     none
Writes:           137.44 GB of file backed memory dirtied over 37649 seconds (3650.58 KB per second average), exceeding limit of 1590.73 KB per second over 86400 seconds
Footprint:        122.88 MB -> 158.38 MB (+35.50 MB) (max 618.05 MB )
Start time:       2026-06-06 16:00:41.323 +0800
End time:         2026-06-07 02:07:17.969 +0800

    The heavy stack in the report is dominated by write-related paths, including pwrite, fsync, close, open, and unlink.

    2. WindowServer CPU resource report

    Source report:

    /Library/Logs/DiagnosticReports/WindowServer_2026-06-07-084050_<HOST>.cpu_resource.diag

    Extract:

    Date/Time:        2026-06-07 08:37:52.970 +0800
End time:         2026-06-07 08:40:49.613 +0800
Command:          WindowServer
Path:             /System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/Resources/WindowServer
On Behalf Of:     1 sample Codex (Service) (Codex) [33786] (1 sample originated by Codex (Service) (Codex) [33786])
Event:            cpu usage
Action taken:     none
CPU:              90 seconds cpu time over 177 seconds (51% cpu average), exceeding limit of 50% cpu over 180 seconds
Footprint:        1822.88 MB
Start time:       2026-06-07 08:37:58.415 +0800
End time:         2026-06-07 08:40:47.081 +0800

    The heavy stack is in display update / Metal compositing paths:

    CGXUpdateDisplay
WS::Updater::UpdateDisplays(...)
WS::Displays::SLCADisplay::render_update(...)
CompositorMetal::CompositeLayersToDestination(...)
CompositorMetal::composite(...)
MetalCompositeLayers
CARenderOGLRenderDisplayWithOptions
QuartzCore rendering

    3. CoreSpotlight disk-write report immediately after reboot

    Source report:

    /Library/Logs/DiagnosticReports/corespotlightd_2026-06-07-100857_<HOST>.diag

    Extract:

    Date/Time:        2026-06-07 10:05:34.957 +0800
End time:         2026-06-07 10:08:56.733 +0800
Command:          corespotlightd
Path:             /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/corespotlightd
On Behalf Of:     7 samples fileproviderd [767] (7 samples originated by fileproviderd [767]), 1 sample UNKNOWN [730] (1 sample originated by UNKNOWN [730])
Event:            disk writes
Action taken:     none
Writes:           2147.50 MB of file backed memory dirtied over 202 seconds (10.64 MB per second average), exceeding limit of 24.86 KB per second over 86400 seconds
Time Since Boot:  61s
Total CPU Time:   407.884s
Footprint:        6176 KB -> 82.22 MB (+76.19 MB)
Start time:       2026-06-07 10:05:35.235 +0800
End time:         2026-06-07 10:08:56.451 +0800

    Additional related samples in that report:

    Path:             /System/Library/Frameworks/FileProvider.framework/Support/fileproviderd
On Behalf Of:     1 sample fileproviderd [767] (1 sample originated by fileproviderd [767])
Start time:       2026-06-07 10:05:36.605 +0800
End time:         2026-06-07 10:08:56.073 +0800

Path:             /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mds_stores
On Behalf Of:     50 samples mds [363] (48 samples originated by mds [363], 2 samples originated by fileproviderd [767])
Start time:       2026-06-07 10:06:00.406 +0800
End time:         2026-06-07 10:08:32.272 +0800

    4. FileProvider disk-write report immediately after reboot

    Source report:

    /Library/Logs/DiagnosticReports/fileproviderd_2026-06-07-101040_<HOST>.diag

    Extract:

    Date/Time:        2026-06-07 10:05:35.168 +0800
End time:         2026-06-07 10:10:39.466 +0800
Command:          fileproviderd
Path:             /System/Library/Frameworks/FileProvider.framework/Support/fileproviderd
On Behalf Of:     3 samples fileproviderd [767] (3 samples originated by fileproviderd [767])
Event:            disk writes
Action taken:     none
Writes:           2147.48 MB of file backed memory dirtied over 304 seconds (7057.17 KB per second average), exceeding limit of 24.86 KB per second over 86400 seconds
Time Since Boot:  62s
Total CPU Time:   728.829s
Footprint:        10032 KB -> 20.23 MB (+10.44 MB) (max 21.25 MB )
Start time:       2026-06-07 10:05:36.605 +0800
End time:         2026-06-07 10:10:29.855 +0800

    Additional related samples in that report:

    Path:             /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/corespotlightd
On Behalf Of:     11 samples fileproviderd [767] (11 samples originated by fileproviderd [767]), 1 sample UNKNOWN [730] (1 sample originated by UNKNOWN [730])
Start time:       2026-06-07 10:05:35.235 +0800
End time:         2026-06-07 10:10:39.465 +0800

    5. Repeated Computer Use service crashes during the same long session

    Files observed locally, redacted:

    <HOME>/Library/Logs/DiagnosticReports/SkyComputerUseService-2026-06-07-000545.ips
<HOME>/Library/Logs/DiagnosticReports/SkyComputerUseService-2026-06-07-000617.ips
<HOME>/Library/Logs/DiagnosticReports/SkyComputerUseService-2026-06-07-000627.ips
<HOME>/Library/Logs/DiagnosticReports/SkyComputerUseService-2026-06-07-000635.ips
<HOME>/Library/Logs/DiagnosticReports/SkyComputerUseService-2026-06-07-000656.ips
<HOME>/Library/Logs/DiagnosticReports/SkyComputerUseService-2026-06-07-000703.ips
<HOME>/Library/Logs/DiagnosticReports/SkyComputerUseService-2026-06-07-000744.ips
<HOME>/Library/Logs/DiagnosticReports/SkyComputerUseService-2026-06-07-000809.ips
<HOME>/Library/Logs/DiagnosticReports/SkyComputerUseService-2026-06-07-000836.ips
<HOME>/Library/Logs/DiagnosticReports/SkyComputerUseService-2026-06-07-000912.ips
<HOME>/Library/Logs/DiagnosticReports/SkyComputerUseService-2026-06-07-000931.ips
<HOME>/Library/Logs/DiagnosticReports/SkyComputerUseService-2026-06-07-001000.ips
<HOME>/Library/Logs/DiagnosticReports/SkyComputerUseService-2026-06-07-001016.ips
<HOME>/Library/Logs/DiagnosticReports/SkyComputerUseService-2026-06-07-001112.ips

    Representative metadata from the first report:

    {"app_name":"SkyComputerUseService","timestamp":"2026-06-07 00:05:45.00 +0800","app_version":"1.0","build_version":"809","bundleID":"com.openai.sky.CUAService","bug_type":"309","os_version":"macOS 26.5.1 (25F80)","name":"SkyComputerUseService"}
"procLaunch" : "2026-06-06 08:53:16.8454 +0800",
"procName" : "SkyComputerUseService",
"parentProc" : "Codex",
"coalitionName" : "com.openai.codex",
"exception" : {"codes":"0x0000000000000001, 0x00000001005f0234","rawCodes":[1,4301193780],"type":"EXC_BREAKPOINT","signal":"SIGTRAP"},
"termination" : {"flags":0,"code":5,"namespace":"SIGNAL","indicator":"Trace/BPT trap: 5","byProc":"exc handler","byPid":34430},
"faultingThread" : 0,

    The faulting thread in the full report includes AppKit/window access such as -[NSWindow windowNumber].

    6. Reboot timing / non-panic signal

    Observed reboot time:

    kern.boottime: { sec = 1780797884, usec = 716888 } Sun Jun  7 10:04:44 2026

    last reboot showed:

    reboot time                                Sun Jun  7 10:04

    last shutdown did not show a normal shutdown entry for that reboot.

    Unified log around boot showed DumpPanic ran after startup but found no panic data:

    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

    This is why I suspect a user-space/system-service freeze followed by forced reboot rather than a standard kernel panic with a .panic report.

    7. Memory pressure note

    Memory pressure was green / non-critical. Local checks after reboot showed:

    Memory size: 128 GB
Swapins: 0
Swapouts: 0
System-wide memory free percentage: 66%

    So the issue is much more consistent with disk-write churn plus WindowServer/FileProvider/CoreSpotlight pressure than RAM exhaustion.

  4. jason5545 commented on Jun 7, 2026

    @jason5545
    jason5545
    on Jun 7, 2026 – with ChatGPT Codex Connector
    Author

    Reviewed the suggested duplicate #25744.

    I agree it is related, but I do not think this issue should be closed as a duplicate yet.

    #25744 is primarily about a long-running macOS session accumulating many stale helper processes and unreaped zombie children:

    • many SkyComputerUseClient mcp processes
    • many node_repl processes
    • many codex app-server --listen stdio:// children
    • 126+ zombie children under the main Codex process
    • WindowServer/TCC HID stalls

    This issue has a different primary failure signal:

    • macOS generated a codex disk-write resource report for the bundled /Applications/Codex.app/Contents/Resources/codex process;
    • that report shows 137.44 GB of file-backed memory dirtied over ~10.5 hours;
    • the heavy stack is dominated by write paths such as pwrite / fsync;
    • the machine later required a force reboot;
    • immediately after reboot, FileProvider and CoreSpotlight each generated ~2.1 GB disk-write reports within ~1 minute of boot;
    • memory pressure remained non-critical.

    There is overlap in the symptom family, especially long-running session + Computer Use instability + WindowServer/system-service pressure. But #25744 does not appear to contain the 137.44 GB Codex disk-write resource report or the post-reboot FileProvider/CoreSpotlight evidence.

    So I would treat this as related to #25744, possibly same broad root-cause area, but not a strict duplicate unless maintainers decide the disk-write behavior is already covered by that investigation.

  5. jason5545 commented on Jun 9, 2026

    @jason5545
    jason5545
    on Jun 9, 2026
    Author

    Further investigation: heartbeat automation was a major amplifier

    After the original report, we ran a controlled A/B test on the same machine.

    What we found

    A heartbeat automation was waking the same Codex thread every hour for several days. That thread had accumulated:

    • ~143 MB rollout JSONL
    • 14,713 records
    • heavy compaction artifacts
    • ~3.7 MB log traffic per wake-up

    Every hourly wake-up reloaded the full thread state—tool history, renderer updates, logs_2.sqlite growth. This was not a lightweight "check and exit."

    What changed

    We replaced the heartbeat with a one-shot Python monitor run by launchd. Each run scans once, writes a small JSON/text status, then exits. No sync, no git push, no persistent state. The original thread has been archived.

    Public issues matching this pattern

    • #21134: long-running thread causes app-server CPU, memory, and logs_2.sqlite growth
    • #20735: sustained idle CPU after extended desktop use
    • #20435: renderer CPU spin while backends are idle

    Remaining concern

    Even after removing the heartbeat, pre-B sampling showed 7 app-servers, 6 Computer Use client + node_repl helper groups, and a 41+ hour turn-ended residual process. The renderer jumped from 4.6% to 24.6% CPU between samples. These are not killed by removing heartbeat alone.

    Our current take

    1. 10+ hour degradation → Desktop long-session + heartbeat amplification. Removing heartbeat is expected to help here.
    2. Hard freeze (mouse/keyboard/Caps Lock all dead) → still points to Computer Use / WindowServer / HID path. Heartbeat removal may reduce probability but does not explain it.

    Architecture observation

    Automation should be isolated. Waking a 143 MB thread every hour to check a file system is a design gap—there is no per-thread cost cap, no lightweight wake-up mode, and no boundary that restricts how much accumulated state automation must carry.

  6. etraut-openai commented on Jun 10, 2026

    @etraut-openai
    etraut-openai
    on Jun 10, 2026
    Contributor

    This was caused by noisy logging. It's now fixed in recent versions.

  7. etraut-openai
    closed this as completedon Jun 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingcomputer-useperformance

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions