›_ Codex Issues
Codex Issues / #26736

Codex Desktop on macOS drives high GPU only while window is visible; minimizing immediately drops usage

Open 💬 10 comments Opened Jun 6, 2026 by cmmchina
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

  • Codex Desktop: 26.602.40724
  • App bundle version: 3593
  • Bundled Codex CLI: codex-cli 0.137.0-alpha.4
  • External/Homebrew Codex CLI: codex-cli 0.137.0

What platform is your computer?

  • macOS 26.5.1 (25F80), Apple Silicon
  • Mac mini (Mac16,10)
  • Apple M4, 10-core CPU (4 performance + 6 efficiency cores)
  • 32 GB memory
  • External display: Kuycon G34W, 5120 x 2160 native, 60 Hz
  • Current display mode: 2560 x 1080 HiDPI logical resolution
  • HDR supported

What issue are you seeing?

Codex Desktop appears to cause very high GPU usage only when its window is visible. When the Codex window is minimized, GPU load drops immediately, while the same session continues running.

This makes long-running Codex work difficult to monitor from the desktop app, especially on a large 5120 x 2160 HiDPI display. The current workaround is to keep Codex Desktop minimized and monitor the session from terminal/session logs instead.

We initially suspected the external HiDPI display setup, but after testing, the trigger appears to be the Codex App window visibility itself:

  • Codex window visible: GPU workload rises very high, sometimes close to 100%.
  • Codex window minimized: GPU workload immediately drops.
  • The project/test workload is not the observed trigger.

This looks like a UI renderer/compositor path, animation, live progress indicator, or HiDPI repaint loop issue rather than agent computation.

Steps to reproduce

  1. On macOS 26.5.1, launch Codex Desktop 26.602.40724.
  2. Open a project/session and leave the Codex window visible on an external 5120 x 2160 HiDPI display.
  3. Observe GPU usage in Activity Monitor or another GPU monitor.
  4. In this environment, GPU usage can climb very high, sometimes close to 100%.
  5. Minimize the Codex window without stopping the session.
  6. Observe that GPU usage immediately drops.
  7. Restore/show the Codex window and observe that GPU usage rises again.

Expected behavior

Codex Desktop should not drive sustained high GPU usage just because the app window is visible. Keeping a conversation visible for monitoring a long-running task should be low overhead.

Actual behavior

GPU load is high while the Codex window is visible and drops immediately when the window is minimized. The user can only keep GPU load low by minimizing Codex and monitoring session logs/CLI output instead.

Diagnostic notes / isolation

  • The same session continues running after minimizing the app, but GPU load drops immediately.
  • This suggests the app's visible UI rendering/compositing path is the trigger.
  • Large HiDPI display setup may amplify the issue.
  • BetterDisplay virtual screen mirroring was previously used for custom HiDPI experiments, but at the time of the current isolation the display was not linked to a BetterDisplay virtual screen (virtualScreenLinked@Display:2 = 0).
  • No raw session logs are attached here because they may include local paths/session details.

Related issues

This may be related, but the reproduction here is specifically tied to Codex Desktop window visibility on macOS:

  • #16857
  • #18545
  • #23072
  • #13749

View original on GitHub ↗

10 Comments

github-actions[bot] contributor · 1 month ago

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

  • #25036

Powered by Codex Action

cmmchina · 1 month ago

Additional observation / 补充观察：

中文

在最新版 Codex Desktop 26.609.41114（发布于 Jun 13, 2026）上，问题仍然很严重，并且我又观察到两个更明确的触发特征：

  1. 当 Codex App 正在显示一个 run 中的会话时，窗口越大，GPU 占用越高。
  2. 在相同窗口尺寸下，如果会话已经停止 / idle，GPU 占用会明显低很多。

这进一步说明问题和可见窗口的 UI 渲染面积、实时运行状态的刷新 / repaint / compositor 路径有关，而不像是模型推理、项目测试或后台任务本身导致的。

