Claude desktop app crashes/hangs on Caps Lock keypress

App: Claude desktop, version 1.24012.1
OS: macOS 26.3.1 (build 25D771280a)

Summary

Pressing Caps Lock while a Claude Code session is focused causes the app to crash/become unresponsive immediately. This has now happened 6-8 times across separate sessions.

Repro steps

1. Open the Claude desktop app with a Claude Code session focused (app is mid-task / busy).
2. Press Caps Lock.
3. App crashes/hangs immediately.

A sharper repro was also found: it is not only the Caps Lock toggle itself — any keypress while Caps Lock is engaged (i.e., typing a character with Caps Lock already "on") also triggers an immediate crash/hang.

What's been ruled out

• No third-party keyboard remapping software installed (Karabiner-Elements not present).
• No OS-level Caps Lock remap active (com.apple.keyboard.modifiermapping domain empty).
• No active session-level key remap (hidutil property --get "UserKeyMapping" returns null).
• No custom per-app menu shortcuts for Claude.app (NSUserKeyEquivalents unset).
• No custom global key equivalents (NSGlobalDomain NSUserKeyEquivalents unset).
• No custom system-wide keyboard shortcut overrides (com.apple.symbolichotkeys.plist has no enabled overrides relevant to this).

Notable diagnostic detail

No macOS crash report (.ips) is generated for the Claude process in ~/Library/Logs/DiagnosticReports/ or ~/Library/Logs/DiagnosticReports/Retired/, and nothing shows up in the unified system log (log show --predicate 'process == "Claude"') around the crash times — even though this same machine reliably generates .ips reports for other apps that crash (e.g. railway, node). This suggests the app isn't hitting a fatal exception/segfault, but rather hanging or silently quitting in response to the Caps Lock modifier-key event (likely a flagsChanged-related code path), especially when the app already has work in flight ("busy").

Impact

Reproducible and disruptive enough that the user is now avoiding the Caps Lock key entirely to keep working.