One morning, three things happened on my Mac at the same time:
・Cmd+Tab would not switch apps
・Switching between Japanese and English input behaved strangely
・The mouse and the other keys worked normally
A reboot might have fixed it.
But my Mac is always recording or running something long, so I don't reboot lightly.
When I tracked it down, the cause was a password field in an app hidden in the background.
The cause: macOS Secure Input
macOS has a feature called Secure Input.
While the cursor is in a password field, other apps are not allowed to read keystrokes.
It exists so nothing can snoop on your password, and that's the right call.
The catch is that it applies to the whole Mac.
While Secure Input is on, apps that work by reading keystrokes (Cmd+Tab switchers, input method helpers, key remappers) stop receiving keys.
They still see modifier keys like Cmd and Shift, but not the actual key presses.
And if the cursor stays in a password field, Secure Input stays on, even when that app's window is hidden behind others.
What happened on my Mac
The first time, it was a browser password manager extension.
The password manager's Safari extension turned Secure Input on and failed to turn it off, and Cmd+Tab died.
Quitting Safari didn't fix it. Locking and unlocking the screen didn't either.
The second time, it was a browser window I was driving with automation.
A browser running in the background got stuck on a login page with the cursor in the password field.
The window was off screen, so I couldn't see it.
Cmd+Tab and input switching stayed broken from the middle of the night until morning.
Check whether Secure Input is on
Run this in Terminal:
ioreg -l -w 0 | grep -i SecureInput
If the kCGSSessionSecureInputPID line shows a number other than 0, Secure Input is on.
If nothing comes back, or the number is 0, it's off.
The trap: the app it points to may not be the culprit
kCGSSessionSecureInputPID shows a process ID.
It's tempting to read it as "this app is the culprit". That's the trap.
The number is only the process that last turned Secure Input on.
It isn't necessarily the app holding it now, and it can even be the ID of an app that has already quit.
The second time, the ID pointed to an unrelated app.
Restarting that app did nothing.
The real culprit was the password field in that off screen browser window.
How to find the real culprit
Instead of trusting the number, check these in order:
・Is any open app sitting with its cursor in a password field? Include windows that are behind others or off screen
・Is a password manager running, including browser extensions?
・Is a browser automation tool stuck on a login page?
With macOS Accessibility, you can check which element each app currently has focused, and whether it's a password field, without moving the cursor.
That's how I found the password field in the off screen window.
How to fix it
Once you know the culprit, you don't need to reboot.
・If an app has its cursor in a password field, move the cursor out of it or close that window
・If it's a password manager extension, quit just that extension's process. You don't have to quit the browser
The first time, quitting only the Safari extension's process turned Secure Input off on the spot, and Cmd+Tab came back.
# For the Bitwarden Safari extension (it starts again on its own when needed)
pkill -f "Bitwarden.app/Contents/PlugIns/safari.appex"
If you automate a browser
When you drive a browser with automation, a job can stop on a login page and leave the cursor in a password field.
Even when you can't see the window, it affects keyboard input for the whole Mac.
On my setup, automation now always moves the cursor out of password fields when it finishes.
And when the automation hits a login page, it leaves the field alone and hands it to a person.
Summary
・If Cmd+Tab or input switching suddenly stops working, suspect Secure Input first
・Confirm it with ioreg -l -w 0 | grep -i SecureInput
・The process ID it shows may not be the culprit
・Look for password fields in hidden or off screen windows, password manager extensions, and automated browsers
・Once you find the culprit, you can fix it without a reboot
Top comments (0)