Fix Flow shortcuts blocked by macOS Secure Keyboard Entry / Secure Event Input

Last updated: October 30, 2026

Available on: Mac

If Fn+Space (hands-free) or Escape (cancel) stops responding while Fn hold-to-talk and typing still work, macOS Secure Event Input may be blocking Flow.

Quick checks

Test with your own shortcuts if you've changed the Mac defaults of Fn hold-to-talk, Fn+Space hands-free and Escape cancel. If onboarding found no Apple Fn key while your binding was Fn, Flow switched to Ctrl+Opt hold-to-talk, Ctrl+Opt+Space hands-free and Escape cancel; secure input blocks Ctrl+Opt+Space but not the Ctrl+Opt hold.

Note: Finish onboarding before troubleshooting. During onboarding, dictation and hands-free work only on enabled setup pages, double-pressing Fn also works in the hands-free tutorial, and the Set-shortcut page registers keys without starting dictation.

  • Accessibility access: Shortcuts and dictation require it. Enable Wispr Flow in System Settings → Privacy & Security → Accessibility, then retest; no relaunch is needed. Missing or revoked access triggers “Accessibility Permission Required” with “Flow needs accessibility access to work properly.” Its “Open Settings” action requests access from macOS.

  • Just launched, woke or unlocked? Shortcuts can pause while Flow restores keyboard access; this recovers automatically, so retry your hands-free shortcut. If Flow stops retrying and shows a persistent failure notification, restart Flow and retest.

  • Check the pattern: Test typing in a non-password field and Fn hold-to-talk. If both work but Fn+Space fails, continue below; if either also fails, include that detail when contacting support. A loading error can accompany failure of all shortcuts, and typing inside Flow does not confirm shortcuts work.

How to fix it

A focused password field can enable Secure Event Input. Password fields normally turn it off when focus moves away, but closing a window with the field still focused can leave it held, and Terminal and iTerm2 can keep it enabled in the background, so switching windows may not release it.

Flow shows no on-screen alert for this block, and macOS can misidentify the responsible app, naming the frontmost app when a background app is the cause — test more than one suspect if needed. Stop when Fn+Space starts hands-free dictation; no Flow restart is needed once the block clears.

Tip: With the default shortcuts, you can still hold Fn to dictate or double-press Fn within 500 ms for hands-free while blocked, because Fn is a modifier key. A third press within the same 500 ms cancels a just-started hands-free session; a quick second press of the hands-free shortcut also dismisses one, but only if that shortcut responds.

  1. Click a non-password field in the suspected app, or switch to another app.

    Test Fn+Space. If it still fails, continue.

  2. Uncheck Terminal → Secure Keyboard Entry if Terminal is running and the option is checked.

    Test Fn+Space again; disabling this setting does not guarantee other apps have released secure input.

  3. Close a suspected app's window, starting with password managers such as 1Password.

    Test Fn+Space. If it still fails, quit that app next.

  4. Quit the suspected app with Cmd+Q.

    1. Reopen Flow before testing if it was the app you quit.

    Test Fn+Space. If still blocked, repeat with another suspected app.

If the app has quit but shortcuts remain blocked

When the app holding secure input has already exited, macOS can retain a stale block. Quitting more apps cannot release it; a lock/unlock cycle or logging out clears it. Neither is a guaranteed fix while an app still holds secure input.

Warning: Save your work before logging out.

  1. Lock your Mac with Ctrl+Cmd+Q or Apple menu → Lock Screen.

  2. Unlock your Mac.

    Test Fn+Space. If it starts hands-free dictation, stop; otherwise, continue.

  3. Log out using Apple menu → Log Out.

  4. Sign in to your Mac again.

    Test Fn+Space. If shortcuts still fail, contact support.

Other causes

Can Flow itself cause this?

Flow can hold secure input if a password field was focused in one of its windows when that window closed without the field losing focus. The hold stays until Flow quits, so follow the quitting and reopening steps above with Flow as the suspected app. Restarting Flow does not clear another app's hold or a stale macOS block.

If a key release was missed

A missed key release can make shortcuts unresponsive independently of secure input. Flow clears keys that still appear held after more than 10 seconds, and when no dictation is running, retrying your configured shortcut can restore it sooner. During dictation, that timed clearing never affects keys in the active dictation shortcut.

Still need help?

Contact support if:

  • You cannot identify which app is blocking shortcuts.

  • Fn hold-to-talk also fails after checking Accessibility permission and finishing onboarding.

Include your macOS version, Mac and keyboard model, apps open when the issue began, how long shortcuts have been blocked, and what you've tried. If this started after closing a Flow sign-in window, include your logs.