[WITHDRAWN — misattributed] Secure keyboard entry stuck system-wide on macOS: root cause is a loginwindow lock-screen leak, not Claude Desktop

[!IMPORTANT] Withdrawn by the reporter, 2026-08-21. This is not a Claude Desktop bug. The root cause has been found and it is in macOS itself. loginwindow leaks secure event input every time the lock screen appears — many CGSSetSecureEventInput: 1 calls against a single : 0. Because loginwindow never exits, the leaked count is never reclaimed and secure event input stays on system-wide. Claude Desktop was named only because kCGSSessionSecureInputPID reports whichever app is frontmost when the leak happens, not the app responsible. On this machine that record has since named ChatGPT, Google Chrome, Mail, WorkFlowy and a locally built SwiftUI app with no secure-input code in it at all. My apologies to the maintainers for the misdirected report. Full evidence is in the closing comment below, and the bug has been filed with Apple. The original text is left below unaltered for the record.

---

Environment

• App: Claude Desktop (/Applications/Claude.app), version 1.24012.9
• OS: macOS 26.5.2 (build 25F84)
• Hardware: MacBook Pro (Apple Silicon, M3 Max)

Summary

Claude Desktop enabled macOS secure keyboard entry (CGSSetSecureEventInput) within ~70 seconds of launch and held it for the entire 14-hour life of the process. While held, every keystroke-monitoring utility on the system was silently disabled (TextExpander, Keyboard Maestro, FluidVoice — anything using event taps). When the app was quit, the claim was not released: kCGSSessionSecureInputPID still pointed at the dead PID, and only a reboot/re-login clears it. There is no user-visible indication in the app that it is holding secure input.

Timeline (from unified log and ioreg)

• 2026-07-26 20:28:41 — Claude Desktop launches (PID 719).
• 2026-07-26 20:29:50 — WindowServer log already shows secure input active and attributes enforcement to it:

``
20:29:50.424 E WindowServer [com.apple.SkyLight:processes] [SetFrontProcessWithInfo]: CPS: Denying Adobe Content Synchronizer the right to be in front because secureTextInput is active and this process doesn't have secure text mode enabled...
``
(identical denials follow for other background processes)

• 2026-07-26 20:29 → 2026-07-27 ~10:30 — secure input held continuously for ~14 h. All system-wide text expansion, macros, and dictation input dead. ioreg -l -w 0 | grep SecureInput shows "kCGSSessionSecureInputPID"=719, and ps -p 719 shows /Applications/Claude.app/Contents/MacOS/Claude.
• 2026-07-27 ~10:40 — user quits Claude Desktop. PID 719 no longer exists, but ioreg still reports "kCGSSessionSecureInputPID"=719. Screen lock/unlock (loginwindow sets and releases its own secure input correctly at 10:26:5x) does not clear the stale claim. Only reboot/re-login clears it.

Expected behavior

1. The app should enable secure keyboard entry only while a password/secure field actually has keyboard focus, and release it as soon as focus leaves that field (and unconditionally on window blur / app background / quit).
2. The app should never hold secure input while idle in the background for hours.

Actual behavior

Secure input is enabled shortly after launch (no password was being typed; the app was signed in and idle) and is never released, disabling all keystroke-listening utilities system-wide until the app quits and the machine is rebooted (the stale post-quit claim is arguably an OS bug, but the app holding the claim for 14 idle hours is what exposes it).

Repro notes

Not yet reduced to a minimal trigger. The enable happened within ~70 s of app launch during normal startup (session restore), suggesting a password-type field in a webview receives focus during startup and the corresponding release never fires. Happy to run diagnostics on request.

Impact

Silent, system-wide breakage of third-party accessibility/productivity tools with no attribution visible to the user — this class of failure is very hard for end users to diagnose (nothing in the Claude UI indicates secure input is held).