mac: dictation shortcut stops working after the app sits idle (3.3.0, Secure Input left enabled) #1634

HEX version

3.3.0 (macOS arm64)

Platform

macOS

System details

MacBook Pro, Apple M1 Max, macOS 26.6.2 (25G83)

What happened?

The dictation shortcut stops responding after Hex has been idle for a while.

• Shortcut: Shift+Cmd+M
• Shortcut mode: Hold
• "Release microphone while idle": on
• Microphone: AU05 (USB composite HID keyboard + USB audio)

It works for one or two dictations. After leaving the machine/the app idle for a few minutes, holding the shortcut does nothing: no sound, no indicator, no recording. Quitting and relaunching Hex restores it immediately, then it fails again after another idle period.

I suspect the macOS Secure Input flag. While the shortcut was dead, IsSecureEventInputEnabled() returned true; while it works it returns false. No other app regressed at the same time, and switching focus to Finder did not clear it.

Hex's main binary imports _EnableSecureEventInput / _DisableSecureEventInput (checked with nm -u), while none of the other third-party apps running here do. This looks like Hex enabling Secure Input on some path and not disabling it, which would block its own event tap (suppression::run_event_tap) and the NSEvent global monitor.

This looks like the same symptom as #195, and the 3.3.0 release notes claim a fix ("mac: the shortcut works again ... after hex sat idle for a while ..."), but it still reproduces on 3.3.0.

Steps to reproduce

1. Use Hex 3.3.0 on macOS in Hold mode.
2. Dictate once or twice successfully.
3. Leave it idle for a few minutes without pressing the shortcut.
4. Hold the shortcut again — nothing happens (no sound, no indicator).
5. Quit and relaunch Hex — it works again for a while.

Additional context

• process.log shows dictation listener started device=AU05 after a restart, but no key events are logged while the shortcut is dead.
• No USB reset/re-enumeration of AU05 appears in the logs during the failure.
• Related: Hex dictation shortcut stops working after a couple of minutes on MacOS (M3, 26.6.1) #195 (same symptom; that report also mentioned kCGSSessionSecureInputPID and suppression::run_event_tap).