Secure Input blocking other apps event taps

Hi,

1Password 8.12.26-31 mentions in it’s Release Notes

We’ve fixed an issue where 1Password could keep Secure Input enabled longer than intended.

I’m on 1Password for Mac 8.12.32 (81232018) and I can still reproduce the issue both with the repro steps pitnikola and I mentioned.

It’s quite blocking in my workflow so I will try out Keeper app if the migration is easy. But feel free to reach out for me to test again if you fix it.

Hi ​@adilerchouk, I’m sorry for any confusion caused here, and for the continued disruption to your workflow. The fix you’ve highlighted in our release notes was for a different issue with 1Password and Secure Input. The issue you’ve reported is still being worked on at the moment.

Thanks for checking back in about this, and for your kind offer to test a fix once one is released!

For weeks I’ve been seeing a recurring issue on an M2 MacBook Pro running macOS 26.5.2 (25F80). When it occurs:

• Fn-E won’t open the emoji picker
• Fn-Fn won’t start Dictation
• Alfred snippets stop expanding
• Keyboard Maestro typed-string triggers stop working
• Sometimes the emoji picker opens, but clicking an emoji doesn’t insert it

Running:
ioreg -l -w0 | grep SecureInput

shows that Secure Input is active. Different processes have appeared as the owner, including Proton Mail, Capture One, and loginwindow. In one case, Proton Mail’s PID remained listed even after Proton Mail had quit.

The reliable workaround so far is to unlock 1Password. Immediately afterward, Secure Input clears, ioreg returns no result, and Fn-E, Dictation, Alfred snippets, and Keyboard Maestro all begin working again.

Restarting CharacterPalette, TextInputMenuAgent, TextInputSwitcher, SystemUIServer, Dock, and pboard did not fix it. Logging out and back in does.

Has anyone else seen Secure Input become stuck like this, particularly after sleep/wake? Any idea what might be causing it, or how to clear it properly without relying on 1Password or logging out?

Updated:
Moments ago when I returned to my computer, Apple Music had supposedly captured Secure Input! I think this is an issue with MacOS.

Hi ​@kappabear, I’m sorry to hear you’ve been running into issues with 1Password and Secure Input as well.

To confirm, does the behaviour you’re seeing match the behaviour others have mentioned in this thread - that is, it happens when your device locks/sleeps while 1Password is running, and locked but not focused on your screen, and once you wake your device, that’s when Secure Input is reported as being held by various other processes?

This secure input bug is really annoying, and I don't think even the usually awesome 1Password team has been able to fix it. Instead of closing and reopening the 1Password app, I found a much quicker way to get back to work. Just enter the following commands in the Terminal app, and you can continue working immediately:

killall "1Password Helper"

killall "1Password Helper (Renderer)"

killall "1Password-BrowserSupport"

On my MacBook, Terminal runs in the background all day.

—Carsten

This is extremely frustrating. I rely on several accessibility and efficiency tools—including Superkey and Keyboard Cowboy—to navigate my Mac. When 1Password leaves Secure Input enabled, those applications stop receiving global keyboard shortcuts.

I’ve upgraded to the latest 1Password release, but the problem persists. Focusing 1Password and then switching to another application—or quitting and reopening 1Password—releases Secure Input, but this is only a temporary workaround. Please prioritise a permanent fix. Thank you.

System information

• macOS 26.5.2 (25F84), Apple Silicon/arm64
• MacBook Air (Mac17,3), Apple M5, 24 GB RAM
• 1Password for Mac 8.12.33
• 1Password for Brave extension 8.12.32.33
• Brave 151.1.93.134
• Superkey 1.66
• Keyboard Cowboy 3.28.4
• Karabiner-Elements 16.0.0

Relevant 1Password configuration

• Touch ID and device-based unlocking enabled
• Idle auto-lock: 60 minutes
• “Lock when device locks or sleeps” currently disabled as a workaround
• SSH Agent enabled
• Developer features enabled
• CLI and SDK shared lock state enabled
• Local MCP integration enabled

Symptoms

• The failure usually appears after the Mac sleeps or is locked and subsequently wakes.
• Superkey and Keyboard Cowboy stop detecting global shortcuts.
• Secure Input remains active even though 1Password is in the background and no password field is visibly focused.
• ioreg may report loginwindow or whichever application is currently focused rather than 1Password.
• Bringing 1Password to the foreground and switching away often immediately clears the condition.
• If that fails, quitting and reopening 1Password clears it.
• Logging out also clears it, presumably because the process holding Secure Input is terminated.

