[macOS App] Opening integration-heavy tasks spawns persistent renderers that survive archive and idle #33469

Summary

Codex Desktop on macOS accumulates child Codex (Renderer) processes when opening tasks that contain many inline integration/tool-result cards. Reopening the same task creates additional renderer processes. Navigating away, archiving the task, and waiting several minutes do not terminate them.

The renderers may have their resident memory trimmed while idle, but the processes and almost all of their threads remain. Fully quitting and relaunching the app is the only cleanup observed.

Environment

• Codex/ChatGPT desktop app: 26.707.72221 (build 5307)
• Bundled Codex CLI: 0.144.2
• macOS: 26.5.1 (build 25F80)
• Architecture: Apple Silicon / arm64
• Hardware: M4 MacBook Air, 24 GB RAM
• Displays during the initial tests: built-in display plus two 6016×3384 displays
• Later archive/idle tests: battery power with only the built-in display online

The renderer-lifecycle behavior reproduced across both display configurations.

Reproduction

1. Fully quit and relaunch Codex Desktop.
2. Open a task containing many inline integration results (for example, Slack, GitHub, Jira, or Confluence result cards).
3. Switch to another task and reopen the integration-heavy task several times without expanding or interacting with individual cards.
4. Observe direct child Codex (Renderer) processes after each opening.
5. Navigate away from the task.
6. Archive it from the sidebar without reopening it.
7. Wait several minutes and inspect the process tree again.

Controlled results

Fresh restart

Five repeated openings of one integration-heavy task

Before this test, 21 renderer processes were alive.

The app log recorded exactly five activations of the affected task. Renderer process start times aligned with those activations:

One older renderer exited during the interval, giving a net increase of five. The task had no Browser sidebar activity, so these were not Browser guest renderers.

After approximately ten idle minutes, all 26 renderers remained alive. Renderer RSS fell from 3,709 MiB to 2,234 MiB, consistent with inactive working-set trimming, but no renderer process was cleaned up.

Separate Confluence-heavy task and archive test

Opening another task that rendered many inline Confluence/integration snippets produced:

Merely navigating away left all 35 renderers alive.

Archiving the task succeeded. Desktop logs recorded:

• thread/archive completed
• browser-use route disposed
• browser-use conversation disposed
• worktree archive cleanup completed
• no Browser guest teardown
• no renderer exit

Expected behavior

Opening a task or hydrating inline integration history should reuse a bounded renderer set. Renderers associated with task-local tool views should be terminated or otherwise released when their views are unmounted, their route is disposed, or the task is archived.

Actual behavior

Each opening of an integration-heavy task creates additional renderer processes. Those processes survive navigation, task archive, and idle time. Memory may be compressed or reclaimed, but the process and thread counts remain accumulated for the lifetime of the desktop app.

Workaround

Fully quit and relaunch Codex Desktop. This immediately reduced the observed renderer count from 388 to 2. The accumulation begins again as integration-heavy tasks are opened.

Feedback and diagnostics

An in-app feedback upload with logs completed successfully at 2026-07-16T01:30:56Z. The UI feedback ID was not retained. The local app-server request correlation was 22402790-801d-4045-8e05-fe5a6cd67302.

Timestamped process reports and additional sanitized excerpts are available. Raw app logs are not attached publicly because they contain private task text and local paths.

Related issues

• Abnormally high ram usage in mac app #18589 — high content-renderer RAM usage on macOS
• Codex Desktop compaction does not bound transcript hydration/rendering; valid long thread becomes unscrollable #33285 — unbounded transcript hydration/rendering when opening long tasks
• Codex App visible window causes sustained high GPU/WindowServer CPU and MacBook Air extreme heat #30464 — renderer/WindowServer load on an M4 MacBook Air
• Codex Desktop main process leaks memory in Chromium PartitionAlloc / Memory Tag 253 on macOS #31793 — adjacent Chromium/Electron memory accumulation in the macOS main process