换句话说：

  • Codex 窗口可见 + 会话 running：GPU 占用很高，窗口越大越明显。
  • Codex 窗口可见 + 会话 stopped/idle：同样窗口尺寸下 GPU 占用低很多。
  • Codex 窗口最小化：GPU 占用会立刻下降。

This also appears distinct from the noisy logging issue discussed in #26843. That fix may reduce long-session logging / disk-write amplification, but it does not seem to resolve this visible-window GPU/compositor issue.

English

Still reproduces severely on Codex Desktop 26.609.41114 (released Jun 13, 2026). I have two more specific observations:

  1. When the Codex App is showing a running session, GPU usage increases as the Codex window gets larger.
  2. At the same window size, a stopped / idle session uses much less GPU than a running session.

This makes the issue look even more tied to visible UI rendering area plus live running-session refresh / repaint / compositor work, rather than model inference, project tests, or background agent computation.

In short:

  • Codex window visible + session running: GPU usage is high, and gets worse with larger window size.
  • Codex window visible + session stopped/idle: GPU usage is much lower at the same window size.
  • Codex window minimized: GPU usage drops immediately.

This seems separate from the noisy logging issue mentioned in #26843. That fix may address long-session logging / disk-write amplification, but it does not appear to fix this visible-window GPU/compositor problem.

laozhangzzz · 27 days ago

I can reproduce the same issue on macOS with Codex Desktop 26.616.81150.

Environment:

  • macOS: 26.5
  • Hardware: Apple M5 Max
  • Codex Desktop: 26.616.81150
  • Runtime shown in diagnostics: Electron/Chromium 149.0.7827.115
  • Display: 5120x2880, scale factor 2

Observed behavior:

  • When the Codex window is visible, GPU usage rises significantly. In my menu bar monitor it was around 33%.
  • When I minimize the Codex window, GPU usage immediately drops to 0%.
  • Activity Monitor shows WindowServer and Codex GPU/renderer-related processes as the main visible load.
  • This does not look like local model inference or project workload.

I tested several possible triggers, but none changed the behavior:

  • Collapsing/hiding the sidebar: no effect.
  • Starting a new blank thread: no effect.
  • Turning Codex Pet on/off or tucking it away: no effect.
  • Restarting Codex after upgrading: no effect.

This makes my case look less like only the thinking/shimmer animation or pet overlay, and more like the main Codex window visible-rendering/compositor path itself. The strongest signal is:

  • Codex visible: GPU high.
  • Codex minimized: GPU immediately drops to 0%.

This also looks related to #24185 because WindowServer is consistently involved.

中文补充：
我这边也复现了同类问题。侧边栏、新空线程、Pet 开关都不影响；只有窗口最小化会让 GPU 立刻从约 33% 掉到 0%。所以这不像某个聊天内容或 pet overlay，而更像 Codex 主窗口可见时持续触发 macOS WindowServer / Chromium compositor 重绘。

stors789 · 20 days ago

+1, I am experiencing exactly this issue. Here is my detailed report:

I am seeing a reproducible GPU usage issue with the Codex desktop app on macOS 27.0 beta.

Environment:

  • Device: Mac17,3
  • OS: macOS 27.0
  • Build: 26A5368g
  • Codex desktop app version: 149.0.7827.197
  • Language/locale: zh-CN

Issue:
When the Codex desktop window is focused and large/fullscreen, GPU usage immediately jumps to around 85-90%. If I switch focus away from Codex to Finder/Desktop/another app, GPU usage drops quickly to around 10-40%. If I resize the Codex window to a very small size, GPU usage also drops significantly even while Codex remains focused.

This strongly suggests the issue is related to foreground window rendering/compositing in the Codex desktop app, likely Electron/Chromium compositor behavior on macOS 27 beta.

