›_ Codex Issues
Codex Issues / #30715

Unexpected disk write activity while Codex is running

Open 💬 4 comments Opened Jun 30, 2026 by Capyhw
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What happened?

I noticed unexpectedly high disk write activity while Codex was running on macOS.

From the disk monitor screenshot:

  • Overall disk write rate: about 58.9 MB/s
  • Overall disk read rate: about 1.7 MB/s
  • The process table shows Codex writing about 127 KB/s
  • Another process name appears garbled/unreadable in the monitor and is writing about 33.6 MB/s

I am not sure whether the high write rate is caused directly by Codex or by a child/helper process related to Codex, but the activity appeared while using Codex and looked abnormal enough to report.

Expected behavior

Codex should not cause sustained or unexpected high disk writes during normal usage.

Environment

  • Codex CLI: codex-cli 0.142.4
  • OS: macOS 26.5.1 (25F80)
  • Architecture: arm64

Screenshot details

I have a local screenshot of the disk monitor. Since this issue is being created via gh issue create, I am summarizing the visible values here instead of attaching the local image directly.

Additional notes

Please let me know if there are recommended diagnostics to collect, such as logs, process names, file paths being written, or a command to trace disk I/O for Codex/helper processes.

View original on GitHub ↗

4 Comments

Capyhw · 1 month ago

补充截图

<img width="560" height="1266" alt="Image" src="https://github.com/user-attachments/assets/485ecdb5-de1e-4bef-a536-5ebcbb67f86e" />

github-actions[bot] contributor · 1 month ago

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

  • #29876
  • #30236
  • #29532

Powered by Codex Action

Capyhw · 1 month ago

<img width="695" height="273" alt="Image" src="https://github.com/user-attachments/assets/0a130e3b-3a1e-4818-8a71-e27258281c7c" />
关闭codex 客户端后，不再出现此进程

agentHits · 1 month ago

Adding another macOS data point that may be related, with one important nuance: in my case the largest I/O was not only the codex process itself, but a cascade triggered by Codex running heavyweight local verification commands.

Environment/context:

  • macOS / Apple Silicon MacBook
  • Codex Desktop/API-driven coding session inside a Swift/Xcode project
  • During the session, Codex ran xcodebuild test and xcodebuild clean build with -derivedDataPath .agent-work/derived-data/...
  • The project-local DerivedData folder reached several GB, but Activity Monitor process counters showed much larger aggregate I/O due to system services reacting to the generated build artifacts.

Observed Activity Monitor Disk counters from the same period:

  • kernel_task: ~5.39 TB written, ~567 GB read
  • mds_stores: ~128.99 GB written, ~523.62 GB read
  • syspolicyd: ~31.84 GB written, ~290.59 GB read
  • mds: ~1.01 GB written, ~186.24 GB read
  • fileproviderd: ~33.45 GB written, ~138.14 GB read
  • corespotlightd: ~6.41 GB written, ~72.16 GB read
  • codex: ~13.40 GB written, ~13.05 GB read

Interpretation:

  • Some of this is expected once Xcode creates many build artifacts: Spotlight indexes them, Gatekeeper/syspolicyd checks them, FileProvider may scan them, etc.
  • However, from a user/product perspective this still appears as Codex causing unexpectedly high disk I/O and SSD wear risk, because the agent autonomously chose to run heavy verification and wrote build products into a project-local hidden workspace folder.

What would help:

  1. Codex should treat xcodebuild, large test/build/archive commands, dependency installs, and similar commands as high-I/O operations and ask before running them.
  2. Codex should expose/estimate disk-impact before such commands: “this may create DerivedData/build artifacts and trigger Spotlight/Gatekeeper I/O.”
  3. Codex should avoid project-local hidden paths like .agent-work/derived-data for compiler output by default.
  4. If the user approves heavy verification, Codex should prefer a dedicated .noindex DerivedData/cache location and offer cleanup afterward.
  5. There should be a low-impact verification mode: static checks/searches first, build/test only on explicit approval.
  6. It would be useful to expose diagnostics showing which Codex-invoked command caused the I/O and what artifact path was used.

This is especially important on MacBooks with soldered SSDs. Even if the direct codex process writes less than the system services, Codex can still indirectly amplify disk I/O by choosing heavyweight verification workflows without warning.