I am sure anyone who uses TextExpander, Keyboard Maestro, and other text expansion apps is familiar with the dread warning that “secure input” is preventing the app from being able to do its macro magic. I have seen this off and on over the years and usually can clear the state. Starting a few days ago on my M1 Mac mini running Monterrey, which I updated last days ago, TextExpander started to display this warning all the time. Keyboard Maestro, when launched, does the same, so I confirmed it’s not just TE. I use TE 5, as I didn’t need the subscription features.
I have read and done everything in this document at Smile’s site, so read that first before duplicating its suggestions. This includes locking the screen, logging out and back in, and restarting.
I also dug up Terminal commands from various posts people had made online. For instance, run ioreg -l -w 0 | grep SecureInput and you can see anything with SecureInput enabled. However, the advice is then to kill jobs or quit apps that are referenced in the resulting lines. Doing that seems to produce an orphan reference in the ioreg chart: the job number (PID) still appears, but there’s no job running.
You can run this to have the PID in the ioreg output look up the specific job in the process list (ps):
I have had a couple recent reports of Secure Input issues, which is more than usual, but not enough to be significant.
Both reports were inconclusively, identifying the culprit as the “loginwindow” process.
Typically when it is the loginwindow the cause is a server of some sort asking for a password at login time. Generally restarting resolves it - frequently nothing else will. @glennf - have you restarted? Does the problem persist?
No number of restarts helps. Often, Slack is reported as the culprit! If I quit Slack then sometimes it reverts to loginwindow. It’s baffling. I imagine there is a persistent flag somewhere surviving restarts, except the ioreg command would seem to only be pulling up a live registration of SecureInput’s invocation.
That is not my understanding of how Secure Input Mode works.
There is no persistent flag, it will be some process requesting it, directly or indirectly and then failing to release it, or still waiting for whatever secure input it needed to happen.
Try a Safe Boot. Try creating a fresh clean account and restart and log in to that instead.
Check your Login Items, and any third party system services (I use Lingon X to monitor any services that are started up in the various ways).
The solution was apparently to upgrade to macOS 12.4, out this morning. I did immediately, wondering if the process by which macOS prepares a new signed sealed volume would magically fix it. It did!
Spoke too soon: after the following restart, same problems. After removing lots of cruft with Lingon, too! Now in a permanent state of Secure Input, even when the thing that macOS claims has Secure Input is no longer running—the ioreg entry never gets updated.
I’ve had an uptick in people reporting this sort of thing (still very small number, less than one a week), where Secure Input Mode comes on immediately at boot.
Just yesterday after restarting because of a couple oddities, TextExpander is back and working for the longest it has since the mystery started. I have not installed any Monterey updates in the meantime, but I did clear out a lot of cruft? Perhaps it took two reboots for the cruft to fix itself.