Reproduction steps:

  1. Open Codex desktop app on macOS 27.0 beta build 26A5368g.
  2. Use a large or fullscreen Codex window.
  3. Keep Codex focused.
  4. Observe GPU usage in Stats/ioreg.
  5. Switch focus to Finder/Desktop.
  6. Observe GPU usage drop.
  7. Switch focus back to Codex.
  8. Observe GPU usage jump back up.
  9. Resize the Codex window very small.
  10. Observe GPU usage drop even while Codex is focused.

Observed data:

  • Finder focused: GPU Device Utilization around 39%.
  • Codex focused: GPU Device Utilization jumped to around 85%.
  • ioreg sample after Codex focus:
  • Tiler Utilization: 78%
  • Renderer Utilization: 85%
  • Device Utilization: 85%
  • WindowServer CPU was also elevated, around 40-50%.
  • Codex GPU process and Renderer process were active.
  • Stopping Codex Computer Use helper processes did not reduce the GPU usage.
  • Launching Codex with --disable-gpu --disable-gpu-compositing --disable-accelerated-2d-canvas made the app unresponsive, so that workaround is not usable.

Expected behavior:
Codex should not cause sustained 85-90% GPU usage simply by being focused, especially when idle or showing a normal chat/thread view.

Actual behavior:
GPU usage scales heavily with Codex window size and focus state. Large focused Codex window causes very high GPU usage; small window or unfocused Codex significantly reduces GPU usage.

Notes:
This appears separate from other system issues observed on this machine. I also identified unrelated macOS beta issues involving appstoreagent and a third-party screensaver, but the Codex GPU issue reproduces based specifically on Codex window focus and size.

pcg562240 · 5 days ago

我也遇到了这个问题，看到这贴我才找到了临时解决方案，就是让CODEX窗口最小化，笑死，希望早日修正这个BUG

stors789 · 5 days ago
我也遇到了这个问题，看到这贴我才找到了临时解决方案，就是让CODEX窗口最小化，笑死，希望早日修正这个BUG

或者把尺寸缩小

Anthoooooooony · 4 days ago

CodeX 在 macOS 上窗口最大化运行时占用的 GPU 都和我本地跑一个 7B 小模型占用的 GPU 资源差不多了，有点夸张。最小化后占用迅速归零。

ZUOHS · 4 days ago

Same for me. plz fix.

DenisPDX · 3 days ago

I can reproduce this on an Apple M1 Max (32-core GPU), and the issue persists on a newer build:

  • ChatGPT/Codex: 26.707.91948 (build 5440)
  • Codex Framework: 150.0.7871.115
  • Bundled Codex CLI: 0.144.5
  • macOS: 26.5.2 (25F84)

I tested focus and visibility as separate states using the AGXAccelerator PerformanceStatistics values:

  • Codex visible and frontmost: 62% device / 62% tiler / 61% renderer utilization
  • Codex visible but unfocused, with Finder confirmed frontmost: 30% device / 30% tiler / 28% renderer utilization
  • The unfocused reading remained stable through samples at approximately 10, 15, and 20 seconds
  • Codex hidden: 7% device / 7% tiler / 7% renderer utilization after five seconds
  • In an earlier test on framework build 150.0.7871.101, hiding dropped the same system to 1%, and restoring the window returned it to about 60%

So focus changes the severity, but does not eliminate the load while the Codex window remains visible. Hiding the window is the only tested state that brings GPU use close to idle.

The hot processes remain the Codex GPU helper (Codex (Service) --type=gpu-process), the active renderer, and WindowServer. Fresh GPU-helper/renderer process samples and app logs were uploaded privately through Codex feedback.

Feedback/session ID: 019f719f-29e1-7d82-86d5-60928330e78b
Original feedback/session ID: 019f4cdd-bee5-7023-9bc8-1c53aac62c8f

Mappsnet7 · 1 day ago

Hi guys! I found a fix: disable the translucent sidebar (both light and dark modes), and the issue should be gone

<img width="904" height="726" alt="Image" src="https://github.com/user-attachments/assets/425d53ed-bd4c-4cb3-abbb-089ba6fc819c" />