›_ Codex Issues
Codex Issues / #29177

Codex Desktop on Windows generates excessive local SQLite I/O and causes system stalls

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

What version of Codex are you using?

Codex Desktop App on Windows, observed install path version: 26.616.4196.0.

What platform is your computer?

Windows desktop workstation.
Hardware: AMD Ryzen 9 9950X, 32 GB RAM.

What issue are you seeing?

Codex Desktop generates very heavy local I/O against multiple SQLite databases under the user Codex data directory. Before moving these SQLite files to a RAM disk, the machine would periodically stall or feel blocked during normal Codex use, despite being a high-end workstation.

The problematic files include SQLite databases and WAL/SHM companions such as logs/state/memories/goals databases. The write pattern appears continuous and high-frequency, especially around SQLite WAL activity.

After moving these Codex SQLite files to an AIM RAM disk and keeping a disk-backed sync copy, the system became noticeably smoother. This strongly suggests that Codex local persistence/logging behavior is causing the disk stalls.

Local observation data

A 60-second local monitor after moving the files to RAM disk showed:

Physical disk activity:

R:  write 155.1 MB, peak 25.7 MB/s
D:  write 8.8 MB, read 0.2 MB
C:/F: write 5.7 MB, read 0.3 MB
E:/K: near 0

Top process I/O deltas during the same 60 seconds:

codex.exe app-server: total I/O about 1896.8 MB, write about 282.3 MB
Codex.exe main process: total I/O about 789.4 MB, write about 70.1 MB
Codex renderer process: write about 403.8 MB

I understand process-level I/O includes pipes, IPC, network, and device I/O, so it is not equal to physical disk writes. But the disk-level measurement still shows that Codex would have produced substantial local write pressure without the RAM disk workaround.

Expected behavior

Codex Desktop should avoid continuous high-frequency writes to the user's physical disk during normal use. A high-end Windows workstation should not experience UI/system stalls due to Codex local persistence.

Suggested improvements

Please consider improving Codex Desktop local persistence behavior:

  • Reduce local log verbosity by default.
  • Batch/debounce SQLite writes.
  • Separate volatile logs from durable state.
  • Provide a setting to choose log/cache/database directory.
  • Provide max log size and retention controls.
  • Automatically rotate, checkpoint, vacuum, or compact large SQLite logs.
  • Avoid unbounded WAL growth or very frequent WAL writes on the user/system disk.
  • Allow volatile logs to be stored in a temp/cache location while keeping durable state safer.
  • Expose diagnostics showing which Codex local files are responsible for heavy I/O.

Workaround used

I moved the high-frequency Codex SQLite files to a RAM disk and keep a synchronized disk-backed copy. This greatly reduced physical disk writes and made the machine smoother. However, this workaround is fragile and should not be necessary for normal desktop use.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 2 months ago

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

  • #28224
  • #28997
  • #27911
  • #27741

Powered by Codex Action

lgoklgok-lee · 2 months ago

I reviewed the potential duplicates (#28224, #28997, #27911, #27741). This issue is definitely related to the broader SQLite/log persistence problem, especially #28224, but I believe it adds distinct Windows Desktop evidence rather than being a pure duplicate.

Additional distinction in this report:

  • Observed on the native Codex Desktop Windows app, version 26.616.4196.0.
  • The machine is high-end hardware: Ryzen 9 9950X with 32 GB RAM, yet Codex still caused visible system stalls before mitigation.
  • The observed pressure is not limited to logs_2.sqlite; the active local SQLite set included logs/state/memories/goals databases and their WAL/SHM files.
  • Moving the high-frequency Codex SQLite files to an AIM RAM disk dramatically reduced physical D: drive writes and made the machine noticeably smoother.
  • The report includes a 60-second disk-level and process-level measurement after mitigation, showing Codex activity moved mostly to the RAM disk while physical D: writes stayed low.

So I think #28224 is probably the best umbrella issue for the root cause, but this issue may still be useful as Windows Desktop performance evidence showing real user-visible stalls and a validated RAM-disk workaround.

Jafa7 · 2 months ago

I'm afraid to update Codex Desktop every time. Now, it is working and I don't want to update it:)

