After a MacOS update last week, Secure Input has started blocking advanced keyboard shortcuts in Alfred, BetterTouchTool, and even my Logitech mouse options.

I have repeatedly tried to quit the programs reportedly blocking it, and this never works. About 60% of the time it's just login_window that is keeping Secure Input on.

Until last week, I'd never had this problem, however it now happens multiple times per day. The only fix I've found so far is to logout/login or restart the machine.

Is there ANY fix for this?

7 Answers 7


The quickest fix seems to be to but your mac to sleep, and then waking it again. This forces you to log in. After logging in, my experience is that secure input is usually disabled.

Edit: An even faster way I have found is to lock your screen (using ctrl + cmd + q), and then immediately unlocking it again using TouchID or password.

  • 3
    It is a super hack. Commented Jan 12, 2022 at 15:50
  • 1
    Thank you so much for that tip! I'm here for the mouse issue (mostly), and I was sleeping it before and re-logging in. Turns out, ctrl+cmd+q and login again fixed it like a charm.
    – Andrew
    Commented Jul 26, 2022 at 22:53
  • Yeah, it's crazy! I have to unlock the system twice almost every time, because after the first time, the Secure Input is stuck (it reports any application that has the focus currently). So I lock it again, unlock and finally it's gone. Extremely annoying. Commented Feb 21 at 14:03

