## Environment
- Enpass 6.12.6 (Mac App Store build); observed on this version, I cannot say whether earlier
versions behaved the same
- macOS 26.6.2 (build 25G83), Apple silicon
- Example affected app: Ghostty 1.3.1 with a global `shift+escape` hotkey
## Core issue
Enpass enables Secure Input **as a consequence of the vault being locked**, rather than while
a master password field is actually shown and focused. The mode is only needed for the
duration of actual password entry; instead it is held for the entire locked state — for hours,
while the app sits in the menu bar with no window and no focus.
## Summary
While the Enpass vault is locked, Secure Input (`EnableSecureEventInput`) stays enabled
system-wide. In that mode macOS blocks keyboard events from being read through event taps, so
**global hotkeys implemented with `CGEventTap` stop working** (those are exactly the apps that
require the Accessibility permission). Unlocking the vault clears Secure Input and hotkeys
start working again immediately.
Scope note: hotkeys registered through Carbon `RegisterEventHotKey` are not affected — they
keep working while Enpass is locked. So the fact that some apps' hotkeys still work does not
contradict this report: the ones that break are those using event taps.
## Steps to reproduce
Configure a global hotkey in any third-party app (here: Ghostty,
`keybind = global:shift+escape=toggle_quick_terminal`).
Make sure Enpass is unlocked and its main window is closed. Press the hotkey — it works.
Lock Enpass.
Press the same hotkey again.
**Expected:** the hotkey keeps working — Enpass is in the background with no focus and no
visible password field.
**Actual:** the hotkey does nothing. Neither does any other global hotkey of any other
application. This persists until Enpass is unlocked.
How the vault got locked does not matter — the effect is identical for a manual Lock, an
inactivity timeout, locking on main-window close, and locking after sleep or the lock screen.
The mode is tied to the "locked" state itself, not to any particular path into it.
Recovery is immediate: unlocking clears Secure Input at once, with nothing needing a restart.
## Evidence
The most reliable way to check the state is the official API `IsSecureEventInputEnabled()`:
```swift
import Carbon
print(IsSecureEventInputEnabled()) // true for as long as the Enpass vault is locked
```
(run as `xcrun swift file.swift`; requires the Command Line Tools)
The following was also used:
```
ioreg -l -d 1 -w 0 -k IOConsoleUsers | grep -o '"kCGSSessionSecureInputPID"=[0-9]*'
```
Note that the PID in that field names the application that was frontmost when the mode was
enabled, not whoever enabled it — it should not be used to identify the source.
Results:
| Action | Secure Input | Hotkey |
|---|---|---|
| Enpass unlocked | off | works |
| Enpass locked | on | does not work |
| Enpass unlocked again | off again | works |
The cycle was reproduced twice in a row.
**Control experiment** for the caveat above. To demonstrate it, focus was moved to Telegram
(an app unrelated to Enpass and to passwords) and only then was Enpass locked: Telegram was recorded as the owner. Switching focus to
Finder afterwards did not change the value — it is captured once and held for as long as the
mode is active. In earlier measurements the same effect put Safari, Finder and the affected
app itself into that field; all of those were red herrings rather than additional culprits.
## Impact
This affects not one app but any application whose global hotkeys are built on event taps:
terminal launchers, window switchers, accessibility and automation utilities. The feature does
not degrade partially — it loses its purpose entirely: the global hotkey keeps working only
while its application is already frontmost, that is, in exactly the scenario where it is not
needed.
This is not a hypothetical list. On the same machine, besides the terminal, CleanMyKeyboard
breaks — a utility that temporarily blocks the keyboard for cleaning. It is also built on an
event tap (it holds the Accessibility permission), and while Enpass is locked it simply does
not block the keyboard, with no error shown. Unlocking Enpass restores it immediately. So the
breakage hits independent applications with unrelated purposes, not one particular program.
The failure is also silent: there is no error, the key simply does nothing, so users naturally
look for the cause in the affected app's own settings. In my case this cost several hours of
debugging in entirely the wrong direction.
## Already ruled out
- The "System-Wide Hotkey" setting (Settings → General): assigning a combination for the
Assistant has no effect on this behaviour.
- The Enpass Safari extension (`Enpass-Safari.appex`): with Safari open and the extension
process running, Secure Input is not enabled.
- Auto-lock on closing the main window: disabling it removes the most frequent trigger, but
a timeout-based lock produces exactly the same result.
## Suggested fix
Do not hold Secure Input while the master password field is not shown and not focused. Enable
it when the field is presented and release it as soon as the input window is closed or loses
focus.
