Codex desktop app generates excessive file I/O (~5,500-12,000 openat/sec), causing severe CPU load on systems with endpoint security software

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

What version of the Codex App are you using (From “About Codex” dialog)?

26.217.1959 (669)

What subscription do you have?

Plus

What platform is your computer?

Darwin 25.2.0 arm64 arm

What issue are you seeing?

The Codex desktop app generates an extremely high rate of file system operations (5,500–12,000 openat calls/sec) on its internal data files, even during normal usage. On systems running endpoint security software (CrowdStrike Falcon in my case), this triggers real-time scanning of every file operation, causing com.crowdstrike.falcon.Agent to consume 240–270% CPU and the entire system to become nearly unusable (idle CPU drops to ~1%).

I captured detailed fs_usage logs filtered to com.crowdstrike.falcon.Agent to identify exactly which files were being scanned. The results show that 93.7% of all file operations target Codex's internal files:

  Path: ~/Library/Application Support/Codex/ (LevelDB, GPUCache, DawnGraphiteCache, DawnWebGPUCache)
  openat count (74 sec sample): 231,464
  % of total: 56.2%
  ────────────────────────────────────────
  Path: /private/var/folders/*/C/com.openai.codex/com.apple.metal/ (Metal shader cache)
  openat count (74 sec sample): 102,844
  % of total: 25.0%
  ────────────────────────────────────────
  Path: ~/Library/Logs/com.openai.codex/
  openat count (74 sec sample): 51,440
  % of total: 12.5%
  ────────────────────────────────────────
  Path: All other paths
  openat count (74 sec sample): 25,845
  % of total: 6.3%

For comparison, after Codex became idle, the scan rate dropped to 136 openat/sec (1/80th), and VS Code (also Electron-based) running on the same system generated only ~88 openat/sec — roughly 63x less than Codex.

Furthermore, during Codex shutdown, file I/O actually increased to ~12,000 openat/sec before eventually settling, suggesting cache flush or cleanup operations also contribute significantly.

What steps can reproduce the bug?

  1. Run sudo fs_usage -w -f filesys | grep "com.crowdstrike.falcon.Agent" > crowdstrike.log (or any fs_usage capture)
  2. Use Codex desktop app normally (run an agent, view diffs, etc.)
  3. Observe the captured log — thousands of openat/pread/close operations per second targeting Codex's internal cache and log files
  4. In Activity Monitor, observe the endpoint security process consuming 200%+ CPU

What is the expected behavior?

Codex should minimize unnecessary file I/O on its internal cache and log files. Specifically:

  • GPU/Metal/Dawn shader caches should not be repeatedly read at thousands of ops/sec
  • LevelDB access should be batched or throttled during idle periods
  • Log writes should be buffered rather than flushed per-entry
  • A rate comparable to other Electron apps (VS Code: ~88 ops/sec) would be reasonable

Additional information

Related issues: #10530, #11981, #11124, #11524, #11861 — these all report high CPU usage on macOS. The root cause
may be the same excessive file I/O identified here, manifesting differently depending on whether endpoint
security software is present.

13:01:19.473205 openat /Users/<user>/Library/Application Support/Codex/Local Storage/leveldb/LOG
13:01:19.481240 openat /private/var/folders/.../com.openai.codex/com.apple.metal/32024/libraries.data
13:01:19.482376 openat /Users/<user>/Library/Logs/com.openai.codex/2026/02/24/codex-desktop-....log
13:01:19.488047 openat /Users/<user>/Library/Application Support/Codex/Local Storage/leveldb/000018.log
13:01:19.497653 openat /Users/<user>/Library/Application Support/Codex/Local Storage/leveldb/MANIFEST-000001
13:01:19.535968 openat /private/var/folders/.../com.openai.codex/com.apple.metal/32024/libraries.list
13:01:19.588925 openat /Users/<user>/Library/Application Support/Codex/DawnGraphiteCache/data_1
13:01:19.590681 openat /private/var/folders/.../com.openai.codex/com.apple.metal/16777235_322/functions.data
13:01:19.623758 openat /private/var/folders/.../com.openai.codex/com.apple.metal/32024/libraries.list
13:01:19.624241 openat /Users/<user>/Library/Application Support/Codex/GPUCache/data_1

| Log | State | Duration | openat count | Rate (ops/sec) | Codex % |
|---|---|---|---|---|---|
| 1 | Codex active | ~74s | 411,593 | 5,562/s | 93.7% |
| 2 | Codex shutting down | ~37s | 457,610 | 12,368/s | 95%+ |
| 3 | Codex just exited | ~51s | 584,032 | 11,451/s | 95%+ |
| 4 | Codex fully idle | ~21s | 2,857 | 136/s | 0% |

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 6 months ago

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

  • #11981
  • #11124
  • #11524
  • #11861

Powered by Codex Action

ckazu · 6 months ago

Update on the original issue:

We've configured CrowdStrike exclusions on our end for ~/Library/Application Support/Codex/, ~/Library/Logs/com.openai.codex/, and /private/var/folders/*/C/com.openai.codex/. This resolved the original cache file scanning issue — Codex-internal file I/O dropped from 93.7% of all CrowdStrike scans to effectively 0%.

However, I'm still seeing high CPU load from CrowdStrike caused by Codex's idle-state git polling on a large repository, which cannot be mitigated by exclusions alone.

Remaining issue — git polling while idle:

  • Repository: 115,049 tracked files, 35GB .git directory, git-lfs enabled (258 objects, 3 pack index files)
  • Codex app was open but no agents were running

fs_usage capture (40 seconds, idle):

| Category | openat count | % of total |
|---|---|---|
| /Library/Developer/CommandLineTools/usr/bin/git (binary verification per invocation) | 5,665 | 57.5% |
| <repo>/.git/objects/pack/*.idx (3 pack indexes, ~502 each) | 1,506 | 15.3% |
| <repo>/.git/objects/ (loose objects) | 502 | 5.1% |
| git-lfs binary verification | 495 | 5.0% |
| <repo>/.git/index | 252 | 2.6% |
| <repo>/ working tree files | 251 | 2.5% |
| Other | 849 | 8.6% |
| Total | 61,520 (1,538/sec) | |

Even with CrowdStrike exclusions for Codex's internal files, the git polling itself generates significant I/O that endpoint security software is not practical to exclude (repository files and system binaries like /usr/bin/git).

Observation: It appears that git polling continues at a high frequency even when no agents are active. For repositories of this size with git-lfs, this can result in noticeable system load, especially on machines running endpoint security software. Would it be possible to reduce the polling frequency for idle repositories?