My Mouse Buttons Quit. Secure Input Was Why.

Fri, 09 Oct 2026 00:00:00 +0000

I pressed the button and nothing happened.

It’s the button on the thumb rest of my MX Master 3, the one I’ve set as my Wispr Flow button. Wispr Flow lets you pick a mouse button to trigger dictation, and that thumb button is the one I chose. If you haven’t used Wispr Flow, it’s voice dictation that actually keeps up with how I think, and once you get used to talking instead of typing, it becomes very hard to go back. So when that button stopped doing anything, it wasn’t a small annoyance. It was the thing I rely on most during the day, and it had quietly stopped working.

The mouse itself was fine. It moved, it clicked, it scrolled. Nothing else on the Mac seemed off either. Only that one button, the one another app was listening for, had stopped doing anything. And it wasn’t constant. It came and went, which made it even harder to pin down.

The Mouse Was Fine. The Mac Wasn’t Listening.

macOS has a feature called Secure Input. When your cursor lands in a password field, the system locks down keyboard input so that other apps can’t watch what you type. That’s a good thing. It’s supposed to switch on when you click into the field and switch off the moment you leave it.

The problem is when it doesn’t switch off. If an app turns Secure Input on and never releases it, the Mac stays in that locked-down state. Apps that listen for input across the whole system can stop hearing it. Logitech has a support article on exactly this, and it says that with Options+, keyboard shortcut based tasks stop working while Secure Input is on, while the basic mouse keeps working. In my case, the app that went deaf was Wispr Flow, waiting for a button press it never heard. That’s exactly why this one is so easy to misdiagnose. You end up blaming the mouse, re-pairing it, or reinstalling the software, and none of it helps.

Here’s How to Check

Open Terminal and run this:

ioreg -l -d 1 -w 0 | grep SecureInput

If nothing comes back, Secure Input is off and your problem is somewhere else. If you get output, look for kCGSSessionSecureInputPID. The number after it is the process ID of whatever turned Secure Input on.

When I ran it, Secure Input was on, and it handed me a process ID.

The Process That Wasn’t There

The next step is to find out what that process is. You can search for the ID in Activity Monitor, or run this in Terminal with the number swapped in:

ps -p  -o pid,comm,args

Nothing came back. The process that turned Secure Input on no longer existed. Whatever it was had already exited, and it had left my Mac stuck in Secure Input on the way out.

That’s the part I find interesting. The tool told me exactly who to blame, and the suspect had already left the building. So I had to work from what I knew.

Go With the Most Likely Suspect

Password managers use Secure Input. That’s part of how they protect what you type into them. I use 1Password, and it was open. Its process ID didn’t match the one in the output, but it was still the most likely culprit on my machine.

So I quit 1Password and ran the ioreg command again. Secure Input was off. I pressed the button on my mouse and Wispr Flow started listening.

Then I relaunched 1Password and checked again, and it was not putting me back into Secure Input, at least not yet. Since the problem was sporadic to begin with, I’m not calling it solved until it stays gone for a while. Whatever state had gotten stuck had been cleared by quitting the app, and a fresh launch behaved the way it should. I also noticed my 1Password was a couple of versions behind (8.12.36), so I updated it to 8.12.40. I’ll be watching to see if that makes a difference, though with something this intermittent, it will take some time to know.

I don’t know exactly what happened under the hood, and I’m not going to pretend I do. What I know is that something left Secure Input switched on, the process that switched it on was gone, and quitting the app that most likely had a hand in it cleared the condition.

For the record, this is a new Mac Studio M5 Max running macOS 27 with Logi Options+ handling the rest of the mouse customization. I haven’t installed the latest macOS 27 update yet. That’s on my list for tonight.

When the Thing You Rely On Stops Working

What makes this kind of problem frustrating isn’t how hard the fix is. Once you know where to look, it takes about a minute. It’s that the failure doesn’t point to itself. The mouse looks broken, or the app does. The real cause is a security feature that did its job and then forgot to stop, and the process that triggered it isn’t around anymore to take the blame.

In my experience, a lot of support tickets look like this. Somebody reports a symptom in one place while the cause sits somewhere else entirely, and the first several fixes go after the wrong thing. The useful habit is the same every time: before you replace anything, find out what the system is actually doing.