[macOS] Renderer CPU scales with visible window area: ~130% full-size, ~25% small, ~0% minimized

What version of the Codex App are you using (From “About Codex” dialog)?

26.818.22352 (build 6872)

What subscription do you have?

ChatGPT subscription (exact tier not provided)

What platform is your computer?

Darwin 25.5.0 arm64 arm

• macOS 26.5.1 (build 25F80)
• MacBook Pro with Apple M5 Pro, 24 GB memory
• Built-in 3024 x 1964 Retina display
• External 2560 x 1440 display at 60 Hz

What issue are you seeing?

On macOS, the primary Codex (Renderer) CPU usage and laptop temperature scale sharply with the visible size of the Codex task window, even when the task and app session do not change.

A controlled resize/minimize comparison produced the following results:

Restoring/enlarging the task window brings the renderer load and temperature back. This makes the visible render area the strongest variable in the reproduction.

The effect also depends on page content: displaying Settings in a large window used approximately 21% renderer CPU and 516 MB, substantially less than the active task view at the same general window size. This suggests that the task component tree, layout, or paint/compositing work amplifies the window-area effect.

The app-server was not the hot process during the comparison. An SSH remote connection was disconnected and its retry activity stopped, but the visible large-window renderer still remained around 129% CPU. syspolicyd and trustd were also no longer elevated. GPU compositing was enabled; the app was not launched with --disable-gpu.

What steps can reproduce the bug?

1. Launch Codex Desktop on macOS.
2. Open a task with a substantial conversation/tool-output history.
3. Make the Codex window large or nearly full-screen and leave it visible.
4. Observe the primary Codex (Renderer) process in Activity Monitor for at least 30 seconds.
5. Resize the same window to approximately 600 x 500 without restarting Codex or changing tasks.
6. Observe the renderer CPU drop substantially.
7. Minimize the window using the yellow macOS window button.
8. Observe the renderer approach idle CPU usage.
9. Restore and enlarge the same window; observe the load return.

What is the expected behavior?

An idle or lightly updating visible task should not continuously saturate approximately one CPU core. Renderer work should settle when content is unchanged and should not scale this dramatically with window area. Expensive animations, observers, layout passes, or compositor updates should be paused or throttled when they are not producing meaningful visible changes, and should stop when the window is minimized.

Additional information

Related reports:

• #30464 reports sustained GPU/WindowServer/renderer load while the Codex window is visible and a sharp drop when hidden.
• #32024 reports a visible Codex window driving high WindowServer CPU on macOS.
• #39134 reports the renderer dropping from about 98% to 1.9% when the Recent sidebar is collapsed.
• #34415 reports excessive GPU usage with the translucent sidebar enabled.

This report adds a same-session, three-state A/B comparison on the newer 26.818.22352 build: large visible window, small visible window, and minimized window. No private logs, local paths, server details, or session identifiers are included.

Start by reproducing the Codex App task view on macOS and compare renderer CPU across large, small, and minimized window states. Inspect the task component tree, layout, paint, and compositing work described in the report, then verify that unchanged visible content settles and minimized windows approach idle CPU without regressing the Settings view.