Secure Input mystery with TextExpander etc

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):

ioreg -l -w 0 | grep SecureInput | awk ‘BEGIN {FS="[^a-zA-Z0-9]+"} {print $8}’ | uniq | xargs -n 1 ps auxwww

I even wound up with this ridiculous thing happening:

So: any other ideas? It’s maddening. It’s happening to @rmogull, too.

@peternlewis Any ideas from the Keyboard Maestro perspective?

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).

2 Likes

Nor is it mine! (Admittedly, vastly sketchier than yours.) But I can’t explain why a restart isn’t working.

Will try your suggestions! Baffled absolutely why it suddenly started to happen.

1 Like

Lingon was a great suggestion. I had so much cruft. Will see if that helps.

2 Likes

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!

3 Likes

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.

Did you try Safe Boot?

Have not had time yet. My other Mac, an M1 MBA, continues to work perfectly with TextExpander with the same Monterey release versions.