macOS Intel: repeated WindowServer watchdog exits while Codex Desktop is visible, preceded by AppleIntelICLLPGraphicsFramebuffer VRR_ERR

Open 💬 1 comment Opened Aug 15, 2026 by joyce677

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

ChatGPT/Codex Desktop 26.810.41047 (build 6570), bundle identifier com.openai.codex.

Bundled Chromium: 151.0.7922.137.

What subscription do you have?

Unknown / not provided. This appears to be a local macOS graphics and compositing issue.

What platform is your computer?

Darwin 25.6.0 x86_64 i386

  • macOS 26.6.2, build 25G82
  • MacBook Pro MacBookPro16,2
  • Quad-core Intel Core i5
  • 16 GB RAM
  • Intel Iris Plus Graphics, 1536 MB dynamic VRAM
  • Built-in 2560 × 1600 Retina display only; no external display

What issue are you seeing?

On this Intel Mac, normal use of Codex Desktop with its window visible is highly correlated with repeated macOS WindowServer watchdog exits. The failure closes or restarts the graphical login session, rather than only crashing Codex.

Five confirmed WindowServer exits occurred on 2026-08-14 at approximately:

  • 05:20:31
  • 10:23:41
  • 10:47:31
  • 12:38:01
  • 13:20:51

The repeated sanitized failure signature is:

[ Watchdog ] display <redacted> has become stuck after 10.00s of unreadiness (2403 failures)
[ Watchdog ] Inform the watchdog that all displays are stuck.
Window Server exited, closing down the session immediately

Before several incidents, the Intel framebuffer driver logged:

AppleIntelICLLPGraphicsFramebuffer
[IGFB][ERROR][TRANSACTION] FB0: VRR_ERR
remLinesForOnGlass > (vrrMax + Guardband)
Forcing ... to avoid hang

There were also bursts of:

Fallback GPU Display Pipe transaction submission failed

This may ultimately be an Apple Intel display-driver failure, but Codex window visibility and rendering appear to be a reproducible or highly correlated trigger. I cannot establish that Codex is the sole cause.

What steps can reproduce the bug?

A deterministic minimal reproduction has not yet been isolated, but this sequence reproduced the failure repeatedly:

  1. Launch Codex Desktop on the Intel Mac described above.
  2. Open a task and keep the Codex window visible during normal use.
  3. Continue using the app for an extended period, including viewing an active or recently active conversation.
  4. The display eventually becomes unresponsive, and WindowServer exits after the 10-second display-unreadiness watchdog threshold.
  5. Inspect the sanitized macOS unified logs around the incident. The watchdog signature above appears, and several incidents are preceded by the Intel framebuffer VRR_ERR messages.

The issue does not occur on every launch, but it happened five times in one day with the same watchdog signature.

What is the expected behavior?

Keeping the Codex Desktop window visible should not create a display-pipeline condition that can hang WindowServer or terminate the macOS graphical session. Rendering should remain stable on supported Intel Macs, including when the app contains active progress UI, long conversations, translucent surfaces, or animations.

Additional information

Read-only isolation performed after the incidents:

  • Live samples showed WindowServer reaching 50.9% CPU and about 616 MB RSS while Codex was visible.
  • No continuous ScreenCaptureKit or replayd capture stream was found around these crashes.
  • Computer History was disabled, and its client was not active.
  • Computer Use was enabled, but the failure signature differs from the IOSurface and capture-path crash in #37062 and the stale ScreenCaptureKit stream in #35659.
  • Reduce Transparency was enabled; Reduce Motion was disabled.
  • No external display was connected.

Potentially related reports:

  • #25077: high CPU and GPU load on an Intel Mac
  • #30464: visible Codex window drives WindowServer and GPU load
  • #26736: minimizing the Codex window immediately reduces GPU usage
  • #37062: WindowServer crash in an IOSurface and capture path
  • #35659: stale ScreenCaptureKit stream causing high WindowServer GPU usage

I searched the repository for VRR_ERR, AppleIntelICLLPGraphicsFramebuffer, 2403 failures, and the exact watchdog wording and found no matching report.

No raw crash report, session transcript, username, device serial number, UUID, display identifier, or local path is included here. A useful investigation area may be the Electron/Chromium compositing and presentation path while the Codex window is visible on Intel graphics, especially animation, translucent layers, and variable-refresh timing.

View original on GitHub ↗

1 Comment

guiradha · 5 days ago

Adding another data point — same hardware, same signature:

Environment

  • MacBookPro16,2 (13" 2020), quad-core Core i5, Intel Iris Plus Graphics, 16 GB RAM
  • macOS 26.5.2 (25F84)
  • ChatGPT/Codex Desktop 26.818.41509 (com.openai.codex), internal Retina display only

Pattern

  • 25 WindowServer userspace-watchdog terminations since Aug 16 (7 on Aug 22 alone).
  • Every single one shows the identical termination context:

is_alive_func returned unhealthy : Display 69734272 not ready: DisplayID: 0x4280f80
Surface Use Counts: 6(1) 11(1) 12(3) ... Transactions: [ Active ] [ Waiting ] [ Waiting ]

  • Cross-checked each stackshot: ChatGPT/Codex processes were running at capture time

in the 22 most recent crashes (the 2 earliest predate my ChatGPT usage). No Claude
Desktop, VNC server, BetterDisplay/Duet/Luna/OBS or similar virtual-display software
was running in any of them.

  • Crashes cluster during idle/display-off transitions (displayState: OFF).
  • Notably, Computer Use is disabled here ([mcp_servers.computer-use] enabled = false

in ~/.codex/config.toml), yet crashes continue — consistent with the theory that
window visibility/rendering on Intel ICL graphics is sufficient to trigger it
(#26736, #30464), no active Computer Use session needed.

Happy to attach the full .ips stackshots and userspace_watchdog_timeout.spin files.
Running a controlled 48h test with the app fully quit; will report results here.