For me the problem was Google Chrome browser, and specifically that I had a tab with a login input page that I left open without really doing anything. I tried closing Chrome entirely, and it worked, then I reopened it and secure input was enabled again, then I specifically closed the tab with the login input page, and secure input was finally disabled. I was able to notice because I use an application that informs me of this (namely Textexpander stops working and shows in status bar icon that it is disabled and my Logitech mouse and keyboard settings don't work, and other weird things happen, also running ioreg -l -w 0 | grep SecureInput gives out some output if it's enabled, and nothing if it's disabled).

Textexpander upon login, complained that the culprit was the loginwindow process. I once tried [force] sudo killing the process and my computer just sort of paniced and logged out or something. But in fact it was Google Chrome, and Textexpander was just fooled for some reason.

Really helpful posts:

  • killing loginwindow will always log out of your session. If you try to kill it with activity monitor, it will warn you that it will log you out.
    – forivall
    Commented Oct 16, 2023 at 19:34

Here's the jsavin's full answer from the forum thread above (the fragment above is not enough to find the offending login process):

After running into this issue many times and not finding good solutions short of logging out and back in again, I finally found a [terminal command](https://rakhesh.com/mac/macos-find-app-using-secure-input/) that can help figure out what process is using Secure Input:

ioreg -l -w 0 | grep SecureInput

The output of that command will have a bunch of stuff in it, but the important bit is kCGSSessionSecureInputPID=NNN where NNN is the ID of the process(es) that are using Secure Input.

You can then use:

ps auxww | grep NNN

... replacing NNN with the number after kCGSSessionSecureInputPID= from the first command. This will list the process with PID=NNN.

The first terminal command is of little value without the second one, as the output does not give an application name.

% ioreg -l -w 0 | grep SecureInput
  |   "IOConsoleUsers" = ({"kCGSSessionOnConsoleKey"=Yes,"kSCSecuritySessionID"=100005,"kCGSSessionSecureInputPID"=173,"kCGSSessionGroupIDKey"=20,"kCGSessionLoginDoneKey"=Yes,"kCGSSessionSystemSafeBoot"=No,"kCGSSessionUserNameKey"="alec","kCGSSessionIDKey"=257,"kCGSessionLongUserNameKey"="Alec Kinnear","kCGSSessionAuditIDKey"=100005,"kCGSSessionLoginwindowSafeLogin"=No,"kCGSSessionUserIDKey"=501})
    | |   "IOConsoleUsers" = ({"kCGSSessionOnConsoleKey"=Yes,"kSCSecuritySessionID"=100005,"kCGSSessionSecureInputPID"=173,"kCGSSessionGroupIDKey"=20,"kCGSessionLoginDoneKey"=Yes,"kCGSSessionSystemSafeBoot"=No,"kCGSSessionUserNameKey"="alec","kCGSSessionIDKey"=257,"kCGSessionLongUserNameKey"="Alec Kinnear","kCGSSessionAuditIDKey"=100005,"kCGSSessionLoginwindowSafeLogin"=No,"kCGSSessionUserIDKey"=501})

On the other hand, the two combined are perfect. Here's what the second command yielded when applied to PID 173

ps auxww | grep 173
alec               173   0.1  0.2 410128480  51856   ??  Ss   Sat03pm   6:37.30 /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow console
alec             33173   0.0  0.0 408234032   6224   ??  S     1:16pm   0:00.08 /usr/libexec/biomesyncd
alec             14359   0.0  0.3 450525248 111472   ??  S    Thu02am   0:39.48 /Applications/Brave Browser.app/Contents/Frameworks/Brave Browser Framework.framework/Versions/ Browser Helper (Renderer).app/Contents/MacOS/Brave Browser Helper (Renderer) --type=renderer --disable-client-side-phishing-detection --display-capture-permissions-policy-allowed --origin-trial-public-key=bYUKPJoPnCxeNvu72j4EmPuK7tr1PAC7SHh8ld9Mw3E=,fMS4mpO6buLQ/QMd+zJmxzty/VQ6B1EUZqoCU04zoRU= --brave_session_token=13423536528524367162 --lang=en-GB --num-raster-threads=4 --enable-zero-copy --enable-gpu-memory-buffer-compositor-resources --enable-main-frame-before-activation --renderer-client-id=3036 --launch-time-ticks=236601421739 --shared-files --field-trial-handle=1718379636,r,3517981772750386423,12223908964854909845,131072 --seatbelt-client=112

In my case, it was the Bitwarden login window in Brave (just happened to be Bitwarden, could be any other secure login window in the browser). I didn't even need to quit Brave to be find the secure login page. I just closed the Bitwarden window I had open.¹

Putting my M1 Mac to sleep and waking it back up did not help (it has helped in the past but more often than not does not solve the secure input issue).


1. I have Bitwarden desktop app (typical Electron web-app rubbish but it works and Bitwarden is essential for our work) open all the time and it does not create secure input enabled issues. Unfortunately the desktop app does not allow user management.

  • 1
    Thanks for this! In my case the culprit was "loginwindow", and just closing my laptop / locking the screen, then re-opening and re-entering my password (without having to completely log out / close all windows) was enough to fix the issue.
    – Luke Davis
    Commented Jun 2, 2023 at 16:38

This is very likely caused by some applications, especially some apps requiring high security such as 1password or Bitwarden. I suggest you should quit each background app to test if this problem disappeared.

For my Mac, I found it was caused by the Bitwarden desktop. And this issue had been fixed after a feedback.


It was 1Password for me. I quit 1Password completely, and then reopened it - seems ok now.


I use the contexts app and this issue has caused me a lot of headaches. Wanted to share my experience.

As mentioned in the original post, sometimes "login window" is the culprit, and running @Foliovision's code will highlight the loginwindow process. @Hans Kristian mentioned that in this situation, locking/unlocking the screen or turning sleep mode on/off can solve the problem, however I've found this only works occasionally. Often it seems another app is responsible and the attribution to loginwindow is erroneous. In this case, the solution is to either 1) completely restart or log out, or 2) figure out which app is responsible and close it (or force quit the app in Activity Monitor).

I've found a reliable method is to just go through the apps that you've recently used to enter passwords and quit them one by one. As @atwixtor mentioned I've found that "1Password" can sometimes trigger this bug. Quitting 1Password fixed the issue even though loginwindow was supposedly the culprit. I've also found the "Global Protect" VPN app I use to connect to my university's network has triggered this bug. Force quitting in Activity Monitor fixed the issue. So far have not seen it triggered by web browsers.

Hope this helps someone.


I use both 1Password and Bitwarden on my macOS machine (Ventura).

It turns out the Safari extension for 1Password caused this issue. Quitting Safari and 1Password works for me.

1Password also sometimes disable my Ctrl-c command, cannot copy and wtf.

1Password for Mac 8.10.23 (81023003)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .