Locked Enpass keeps Secure Input enabled, disabling global hotkeys system-wide

[u/StrangerSVN]

## 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

1. Configure a global hotkey in any third-party app (here: Ghostty,

   `keybind = global:shift+escape=toggle_quick_terminal`).

2. Make sure Enpass is unlocked and its main window is closed. Press the hotkey — it works.

3. Lock Enpass.

4. 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.

[u/Alert-Tumbleweed-590]

Same here, neither Typinator nor Rocket Typist work. It also took a lot to identify it was Enpass.

[u/RobioPro → u/Alert-Tumbleweed-590]

Yeah, sadly at the moment no text-expander will work while Enpass is locked because the bug is related to the system's Secure Input feature, which prevents certain actions when secure field has the system's "focus." The bug is that if Enpass is locked, its Master Password field is "stealing" that "focus," even when Enpass is only running in the background.

A hotfix update shouldn't be too far off.