Skip to content

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

Open
Open
macOS Desktop UI lag with excessive codex disk writes despite low system resource pressure#21007
Labels
appIssues related to the Codex desktop appbugSomething isn't workingperformance

Description

@CapriKev
CapriKev
opened on May 4, 2026

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:

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    performance
    on May 4, 2026

  2. github-actions commented on May 4, 2026

    @github-actions
    github-actionsbot
    on May 4, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. emcd commented on May 6, 2026

    @emcd
    emcd
    on May 6, 2026

    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.

  4. baron commented on May 7, 2026

    @baron
    baron
    on May 7, 2026

    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.

  5. brutoshi commented on Jul 6, 2026

    @brutoshi
    brutoshi
    on Jul 6, 2026

    Adding a current macOS data point from Codex Desktop 26.623.101652.

    Symptom

    While typing in the Codex Desktop composer, characters take roughly 3-4 seconds to appear. This is severe enough that normal typing becomes painful/unusable.

    Observed around 2026-07-06 15:20 UTC / 2026-07-06 23:20 Asia/Taipei.

    Environment

    • App: Codex Desktop for macOS 26.623.101652
    • App build: 4674
    • Bundled Codex CLI: codex-cli 0.142.5
    • macOS: 15.7.3 (24G419)
    • Hardware: MacBookPro18,3, Apple M1 Pro, 32 GB RAM
    • Codex app process uptime at the time: about 2d 22h

    Local observations during the lag

    • System load snapshots:
      • 7.03 7.90 11.13
      • 9.06 8.90 11.29
    • Codex-related process snapshot:
      • Codex (Renderer) PID 35934: 41.1% CPU, 879888 KB RSS
      • /Applications/Codex.app/Contents/Resources/codex PID 35880: 38.3% CPU, 192416 KB RSS
      • Codex (Renderer) PID 35933: 5.4% CPU, 136720 KB RSS
      • Codex (Service) PID 35541: 6.6% CPU, 71936 KB RSS
      • Codex main PID 35530: 4.3% CPU, 221088 KB RSS
    • Local Codex state size:
      • ~/.codex: 15G
      • ~/.codex/sessions: 11G
      • ~/.codex/archived_sessions: 35M
      • ~/Library/Logs/com.openai.codex: 36M
      • ~/.codex/logs_2.sqlite: 790M
      • session files under ~/.codex/sessions: 107
    • memory_pressure reported system-wide memory free percentage around 51%; top also showed 12G compressor and only 115M unused physical memory.

    Reproduction shape

    1. Keep Codex Desktop running for multiple days with many/large local sessions.
    2. Work in an existing local project thread.
    3. Type into the message composer.
    4. Character echo lags by several seconds per character.

    Expected behavior

    Typing in the composer should remain responsive even with long-running Desktop sessions and large local Codex state.

    Actual behavior

    The composer input becomes extremely delayed. In this snapshot, the lag coincided with sustained CPU from one Codex renderer plus the bundled codex process, and with a large local session/log state.

    No logs are attached here because local app logs and session transcripts may contain sensitive content. This comment is limited to process/resource evidence and local state sizes.

    This issue or PR was generated by LazyCodex.
    Tag: lazycodex-generated

  6. rellaqaq commented on Jul 21, 2026

    @rellaqaq
    rellaqaq
    on Jul 21, 2026

    Additional sanitized macOS data point from 2026-07-21; no private logs, databases, rollouts, or raw diagnostic report attached.

    macOS: 26.5 (25F71)
ChatGPT Codex Framework: 150.0.7871.124
bundled codex-cli: 0.145.0-alpha.27

process: /Applications/ChatGPT.app/Contents/Resources/codex
Event: disk writes
Writes: 2147.49 MB over 5581 s
Average: 384.79 KB/s
Limit: 24.86 KB/s over 86400 s
Action taken: none

process: ChatGPT Codex (Service), storage.mojom.StorageService
Event: disk writes
Writes: 2147.49 MB over 7640 s
Average: 281.09 KB/s
Limit: 24.86 KB/s over 86400 s
Action taken: none

    At observation time, the root volume had 128 GiB free and macOS memory pressure reported 59% free. The storage service's currently open writable regular files were Chromium LevelDB files under the Codex application-support tree. Their live set was only about 10 MB while files rolled/compacted roughly every 15 minutes; repeated rewrite/compaction as the explanation for the attributed total is an inference, not a confirmed root cause.

    I did not delete or inspect LevelDB, SQLite/WAL, logs, or session JSONL. This build is newer than the versions in the original report, but I cannot establish from release notes whether it contains every mitigation associated with #26396. The separate closed-source storage.mojom.StorageService report may need Desktop-specific ownership rather than the Rust CLI path alone.

  7. twentyOne2x commented on Aug 27, 2026

    @twentyOne2x
    twentyOne2x
    on Aug 27, 2026

    Current-build disk-write diagnostic during a GUI queue-starvation incident

    Adding a sanitized current-build data point from ChatGPT/Codex Desktop 26.820.60940 (build 7119) on macOS 26.3 / Apple Silicon.

    During a roughly two-hour period in which the GUI was intermittently rendered but effectively unusable across three relaunches, macOS generated a Codex disk-write diagnostic:

    • 2147.48 MB of file-backed memory dirtied over 4927s (average approximately 435.9 KB/s)
    • sampled stacks included plugin-catalog/cache and SQLite activity

    Machine capacity was not exhausted:

    • 128 GB physical RAM, with no OOM/ENOMEM evidence
    • ChatGPT footprint approximately 293 MB in the hang report
    • approximately 117 GB free disk, versus a roughly 3 GB low-space threshold
    • no ENOSPC or disk-full evidence

    The proof boundary matters: the macOS diagnostic is a cumulative resource-accounting window and does not by itself prove constant throughput, write throttling, or that disk writes were the sole cause of the GUI failure. The report does not identify whether unrelated writers or indexing contributed.

    Separately, the strongest direct application-level chain was startup thread hydration saturating the shared app-server queue: all six slots were repeatedly occupied, queuedInteractiveRequestCount reached 64, and config/model/plugin/thread/Composer operations expired. The final launch recorded 272 queue rejections. That exact scheduler/backpressure mechanism is tracked in #36914; this comment does not claim it caused the disk-write diagnostic.

    This supports treating logging/cache/SQLite write volume as a potential latency amplifier while separately fixing bounded hydration, interactive-request priority, and automatic queue recovery. Free disk capacity and I/O responsiveness should also be reported separately in diagnostics so users are not told that ample free space rules out local persistence latency.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingperformance

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions