Summary
On current Codex Desktop for macOS, a manual quit/reopen produces a dramatic improvement in memory use and responsiveness, but app-server, renderer, helper-process, and persistent-log growth returns during the same session. The machine can become warm and system-wide UI/browser/audio responsiveness degrades even when no heavy model task is intentionally running.
This report does not claim proven SSD damage. It does show repeatable resource retention and persistent SQLite insert/prune churn that can create avoidable I/O and performance risk.
Environment
- macOS 26.5 (25F71), Apple Silicon
- Physical memory: 64 GiB
- ChatGPT/Codex Desktop: 26.721.41059 (build 5848)
- Embedded CLI: codex-cli 0.146.0-alpha.3.1
- Observation date: 2026-07-24 local time
Clean restart A/B
Before a manual app restart, Activity Monitor showed approximately:
ChatGPT GUI 10.82 GB
codex app-server 5.78 GB
Codex renderers (three largest) 2.50 + 1.66 + 1.28 GB
system memory used 48.39 GB
compressed memory 26.39 GB
swap used 3.77 GB
A separate process inventory near the same bad state found approximately 246 node_repl helpers using about 2.54 GB RSS.
Immediately after manually quitting and reopening the app:
ChatGPT GUI 844 MB
Codex service 766 MB
Codex renderers (two visible) 698 + 305 MB
codex app-server 206 MB
system memory used 24.09 GB
compressed memory 4.83 GB
swap used 2.38 GB
helpers stabilized near 10
The restart therefore removed roughly 24 GB of system memory use and most retained Codex/helper state. No automatic restart or process-kill workaround was used.
Regrowth after the restart
A read-only process-family sample about 3 hours 21 minutes after the restart showed:
ChatGPT GUI 1 process, ~855 MiB RSS
Codex app-server 1 process, ~2,037 MiB RSS, ~62% CPU in the sample
Codex renderers 9 processes, ~3,525 MiB RSS total
node_repl helpers 17 processes, ~235 MiB RSS total
At that moment system memory pressure was normal and the system-wide free/reclaimable percentage was 79%, so this particular sample was not a memory-pressure emergency. The concern is the repeatable growth trajectory and the earlier system-wide lag/warmth/audio artifacts before restart.
Persistent structured-log churn
Current aggregate-only inspection (no log bodies read or shared):
logs_2.sqlite size 8,569,057,280 bytes
WAL size 4,952,272 bytes
10-second max(id) delta 170
10-second sqlite_sequence delta 170
Rows retained in the last 60 seconds by level:
TRACE 287
WARN 236
DEBUG 213
INFO 122
The WAL size stayed flat during the ten-second sample, but sequence IDs continued advancing, consistent with insert/prune churn that file-size-only monitoring can miss.
Raw feedback_log_body data was intentionally not selected or quoted because it may contain private user/task material.
User-visible symptoms
- Mac becomes warm during light foreground use.
- Browser/YouTube playback and the Codex UI become sluggish.
- Bluetooth/audio artifacts have occurred during some high-contention periods, although audio causation is not proven.
- Restarting Codex sharply improves memory use and responsiveness.
- Resource growth returns later in the session.
Steps to reproduce
- Use Codex Desktop on macOS over a long session with multiple local tasks and tool-enabled threads.
- Let completed tool/task activity accumulate without manually killing helpers.
- Observe app-server, renderer, and
node_repl process-family RSS/counts plus SQLite sequence movement.
- Note system warmth and UI/browser responsiveness.
- Manually quit and reopen Codex.
- Observe the large immediate drop in app-server/renderer/helper footprint.
- Continue ordinary use for several hours and observe the footprint/helper/log growth returning.
Expected behavior
- Completed tasks should release or reuse helper processes.
- App-server and renderer memory should settle after work finishes instead of retaining multi-gigabyte heaps/UI state indefinitely.
- Idle/background thread-list and transcript hydration should remain bounded.
- Persistent production logging should filter TRACE/DEBUG before SQLite insertion and enforce bounded retention without continuous insert/prune write amplification.
- The app should expose enough diagnostics to distinguish active work from retained background state.
Actual behavior
Memory, renderers, helpers, and log sequence activity accumulate across a long-running desktop session. A clean restart clears most of the footprint, but growth resumes. In the bad state, the machine becomes warm and visibly laggy despite light intentional foreground work.
Related issues
Suggested investigation boundaries
- Per-task ownership and teardown of
node_repl and other tool helpers.
- App-server heap retention after completed work and thread-list refreshes.
- Renderer lifecycle, transcript hydration, secondary windows, and session-age retention.
- SQLite log filtering before insertion, especially TRACE/DEBUG, plus bounded retention.
- A built-in low-cost diagnostic showing active vs retained tasks/helpers and per-family footprint.
I can provide additional aggregate-only samples or sanitized Activity Monitor screenshots. I will not attach raw database pages, log bodies, transcripts, process arguments, local paths, or task content publicly.
Summary
On current Codex Desktop for macOS, a manual quit/reopen produces a dramatic improvement in memory use and responsiveness, but app-server, renderer, helper-process, and persistent-log growth returns during the same session. The machine can become warm and system-wide UI/browser/audio responsiveness degrades even when no heavy model task is intentionally running.
This report does not claim proven SSD damage. It does show repeatable resource retention and persistent SQLite insert/prune churn that can create avoidable I/O and performance risk.
Environment
Clean restart A/B
Before a manual app restart, Activity Monitor showed approximately:
A separate process inventory near the same bad state found approximately 246
node_replhelpers using about 2.54 GB RSS.Immediately after manually quitting and reopening the app:
The restart therefore removed roughly 24 GB of system memory use and most retained Codex/helper state. No automatic restart or process-kill workaround was used.
Regrowth after the restart
A read-only process-family sample about 3 hours 21 minutes after the restart showed:
At that moment system memory pressure was normal and the system-wide free/reclaimable percentage was 79%, so this particular sample was not a memory-pressure emergency. The concern is the repeatable growth trajectory and the earlier system-wide lag/warmth/audio artifacts before restart.
Persistent structured-log churn
Current aggregate-only inspection (no log bodies read or shared):
Rows retained in the last 60 seconds by level:
The WAL size stayed flat during the ten-second sample, but sequence IDs continued advancing, consistent with insert/prune churn that file-size-only monitoring can miss.
Raw
feedback_log_bodydata was intentionally not selected or quoted because it may contain private user/task material.User-visible symptoms
Steps to reproduce
node_replprocess-family RSS/counts plus SQLite sequence movement.Expected behavior
Actual behavior
Memory, renderers, helpers, and log sequence activity accumulate across a long-running desktop session. A clean restart clears most of the footprint, but growth resumes. In the bad state, the machine becomes warm and visibly laggy despite light intentional foreground work.
Related issues
Suggested investigation boundaries
node_repland other tool helpers.I can provide additional aggregate-only samples or sanitized Activity Monitor screenshots. I will not attach raw database pages, log bodies, transcripts, process arguments, local paths, or task content publicly.