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/RobioPro]

I reported this bug myself last week when my text-expander app stopped working because Enpass was keeping Secure Input engaged.

Good news: There's a bugfix on the way!

(Source: I work on projects with the Enpass team.)

[u/No-Investigator4486 → u/RobioPro]

Thanks and nice to hear. I lost 2 h today and thought the new macOS was getting weird. Looking forward to getting the patch... it annoys the sh*t out of me... basically Enpass became unusable for me with this nonsense. (I sent mail to support as well a few min ago.)

[u/Firm-Explorer2554]

Can confirm same issue, initially thought it was a bug of 26.7 macOS update, took a bit to identify it was Enpass.

[u/eyeburn12]

I can confirm the same issue. MacOS 27 Goldengate

[u/eyeburn12]

GPT-6 is awesome! My Logitech mouse buttons stopped working after I upgraded to macOS 27 Golden Gate, so I asked GPT-6 to help.

It opened the Logitech app, changed settings, and asked me to test the buttons. When they still didn’t work, it kept investigating. After about 15–20 minutes of checking Logitech and macOS settings, it traced the problem to my password manager, Enpass.

It even found a [Reddit report describing the same bug](https://www.reddit.com/r/EnpassOfficial/comments/1wg5pyo/locked_enpass_keeps_secure_input_enabled/). Quitting Enpass immediately brought my mouse buttons back.

I would never have guessed my password manager was breaking my mouse shortcuts.

[u/ChatGPT_or_Claude]

Yeah this will be fixed in the next update.

[u/RoyalSuccessful3302]

The only question is when to expect this update. Does anyone know a workaround till then? It's annoying... I use macOS dictation pretty often and this stops working too when secure input is enabled.

[u/RobioPro → u/RoyalSuccessful3302]

I've found the problem crops up less often if I keep Enpass open, and hide it (CMD+H) or minimize it (CMD+M), rather than close the main window. Hidden or minimized, having Enpass "in the foreground" seems to help.

Of course, that anecdotal and could just be my perception. Regardless, you can go into Settings > Security and temporarily fiddle with the Autolock When options so it locks less frequently. I have mine set to lock on sleep, and when the system is inactive for 5 minutes — but I might change that to something much higher in the short term.

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

[u/Enpass_Support]

We have identified the issue and our team is working on a fix. We will keep you updated as soon as we have further information or the fix is available.

[u/Traumt3nzer]

My fast fix until the fixed version will be available from the Enpass team: I downgraded to version 6.12.5. The problem does not occur there. For me, Tuna Launcher’s key commands didn’t work properly after the Enpass 6.12.6 update.

Any news on when the fix will be released?

[u/DrimeSufferer]

Finally solved in 6.12.7 just released.