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

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.

Start with the five sanitized unified-log incidents and the reported AppleIntelICLLPGraphicsFramebuffer VRR_ERR and WindowServer watchdog signatures. Compare the related reports #25077, #30464, #26736, #37062, and #35659, then investigate the Electron/Chromium compositing path while the Codex window is visible on Intel graphics. Done would require a deterministic reproduction and evidence clarifying whether Codex rendering is a trigger or the issue is confined to the macOS display driver.