macOS Desktop UI lag with excessive codex disk writes despite low system resource pressure

[CapriKev]

Summary

Codex Desktop on macOS becomes noticeably sluggish even when the Mac itself is not under CPU or memory pressure. The lag affects basic UI interactions: scrolling, typing in the input box, and pasting images.

Local diagnostics suggest this is not caused by insufficient hardware resources. A macOS diagnostic report captured the Codex native process doing sustained disk writes: about 2.1 GB over ~648 seconds, with the heaviest sampled stack ending in pwrite.

This looks related to other Desktop performance reports, but I wanted to add concrete local diagnostic data because the symptom is severe enough to make input and scrolling feel blocked.

Environment

• App: Codex Desktop for macOS
• Codex app version: 26.429.30905
• App build: 2345
• Electron version shown in process args: 41.2.0
• macOS: 26.3 (25D125)
• Hardware: MacBook Pro Mac16,7, Apple M4 Pro, 48 GB RAM
• Sensitive identifiers such as serial number, hardware UUID, and hostname omitted.

Symptoms

• UI scrolling stutters or freezes briefly.
• Typing in the prompt box lags.
• Pasting images into the input box lags.
• The issue is visible while overall system resources look healthy.

Local resource checks

At the time of investigation:

• memory_pressure reported very low pressure, with free percentage around 91%.
• vm_stat showed Swapins: 0 and Swapouts: 0.
• Data volume had about 183 GiB free.
• Load average was around 3 on a 14-core M4 Pro machine.
• Codex processes were not consistently pegging CPU in ps snapshots.

Representative Codex process memory at one snapshot:

• Codex Helper (Renderer): ~529 MB RSS
• Codex main process: ~414 MB RSS
• codex app-server --analytics-default-enabled: ~180 MB RSS

Strongest diagnostic evidence

macOS generated a diagnostic report for:

Command:          codex
Path:             /Applications/Codex.app/Contents/Resources/codex
Event:            disk writes
Writes:           2147.48 MB of file backed memory dirtied over 648 seconds
Average:          3315.48 KB/s
Limit:            24.86 KB/s over 86400 seconds
Heaviest stack:   ... pwrite

The stack was not symbolicated locally, but the sampled hot path repeatedly ended in pwrite, which matches the observed UI stalls better than CPU or memory pressure.

Local Codex state size

~/.codex was about 1.3 GB total:

713M  ~/.codex/sessions
195M  ~/.codex/archived_sessions
176M  ~/.codex/logs_2.sqlite
15M   ~/.codex/state_5.sqlite
3.0M  ~/.codex/log/codex-tui.log

The local SQLite log database contained:

rows: 59106
estimated log bytes: 122.4 MB
TRACE: 34159 rows / 95.5 MB
INFO: 18537 rows / 21.9 MB
DEBUG: 6088 rows / 4.4 MB

Largest log targets by estimated bytes included:

codex_client::transport                  66.4 MB
codex_api::endpoint::responses_websocket 14.8 MB
codex_otel.log_only                      11.4 MB
codex_otel.trace_safe                     9.0 MB

There were also repeated warnings like:

failed to load discoverable tool suggestions: request failed with status 403 Forbidden

In the local log file, these warnings included a very large Cloudflare/HTML challenge response body. That may be amplifying disk writes if retried or logged repeatedly.

Possible causes to investigate

• Excessive TRACE/transport logging in Desktop sessions.
• Large response bodies, especially 403/Cloudflare HTML pages, being logged without truncation.
• Log database writes causing UI stalls or contention with the Desktop app-server.
• Long session history / archived session replay making renderer or app-server work scale with total local state.
• Similar interaction with MCP/browser/computer-use sessions, since this setup also had browser/computer-use related subprocesses running.

Related issues

This may overlap with:

• Codex Desktop on macOS becomes progressively slow and causes system-wide lag during long MCP-heavy sessions #12709
• App UI gets extremely slow and laggy during long sessions #11984
• App is almost unresponsive for 5 mins after starting up #16158
• Codex desktop app pegs CPU on macOS after latest update; fans surge and system lags even on small requests #18467
• Codex Desktop repeatedly starts full MCP stacks for new sessions/subagents, causing severe slowdown and memory pressure #18333

I am opening a separate issue because the macOS diagnostic report provides a concrete disk writes event and local log database evidence.

Expected behavior

Typing, scrolling, and pasting images in Codex Desktop should remain responsive even after long sessions. Logging or local persistence should not generate multi-GB write bursts or block UI responsiveness.

Actual behavior

Codex Desktop becomes sluggish in basic UI interactions while macOS reports sustained disk writes from the Codex native process, despite the Mac having low memory pressure, no swap activity, and plenty of free disk space.

[github-actions]

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

• Heavy I/O activity from idle codex processes. #20563
• Codex Desktop App becomes laggy because it scans all ~/.codex/sessions rollout files instead of respecting Desktop-visible session index/state #20864
• mcp-search fails after clean reinstall on Windows: ChatGPT backend plugin/connectors requests return Cloudflare 403, Settings UI also breaks #20673
• VS Code extension repeatedly logs telemetry 403 errors for /ces/v1/rgstr and prompt is lagging #19371

Powered by Codex Action

[emcd]

On Linux, GPT and I whittled this down to Codex CLI hammering SQLite write-ahead logs. Probably constant overwrites of the same rows, so very little actual database growth is seen. Seems consistent with what you observed with the pwrite calls dominating in Codex Desktop for Macos. Added a comment to #20563 about this.

[baron]

See issue #21211 The sqlite is problematic because the title and first_message are actually the same and the codex app sidebar loads both even before you open the thread. If you hot patch the app with the repo linked in the issue the app opens fast again. However the sidebar still loads first_message just rendering the sidebar.