Support keyed shortcuts during Secure Event Input

[LuisUrrutia]

Option-Space in Hybrid mode did nothing, even with a live, enabled event tap. Supported keyed shortcuts now use public Carbon system hot-key registrations, with press/release events feeding the existing recording-mode handling.

During the original diagnosis, IsSecureEventInputEnabled() returned true, and ioreg reported kCGSSessionSecureInputPID=40972. That live PID mapped to Steam's steam_osx executable. After Steam exited, ps confirmed the PID was gone, but macOS still reported the same owner PID and Secure Event Input remained enabled. VoiceInk still had an enabled event tap, and the shortcut still failed.

These observations establish a Steam-associated Secure Input state and a stale owner/state after exit in that session. They do not establish whether Steam, WindowServer, or macOS caused the persistence, or a repeatable Steam launch recipe. A later check reported Secure Input disabled and no former owner PID; what cleared the state is unknown.

Apple documents that Secure Event Input withholds keyboard events from event taps, including when the process enabling it is in the background. A live tap therefore does not establish that VoiceInk can receive the shortcut. Apple TN2150: https://developer.apple.com/library/archive/technotes/tn2150/_index.html. AltTab's API experiment matrix documents registered hot keys working through Secure Input: https://github.com/lwouis/alt-tab-macos/blob/609872b10605672bd0e9f8b012449f47c0573539/src/experimentations/README.md.

The shared monitor covers recording, mode, global utility, and visible recorder-panel shortcuts:

• Successfully registered keyed combinations use only the system hot-key route for transitions, preventing duplicate dispatch through the tap. Registrations and handlers are released when monitoring stops.
• Modifier-only shortcuts, mouse buttons, explicit Fn combinations, and failed registrations retain the event-tap route. Additional-key interruption detection remains limited to events macOS delivers during Secure Input.
• If the tap cannot start and system registrations cannot cover every configured shortcut, startup releases all registrations before reporting failure. A fully registered set can start without a tap.
• Tests cover modifier conversion, real registration release/reuse, and both startup outcomes when tap creation fails. A standalone physical-keyboard probe reports success only when Secure Input is enabled at startup, both transitions, and every intervening 50 ms sample. An observed disabled state exits as inconclusive.

The patch does not disable Secure Input, capture protected text, clear another process's protection, or require restarting macOS.

Validation on macOS 26.6.2 / Xcode 26.6, arm64:

The behavioral, build, and launch checks below ran before the final test-name-only follow-up. That follow-up changes no test body, production code, or probe code; Swift parsing and diff checks passed afterward.

• Passed: the Release VoiceInkTests suite with ENABLE_TESTABILITY=YES: seven shortcut test cases plus the pre-existing empty example. The new partial-startup test failed before the rollback fix and passed afterward.
• Passed: Release build with explicit ad-hoc signing (CODE_SIGN_IDENTITY=-); codesign --verify --deep --strict; a separate launch check confirmed the exact built app finished launching and remained alive for 12 seconds.
• Passed: standalone production probe compilation and seven simulated probe-verdict scenarios. The real probe returned inconclusive (exit 2) with Secure Input disabled. Simulated events validate the verdict logic, not physical hot-key delivery.
• Passed: an AddressSanitizer harness using the unchanged production registration object exercised 100 duplicate-registration failures, subsequent Carbon event dispatch, and release/reuse without a memory error.
• Passed: make check and git diff --check.
• The earlier VoiceInkUITests/VoiceInkUITests/testExample attempt could not start because XCTest timed out while enabling automation mode (exit 65). UI automation remains unverified.

Physical keyboard delivery during Secure Input, short/long Hybrid and push-to-talk holds, and a complete dictation cycle remain unverified. During the original diagnosis, a minimal prototype reported successful handler installation and registration with secureInput=true; no physical press/release was captured. Synthetic keystrokes were not treated as proof.

Substantial AI assistance was used for implementation, code review, verification, and PR text. No human code-review or physical-test completion is claimed. This submission acknowledges the repository's current policy against external PRs.

[cubic-dev-ai]

All reported issues were addressed across 5 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 3 files (changes from recent commits).

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>