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

Last updated: September 23, 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

Note: During onboarding, hands-free shortcuts work only on enabled setup pages; double-pressing Fn also works in the hands-free tutorial. Finish onboarding before troubleshooting.

Use your assigned shortcuts below if you've changed these Mac defaults. Both hands-free and cancel shortcuts are customizable. During dictation, Flow keeps Escape from reaching the app you're typing in.

If Fn wasn't available during onboarding, the defaults are Ctrl+Opt for hold-to-talk, Ctrl+Opt+Space for hands-free, and Escape for cancel. This block affects Ctrl+Opt+Space, but not the Ctrl+Opt hold.

  • Accessibility: Enable Wispr Flow in System Settings → Privacy & Security → Accessibility, then retest; shortcuts and dictation require this permission, and Flow recognizes the grant without a relaunch.

  • Just launched, woke or unlocked? Shortcuts can pause while Flow restores keyboard access after launch, wake or unlock; this recovers automatically, so retry your hands-free shortcut.

  • Check the pattern: Test typing in a non-password field and Fn hold-to-talk; if both work but Fn+Space fails, continue below, and if either also fails, include that detail when contacting support.

If a key release was missed

A missed key release can also make shortcuts appear unresponsive, separately from secure input. Flow automatically clears keys that appear held for more than 10 seconds, with recovery checks about 5 seconds apart. Retrying the shortcut can also restore it sooner when no dictation is running.

During dictation, only timed recovery applies. If Flow cannot confirm that you've released the dictation key, it keeps dictation running rather than cutting it off.

How to fix it

A focused password field can enable Secure Event Input. Terminal and iTerm2 can keep it enabled in the background, so switching windows may not release it.

Flow does not show customers an on-screen alert for this block. macOS can misidentify the app responsible, so test more than one suspected app if needed.

Stop when Fn+Space starts hands-free dictation; no Flow restart is needed once the block clears.

  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.

Tip: With the default shortcuts, hold Fn to dictate or double-press Fn for hands-free while blocked. Fn remains usable because it's a modifier key. To cancel a just-started hands-free session, press the dictation key a third time in quick succession. A quick second press of the hands-free shortcut also dismisses a just-started session, but only if that shortcut responds.

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 that stale block; 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.

FAQs

Can Flow itself cause this?

Flow can hold secure input if a password field, such as sign-in, was focused in one of its windows when the window closed without the field losing focus. The hold stays until Flow quits; 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.

Still need help?

Contact support if:

  • Shortcuts still fail after quitting suspected apps and signing out and back in.

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