This behaviour closely matches the reproduction already reported in this thread: 1Password auto-locks during a lock/sleep transition and its unlock field appears to retain Secure Input after wake.

I'm experiencing this too, and it's extremely frustrating.

I'm using 1Password 8.12.33 (Mac) and Alfred 5.7.3. When 1Password automatically locks after the configured timeout, Alfred Snippets stop working across other apps. If I focus the 1Password window and then return to the app where I was working, snippets immediately begin working again.

Could you please prioritize a fix? This issue is seriously disrupting workflow.

Having 1Password silently disable text expansion and other keyboard-monitoring utilities every time it locks is very disruptive.

I hit this issue regularly too with Hammerspoon workflows, where-in secure input blocks Hammerspoon modal key bindings from working. Confuses the heck out of me sometimes even though I’ve been encountering this for 2+ years.

It occurs whether 1Password gets locked from idle or when macOS locks from inactivity.  These are my settings:

Reproducibility is straight forward in lock/unlock flow:

• open 1Password (with the settings I shared); locked or unlocked at this point
• open Terminal
• run `ioreg -l -w 0 | grep SecureInput` (nothing returned)
• Make sure Terminal is the focused/top application
• Apple → Lock Screen
• Unlock
• run `ioreg -l -w 0 | grep SecureInput` → returns 2x `loginwindow console` (for me)
• cmd-tab to 1Password
• cmd-tab to Terminal
• re-run `ioreg -l -w 0 | grep SecureInput` → expect empty response

So you don’t even have to login to clear it. 100% reproducible on my end.

Workaround for Hammerspoon user

I wrote a quick function that I use when activating Hammerspoon modals that does the tab workflow:

• checks for secure input and whether 1Password is open or bails
• if 1Password is open and the foreground application, nothing happens
• if 1Password is open and a background application, it focuses 1Password and re-focuses the previous application (ie: cmd-tabs back and forth)
• then waits (for up to 3 seconds) for the secure input to be disabled

```

function disable1PasswordSecureInput()
    local currentApp = hs.application.frontmostApplication()
    local onepApp = hs.application.find('1password', nil, nil)

    if onepApp == nil then
        log.d('1Password is not open, nothing to disable')
        return
    elseif currentApp:pid() == onepApp:pid() then
        log.d('1Password is the foreground applicatoin, nothing to do')
        return
    end

    local mainWindow = onepApp:mainWindow()
    mainWindow:focus()

    local windows = currentApp:visibleWindows()
    for key, window in pairs(windows) do
        log.i('refocused ' .. window:title() .. ' from ' .. currentApp:title())
        window:focus(i)
        break
    end

    local start = hs.timer.secondsSinceEpoch()
    local status = nil

    -- give it 100ms to clear things, then loop every 250ms to check
    hs.timer.usleep(100000)
    while true do
        if (hs.timer.secondsSinceEpoch() - start) > 3 then
            log.i('timed out waiting secure input to be disabled')
            break
        end 

        status = hs.eventtap.isSecureInputEnabled()
        if not status then 
            log.d('secure input disabled')
            break
        end

        hs.timer.usleep(250000)
    end
end
```

Lot of ways to improve the helper function, but its been great for a few days so I thought it worth sharing. While I use key activations to trigger the fix, it could be hooked up to unlock/new session events with the `hs.caffeinate` framework instead. 

Hello everyone, 

Our development team is currently testing a fix for the issue in the latest nightly version of 1Password for Mac. If you're comfortable using an experimental release, and interested in helping us confirm that this fix resolves the issue that you've been running into, then please try the nightly by following these steps:

1. Open the 1Password 8 for Mac app and sign in.
2. In the menu bar, click 1Password, then Settings.
3. In the Settings pane, switch to the Advanced tab and change the Release Channel to NIGHTLY.
4. Swap to the About tab, and click Check for Updates.
5. After the update downloads, click Restart to apply the update.

You can read more about the nightly version here:  Use 1Password beta or nightly releases | 1Password Support 

Once you've updated and restarted 1Password. Try to reproduce the issue again. Let me know how it goes by replying to this comment and I can share this information back to our development team. 

-Dave