Excessive disk writes / SSD wear concern on macOS Codex app and JetBrains ACP #29876
Description
Excessive disk writes / SSD wear concern on macOS Codex app and JetBrains ACP
Environment
- macOS 26.5.1, arm64
- MacBook Air M4, Apple SSD AP0256Z
- Codex CLI: 0.142.0
- Bundled Codex app CLI: 0.142.0
- Surfaces used: Codex macOS app + JetBrains/PhpStorm Codex ACP
- Feedback/session ID: 019ef542-c75a-7a13-aacd-cebe3296df6e
Problem
Codex appears to cause very high SSD write volume on macOS, raising SSD wear concerns.
Observed data
- IORegistry
Bytes (Write)since boot previously measured at4,772,341,477,376bytes. - Current later measurement:
4,774,095,269,888bytes. - Boot date: June 6, 2026.
- Measured write deltas while Codex was active:
- ~1.05 GB written over 2 minutes.
- Later ~0.65 GB written over 2 minutes.
- In a mostly idle state, still ~0.413 GB written over 2 minutes, about 207 MB/min.
/private/var/folders/.../X/com.openai.codex.code_sign_clonegrew rapidly after cleanup and is currently about 12 GB.~/.codex/logs_2.sqliteis currently about 166 MB, WAL about 31 MB.- Earlier during investigation, Codex-related
code_sign_cloneand log files were much larger before cleanup. - Process list shows Codex macOS app processes and JetBrains/PhpStorm Codex ACP processes active, including
codex-acpandcodex app-server.
Why this matters
This is not only disk space usage. The main concern is sustained physical SSD writes and SSD wear on a MacBook with soldered storage.
Expected behavior
Codex should avoid sustained high disk write amplification during normal app or IDE usage, or provide a setting/diagnostic explaining what is being written and how to reduce it.
Request
Please investigate high write amplification from Codex app-server / macOS app / JetBrains ACP, especially around com.openai.codex.code_sign_clone and logs_2.sqlite.
Activity
github-actions commentedon Jun 24, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Ko7ov-Konstantin commentedon Jun 24, 2026
I reviewed duplicates; this overlaps with #28224 for SQLite TRACE churn and #28518 for code_sign_clone, but this issue adds IORegistry physical write measurements and JetBrains ACP involvement. Please keep open unless maintainers prefer consolidation.
denispol commentedon Jun 25, 2026
Same root cause; default INFO + off-switch + bounded WAL reduce the write rate substantially: https://github.com/denispol/codex/pull/1
agentHits commentedon Jul 4, 2026
I have a related macOS/SSD-wear observation from a Codex Desktop coding session.
In my case, Codex did not only write through its own local databases/logs. It also indirectly caused very large disk I/O by autonomously running heavyweight verification commands in an Xcode project (
xcodebuild test/xcodebuild clean build) and writing DerivedData into a project-local hidden folder (.agent-work/derived-data/...).The direct folder size was only several GB when inspected, but Activity Monitor showed much larger process I/O due to system services reacting to the generated artifacts:
kernel_task: ~5.39 TB written, ~567 GB readmds_stores: ~128.99 GB written, ~523.62 GB readsyspolicyd: ~31.84 GB written, ~290.59 GB readmds: ~1.01 GB written, ~186.24 GB readfileproviderd: ~33.45 GB written, ~138.14 GB readcorespotlightd: ~6.41 GB written, ~72.16 GB readcodex: ~13.40 GB written, ~13.05 GB readSo there are at least two related SSD-wear surfaces:
Suggested product-level mitigations:
xcodebuild, full test suites, archives, dependency installs, or commands likely to generate large caches..noindexcache/DerivedData path and offer cleanup afterward.For MacBooks with soldered SSDs, this matters even when the largest write counters are attributed to macOS services like Spotlight, Gatekeeper, or FileProvider, because Codex was the actor that triggered the artifact churn.