Crazy bug that locks CMD+Tab and mouse clicks

Recently I have stumbled upon a bug that is hard as h*ll to track down:
Intermittently, CMD+Tab doesn’t work, nor can I use the mouse to click on things. I am able to switch applications other ways (via Spotlight or KM shortcuts), and everything else seems to work.
After a period of time, maybe 20 to 40 seconds, it all works again, and the CMD+Tabs I have done now takes actions.
If I during this period looks what takes CPU I can’t see nothing strange, and I really can’t see what’s causing this.

This is of course extremely annoying! How can I troubleshoot this without reinstalling everything?

It started a month or so ago.

Ideas are welcome. :thinking:

Do you perhaps sometimes minimize app windows with the yellow stoplight button (bad) rather than using the hide window CMD+H command (good)?

Are you running Better touch tool? It intermittently causes me similar issues.

Not often, but it happens.

Not BetterTouchTool, I use BetterSnapTool though.

The problematic behaviour you describe is similar to what I am experiencing since upgrading to Ventura:

I seem to be wrong about Amphetamine though, but I also run BetterTouchTool.

Are you on Ventura as well?

(For me it’s even harder to debug; I can’t open new Apps, so I can’t go to Activity Monitor…)

Launch it at startup and keep it running, until you resolve the problem?

I don’t have Amphetamine, but I am on Ventura as well.

For me, I think this started after the last Ventura update a couple of weeks ago.

Since I started this thread I haven’t noticed the problem. :stuck_out_tongue_closed_eyes:

I just got it again!

After starting to quitting all open apps and processes it finally started to work again after quitting OmniFocus.
However, that may also be because the time went out (as mentioned, the problem only lasts about 40 secs).

…to be continued

I also had another occurrence today.

And I had started Activity Monitor at the start of the day, as suggested.

However, it was minimized at the moment the issue popped up and I could not open/see its main Window until my Mac started working normally again…

So also to be continued?

To echo @karlnyhus, consider hiding rather than minimizing

1 Like

I indeed tend to minimize windows instead of hiding them.

Maybe this is a habit from my Windows days, but I never heard it’s bad.

Can you please explain why minimizing is bad and hiding is good?

I have the same problem since the first Ventura beta, I hoped it would be fixed by now.

I am at least able to switch apps using rcmd even when Command Tab fails, but I can’t launch any app.

This is especially noticeable for me when I am constantly building and launching Lunar in Xcode, and suddenly it stalls at Attaching to Lunar and never finishes until I click randomly in the Xcode UI 5-10 times.

I never used Amphetamine, although I do use App Tamer which also hooks some of the same APIs. But I tested a day with App Tamer quit and it didn’t help, so I suspect this is a macOS problem.

There’s no noticeable CPU usage in htop, it’s not an overload problem. It looks more like something is stalled in the input event queue of the system. No idea how I could debug this.

Mac has an issue for me when I press the red “close” button, but it stays in my CMD+TAB screen but no window is available.

Unlike windows Mac doesn’t close the app when you close all of its windows.

I find this infuriating because until recently my most common laptop was Windows (work laptop).

This might be what is happening to you?

That’s not an issue, it’s the distinction between windows and apps that macOS has but Windows users are not used to. You can go to the Windows behaviour with the Swift Quit app.

The :red_circle: button on a window is for closing that window. It is equivalent to pressing ⌘ Command + W on the keyboard. An app is not its windows though, it can have other UI elements that are not windows.

And in specific cases you would want the app to remain open after closing the last window, to avoid wasting time/CPU on the app launch routine if you use that app often. That’s usually useful for document based apps like Word, Excel, Pages, Photoshop, Affinity etc.

Quitting the app is separate from closing the window in macOS and is usually done with ⌘ Command + Q.

Some apps do quit after the last window is closed, but that’s left as a choice for the app developer to do.

Anyway, it’s not what’s happening here. This is a user interface stalling problem, where the Launch Services daemon doesn’t react anymore and input events are not getting to the foreground app.


Semantics, but it is an issue for me. Thanks for the app tip.

As an app dev, I usually think of an issue as a “system is not working as designed” situation.

I should also think of issues as “it does not meet user expectations” if I want to be helpful, and not just snarky. Thanks for reminding me :sweat_smile:


Others have chimed in with additional useful information. But to answer your question, minimizing is not really bad. :sunglasses: Closing, opening, minimizing, and hiding windows (lowercase “W”) is just different between Windows (cap “W”) and macOS. I had to break established keyboard habit and teach myself to use CMD+H on my Macs. My memory from a long time ago is that minimized apps on Mac did not show up in the CMD+TAB switcher whereas they did on Windows in its ALT+TAB switcher.(For decades, I used Windows PCs at work and Macs at home.)

Apps with minimized windows do show up with Cmd-Tab.

However, minimized windows themselves will not appear when you Cmd-Tab to their app.

Also, I’m pretty sure (but not positive, and on mobile) that minimized windows won’t appear when you Cmd-backtick to cycle through windows (when you’re in their app).

In other words, for app- and window-switching by keyboard, a minimized window might as well not be there, which can be mysterious and frustrating.

Hiding, on the other hand, hides the app and all its windows, but they reappear and behave as expected if you return to the app, including by Cmd-Tab.

1 Like

First occurrence where I could check Activity Monitor:

kernel_task was using the most % CPU: 94,5.

(which makes it not easier to find the culprit; unless it’s really macOS itself…)