Preflight Checklist
What's Wrong?
Title: Claude Desktop (macOS) can run windowless and lock out all system input; requires force-restart
App version: 1.24012.9
macOS: [your version — Apple menu → About This Mac]
Hardware: Apple Silicon (Neptune)
Summary: Claude Desktop repeatedly enters a state where the main window is gone but the app keeps running (main process + renderer + video-capture helper all alive). The quick-entry/screen-capture overlay arms and becomes stuck, and while stuck it captures all keyboard/mouse system-wide — no other app receives input. Esc does not dismiss it. Recovery has required force-restarting the Mac.
Impact: Total system input lockout. This is an accessibility/safety-critical defect: a single app should never be able to make the machine unusable with no software escape.
Steps observed:
App left running; main window closes, leaving a windowless background instance (verified via pgrep — main, renderer, GPU, and video_capture.mojom.VideoCaptureService helper all present, no window).
Invoking the chat/capture overlay arms "Drag to take a screenshot."
Overlay hangs; Esc does not cancel; input is captured globally.
Only recovery was a hardware force-restart.
Additional findings:
open /Applications/Claude.app and open "claude://claude.ai/new" do not surface a window when the app is already running windowless; the URL scheme appears to route in background without window.show() (cf. #65610).
Only the Window → Show Main Window menu item reliably recreates the window. ⌘N (File → New Conversation) instead triggers the capture loop, suggesting a global-shortcut collision intercepting ⌘N.
Disabling Quick Access shortcut in Settings reduced but did not eliminate the capture-loop trigger.
Expected:
Esc always cancels the capture overlay.
The overlay must never hold a global input grab it can't release.
Closing the last window should quit (or reliably reopen via Dock/menu), not leave a headless input-capturing instance.
Settings toggles should take effect on the running instance without restart.
What Should Happen?
Claude should not trigger Screen Capture. It should allow cancel it with ESC.
Error Messages/Logs
NO error, just locked out of all interaction on the system.
Steps to Reproduce
Hit option
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
No response
Claude Code Version
1.24012.9
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
This is in the desktop app.
This on Golde Gate Beta 4
Preflight Checklist
What's Wrong?
Title: Claude Desktop (macOS) can run windowless and lock out all system input; requires force-restart
App version: 1.24012.9
macOS: [your version — Apple menu → About This Mac]
Hardware: Apple Silicon (Neptune)
Summary: Claude Desktop repeatedly enters a state where the main window is gone but the app keeps running (main process + renderer + video-capture helper all alive). The quick-entry/screen-capture overlay arms and becomes stuck, and while stuck it captures all keyboard/mouse system-wide — no other app receives input. Esc does not dismiss it. Recovery has required force-restarting the Mac.
Impact: Total system input lockout. This is an accessibility/safety-critical defect: a single app should never be able to make the machine unusable with no software escape.
Steps observed:
App left running; main window closes, leaving a windowless background instance (verified via pgrep — main, renderer, GPU, and video_capture.mojom.VideoCaptureService helper all present, no window).
Invoking the chat/capture overlay arms "Drag to take a screenshot."
Overlay hangs; Esc does not cancel; input is captured globally.
Only recovery was a hardware force-restart.
Additional findings:
open /Applications/Claude.app and open "claude://claude.ai/new" do not surface a window when the app is already running windowless; the URL scheme appears to route in background without window.show() (cf. #65610).
Only the Window → Show Main Window menu item reliably recreates the window. ⌘N (File → New Conversation) instead triggers the capture loop, suggesting a global-shortcut collision intercepting ⌘N.
Disabling Quick Access shortcut in Settings reduced but did not eliminate the capture-loop trigger.
Expected:
Esc always cancels the capture overlay.
The overlay must never hold a global input grab it can't release.
Closing the last window should quit (or reliably reopen via Dock/menu), not leave a headless input-capturing instance.
Settings toggles should take effect on the running instance without restart.
What Should Happen?
Claude should not trigger Screen Capture. It should allow cancel it with ESC.
Error Messages/Logs
Steps to Reproduce
Hit option
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
No response
Claude Code Version
1.24012.9
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
This is in the desktop app.
This on Golde Gate Beta 4