Nicolas0315 · 2 months ago

I ran a native Windows Desktop measurement on the Codex SQLite files and found one detail that may help with this issue: file-size deltas alone can miss active SQLite writes.

Environment:

  • Windows 11 Pro 10.0.26200
  • Codex Desktop active during the run
  • Upstream source inspected: 63f009e9dad2e70454b7ed6434d8aa28dfb52b51

Measurement method:

  • Scanned .codex, %APPDATA%\Codex, %LOCALAPPDATA%\OpenAI\Codex, and the packaged app local cache for *.sqlite, *.sqlite-wal, *.sqlite-shm, *.db, *.db-wal, and *.db-shm.
  • Sampled size and LastWriteTimeUtc every 5s for 60s.
  • Counted both byte deltas and update-time changes because WAL files can be rewritten/reused without growing.

Observed:

  • SQLite-family file count under the scanned roots: 34
  • Total SQLite-family bytes: 2,714,001,184
  • Total file-size delta over 60s: 0 bytes
  • Files with LastWriteTimeUtc changes over 60s: 4

Changed files:

  • .codex\logs_2.sqlite-wal
  • Size: 31,728,152 bytes
  • Size delta: 0
  • LastWriteTimeUtc changed in 6 of 7 samples.
  • .codex\logs_2.sqlite
  • Size: 300,761,088 bytes
  • Size delta: 0
  • LastWriteTimeUtc changed in 5 of 7 samples.
  • .codex\state_5.sqlite-wal
  • Size: 4,284,832 bytes
  • Size delta: 0
  • LastWriteTimeUtc changed in 1 of 7 samples.
  • .codex\state_5.sqlite
  • Size: 3,821,568 bytes
  • Size delta: 0
  • LastWriteTimeUtc changed in 1 of 7 samples.

Large retained files/backups under .codex on this machine:

  • log-maintenance-backups\codex-log-vacuum-20260617-234151\logs_2.sqlite: 729,575,424 bytes
  • log-maintenance-backups\20260615-085307\logs_2.sqlite: 555,249,664 bytes
  • log-maintenance-backups\20260614-180340\logs_2.sqlite: 523,169,792 bytes
  • log-maintenance-backups\20260619-002818\logs_2.sqlite: 300,761,088 bytes
  • active .codex\logs_2.sqlite: 300,761,088 bytes

Open-source paths I checked:

  • codex-rs/state/src/runtime.rs
  • SQLite opens use WAL mode, synchronous normal, 5s busy timeout, and pools with max 5 connections.
  • codex-rs/state/src/runtime/logs.rs
  • startup log maintenance deletes old logs and runs PRAGMA wal_checkpoint(PASSIVE).

I am not claiming this 60s sample reproduces the full system-stall symptom. The useful finding is narrower: on Windows, the active log DB/WAL can be written repeatedly without any file-size growth, so disk monitors that only look at byte growth may underreport the churn. It may be worth looking at whether log persistence/checkpoint/retention work can be coalesced or throttled when the Desktop app is idle/backgrounded.

Yassycodes · 2 months ago

Thanks for writing this up. I am seeing a related Windows Codex Desktop performance regression in #28855. My case started with a large logs_2.sqlite / WAL problem too, but even after rotating logs and reproducing with small fresh logs, Codex Desktop still caused intermittent mouse/typing/system input lag on Windows.

I linked your report in a broader Discussion collecting recent Windows Desktop performance reports here: https://github.com/openai/codex/discussions/29949#discussioncomment-17428007

No action needed from you unless you want to add more detail there, but I wanted to connect the reports because the recent Windows performance issues look related enough that they may need a canonical tracker.