[BUG] Claude Desktop causes repeated WindowServer crashes on macOS 15.7.3 (Sequoia) — VirtualDisplayListener deadlock

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

After updating Claude Desktop today (29 March 2026), my MacBook has crashed and restarted 4+ times. WindowServer is killed by the userspace watchdog each time. I have not used Cowork at all — the crashes appear to be triggered by the app launching and/or navigating to the Cowork tab, with no active session started.

What Should Happen?

The app should not initialise a virtual display or interact with the display server in a way that causes WindowServer to become unresponsive. The Cowork virtual display should not be initialised until the user explicitly starts a Cowork session.

Error Messages/Logs

Steps to Reproduce

1. Update to latest Claude Desktop
2. Launch the app and log in
3. Navigate to the Cowork tab — do not start a Cowork session
4. Use chat function
5. Within 15–60 minutes, WindowServer crashes and macOS forces a logout/restart

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.1.7203

Claude Code Version

2.1.87

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Crash Evidence

Five WindowServer crash reports today, all following the same pattern:

WindowServer_2026-03-29-180735_userspace_watchdog_timeout.spin
WindowServer_2026-03-29-175014_userspace_watchdog_timeout.spin
WindowServer_2026-03-29-174336_userspace_watchdog_timeout.spin
WindowServer_2026-03-29-165352_userspace_watchdog_timeout.spin
WindowServer_2026-03-29-154301_userspace_watchdog_timeout.spin

(Spin files attached below.)

Crash reason from spin file:

(1 monitored services unresponsive): checkin with service: WindowServer returned not alive
with context: is_alive_func returned unhealthy : Display 69734272 not ready:
DisplayID: 0x4280f80  Surface Use Counts: 3(3) 5(1) 10(1)

Key thread from stack trace:

The com.apple.VirtualDisplayListener thread is frozen in CoreDisplay, waiting on a kernel call that never returns. All 12 stack samples across the 5.58s watchdog window show the same stuck state — it never recovers. The main ws_main_thread and CoreAnimation render server thread are also stuck in the same kernel call.

App log evidence (main.log):

Computer use was immediately configured on launch before any user interaction with Cowork:

[chicago] GrowthBook chicago_config: raw={"enabled":true,...} → enabled=true

This suggests the Cowork virtual display is being initialised at launch or on tab navigation, not only when a session is explicitly started by the user.

Related Issues

• #24699 — Failed to start claude workspace on macOS Sequoia 15.7.3 (same OS)
• #32207 — Claude Desktop freezing with Cowork mode enabled, 9.3GB VM bundle (macOS 15.6)
• #26087 — Cowork VM Kernel Panic Deadlocks Main Thread (macOS 26)

Impact

The machine is unusable while Claude Desktop is running. Five forced restarts in under 3 hours today, with data loss risk each time.

Workaround:

Quit Claude Desktop entirely and use claude.ai in the browser.

WindowServer-SPIN.zip