›_ Codex Issues
Codex Issues / #29876

Excessive disk writes / SSD wear concern on macOS Codex app and JetBrains ACP

Resolved 💬 4 comments Opened Jun 24, 2026 by Ko7ov-Konstantin Closed Jul 10, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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 at 4,772,341,477,376 bytes.
  • Current later measurement: 4,774,095,269,888 bytes.
  • 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_clone grew rapidly after cleanup and is currently about 12 GB.
  • ~/.codex/logs_2.sqlite is currently about 166 MB, WAL about 31 MB.
  • Earlier during investigation, Codex-related code_sign_clone and log files were much larger before cleanup.
  • Process list shows Codex macOS app processes and JetBrains/PhpStorm Codex ACP processes active, including codex-acp and codex 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.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 2 months ago

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

  • #29814
  • #29589
  • #29532
  • #29674
  • #28518

Powered by Codex Action

Ko7ov-Konstantin · 2 months ago

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 · 2 months ago

Same root cause; default INFO + off-switch + bounded WAL reduce the write rate substantially: https://github.com/denispol/codex/pull/1

agentHits · 1 month ago

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 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

So there are at least two related SSD-wear surfaces:

  1. Codex local persistence/logging/database write amplification.
  2. Codex agent behavior that runs high-I/O build/test commands without a clear disk-impact warning and without using a low-impact/noindex artifact strategy.

Suggested product-level mitigations:

  • Ask before running high-I/O commands such as xcodebuild, full test suites, archives, dependency installs, or commands likely to generate large caches.
  • Provide a “low-impact verification” mode where Codex prefers static checks and source inspection first.
  • Avoid project-local hidden DerivedData/build-cache paths by default.
  • If heavy verification is approved, use a dedicated .noindex cache/DerivedData path and offer cleanup afterward.
  • Show which Codex-invoked command/path produced large disk activity.

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.