macOS “Phantom Focus” Bug – Window Focus Switches to Nothing, Keyboard Input Stops Working

I am reposting this because my previous posts on this issue appear to have been removed or de-indexed from my Apple Support Communities profile. I am saving both the forum link and the full text of this report going forward.


This is a long-standing macOS bug where window focus is lost entirely and switches to nothing. No visible app or window becomes active, and keyboard input stops being delivered to any application until certain system services are restarted or the user logs out.


This is not an application bug. It is an OS-level focus / responder chain failure.

Update: This issue is still present in macOS Tahoe 26.2

As of macOS Tahoe 26.2, the same behavior persists:

• Window focus switches to nothing

• Keyboard input stops being delivered to any app

• No visible window owns the responder chain

• Recovery still requires restarting UI services or logging out

This confirms the bug now spans multiple major macOS generations.

Symptoms

• Active window suddenly loses focus

• No other window becomes active

• Keyboard input no longer works in any app

• Clicking windows may visually highlight them, but typing does nothing

• Menu bar remains visible, but input focus is effectively “null”

• The system behaves as if it is focused on an invisible or non-existent window


Only recovery options:

• Restart SystemUIServer and/or Dock

• Restart WindowServer (logs out the user)

• Reboot the system


Affected Systems

I have reproduced this across multiple macOS versions and hardware systems, including:

• macOS Sonoma

• macOS Sequoia

• macOS Tahoe 26.2

• Mac Studio and MacBook Pro

• With and without external displays

• With and without third-party software running


This rules out:

• A single app

• A single OS release

• A single hardware platform

Conditions that Increase Frequency

The issue becomes more likely under:

• Long uptimes

• External display usage

• Multiple Spaces / Mission Control

• Heavy use of menu bar utilities

• Accessibility APIs enabled

• High background activity or I/O


This strongly suggests a race condition between:

• WindowServer

• Accessibility focus APIs

• Mission Control / Spaces

• Menu bar agents

• Keyboard input routing

Historical Evidence

Historically, restarting keyboardservicesd would sometimes restore functionality, demonstrating that the responder chain was breaking at the OS level. However, in recent macOS versions this service is SIP-protected and cannot be restarted:


Operation not permitted while System Integrity Protection is engaged


This shows Apple is aware this service is security-sensitive, yet users are now left without any supported way to recover input focus without logging out.

Current Mitigation Options


Soft reset:


killall SystemUIServer


If needed:

killall Dock


Guaranteed fix (forces logout):

killall WindowServer

Apple should not require users to log out or reboot to recover from a basic UI focus failure.

Why This Matters

This is not a minor usability issue. When this occurs:

• The system becomes partially unusable

• Active work is disrupted

• Unsaved work is at risk

• Accessibility is broken

• Keyboard input is effectively disabled

This is a fundamental failure of core OS input handling.

Previous Reporting

I have previously submitted this issue through Feedback Assistant with:

• Screen recordings showing focus switching to nothing

• sysdiagnose logs captured during the failure

• Detailed reproduction notes

However, there is:

• No public tracking

• No acknowledgement

• No visible resolution

• No safe user-level recovery method

Meanwhile, forum posts describing the issue appear to be buried or detached from user profiles, which prevents collaborative validation and debugging.

Technical Characterization

This behavior is consistent with a null focus state where:

• No NSWindow owns the responder chain

• Keyboard events are not routed to any application

• The system believes it is focused, but on an invalid target

What Apple Needs to Do

Apple should:

  1. Acknowledge this as an OS-level bug
  2. Provide a supported way to safely restart focus and input services
  3. Fix the underlying coordination between:
    1. WindowServer
    2. Accessibility services
    3. Mission Control / Spaces
    4. Keyboard routing
  4. Stop de-indexing or shadow-hiding community reports of system regressions

Until This Is Fixed

Users are forced to rely on:

killall SystemUIServer
killall Dock


or full session resets via:


killall WindowServer


This is not an acceptable long-term solution.

Final Note to Apple Engineers

This bug is real, reproducible, and has persisted across multiple macOS generations, including Tahoe 26.2. It disproportionately affects:

• Power users

• Multi-display setups

• Accessibility users

• Long-running work sessions

This is not an edge case. It is a core UI reliability issue that needs engineering-level attention.


Posted on Jan 27, 2026 6:43 PM

Reply
29 replies

Apr 22, 2026 2:28 AM in response to FutureX

So it's been over 2 months that I removed Logitech GHub from my Macbook Pro and I have NOT encountered this issue ever since. Still on Sequoia 15.7.3. Somebody would need to validate on more recent OS versions, but for me, it looks like it's DEFINITELY caused by Logitech GHub either directly or indirectly. Removing it (moving on on-device profiles for my mouse) has worked out.

Hope this helps.

Jan 28, 2026 9:46 AM in response to FutureX

Additional Diagnostic Evidence (captured during active failure - right now)


  1. lsappinfo front returned no frontmost application:

ASN:0x0-0x9082079:

This shows the system had no valid active process associated with keyboard focus.

ChatGPT_Debug_Focus Switching.t…


2. WindowServer repeatedly reports invalid windows:


_CGXPackagesSetWindowConstraints: Invalid window

This indicates WindowServer is operating on destroyed or invalid window objects.

ChatGPT_Debug_Focus Switching.t…


3.Keyboard focus chain resolves to a null display:


chain did update ... <keyboardFocus; display: null> containsEndOfChain: YES

This shows keyboard focus routing is considered complete even though it resolves to no real display or window target.


4.GUI clients fail to respond:


pid #### failed to act on a ping it dequeued before timing out

This suggests stalled clients are contributing to focus ownership corruption.


5.Ghost window creation/destruction:


FuseBoardServices ... updated window from "none" to "hidden"

Indicates windows entering illegal or invisible states that still participate in focus management.

Mar 12, 2026 1:36 PM in response to Luis Sequeira1

Luis Sequeira1 wrote:


RastaSoulJah wrote:

I have this same issue and I have LogiTech Ghub installed could this be the cause of the issue ?
Very likely.
Try uninstalling and see if the problem goes away, as it seems to have for others.

I completely removed LogiTech GHub from my device ( Macbook Pro Mac OS - Tahoe 26.3.1) 2 days ago and the issue has not presented itself since then. I used the Ghub only for updating my Astro A50 X and I can do that from my mobile device, so no love lost. Hopefully this helps! Thanks @Luis Sequeira1!

May 12, 2026 11:14 PM in response to FutureX

Thanks to Gemini, I have found a solution for myself because I didn't have Logitech Ghub installed.


Check for "Crashing" Loops

If a process is crashing every few seconds, it often steals focus for a millisecond as it tries to launch a window. You can check the "Diagnostic Reports" to see if something is flooding the system:

  1. Open Console.app (via Spotlight).
  2. Click on Crash Reports in the sidebar.
  3. Sort by Date Modified.
  4. If you see a process name appearing repeatedly with timestamps seconds apart, that's it.


I found the app that keeps crashing, uninstalled it and managed to fix the issue.

Jan 29, 2026 8:27 PM in response to FutureX

FutureX wrote:

Affected Systems
I have reproduced this across multiple macOS versions and hardware systems, including:
• macOS Sonoma
• macOS Sequoia
• macOS Tahoe 26.2
• Mac Studio and MacBook Pro
• With and without external displays
• With and without third-party software running

This rules out:
• A single app
• A single OS release
• A single hardware platform

What you have not ruled out is something in your configuration or something installed that is common to all your Macs running those various MacOS. In other words, what you had in Sonoma was migrated to Sequoia and subsequently to Tahoe, how do you know it is not something you have configured on your Macs? As HWTech points out, usually these sorts of things stem from user configured or installed items.


My employer has thousands of Macs. Were running Sonoma, then Sequoia, now Tahoe. I have never seen the issue you describe. It may exist among those thousands of Macs, but if it does, no one has reported it in our Slack channels utilized for reporting anomalies, so it must be unusual or rare.


You have provided an admirably detailed accounting of symptoms, but you have not provided evidence of root cause. I see nothing in your post that convincingly proves root cause is the MacOS as opposed to something installed. Even if no third party software is "running," background process can cause these freeze ups as can attached peripherals.


Posting the Etrecheck report as suggested by HWTech may enable a diagnosis via "crowd sourcing" in Apple Discussions of the root or proximate cause of the anomaly. If this were intrinsic to all those versions of the MacOS, these Discussions would be burning up with scores of reports like yours. But let's see what the Etrecheck reveals before jumping to conclusions.


Anecdotally, we have Macs in this household on Sonoma, Sequoia, and Tahoe (and older Macs on Big Sur, Monterey, even one on High Sierra dating from 2010). Never seen the anomaly that you describe. But it's real for you and I second HWTech's suggestion to post your (complete) Etrecheck report.

Apr 20, 2026 4:57 PM in response to FutureX

You realize your excellent report will not get to the necessary Apple personnel. Make a copy of your post and go to Feedback - macOS - Apple  and tell Apple the problem and include your post.


A quick way I've found to restore the Focus to an app is to click on the Finder icon in the Dock, close the resulting Finder windoe and then the app your current in. That restores the Focus for all apps.


Apr 20, 2026 10:07 AM in response to AlexSonne81

AlexSonne81 wrote:

I'm in 26.4.1 (25E253) and this is still happening. I have no Logitech stuff.

There can be multiple causes, which is why starting your own new thread is useful. Noting that others had the Logitech hardware AND software installed and when those were removed, for at least some people the problem went away. Since you don't have Logitech, something else may be playing up here. Download Etrecheck and post its report here following https://discussions.apple.com/docs/DOC-250000211 so people reading here can inspect for a potential diagnosis.


Jan 28, 2026 3:09 AM in response to FutureX

Of course the symptoms you describe are serious, but I doubt that they are prevalent - otherwise we'd have heard about this, and loudly, too...


I don't think you mentioned the most relevant item in the list - which input device(s) are you using?

Most problems of similar sort that I've heard about on these fora seem to end up being related to mouse drivers (Logitech devices, perhaps due to their abundance, seem to be the most affected).




Jan 28, 2026 3:38 AM in response to FutureX

FutureX wrote:
Previous Reporting
I have previously submitted this issue through Feedback Assistant with:
• Screen recordings showing focus switching to nothing
• sysdiagnose logs captured during the failure
• Detailed reproduction notes

Get started with Feedback Assistant on Mac


To use Feedback Assistant, you must sign in using an Apple Account that’s registered as an Apple Developer, or currently enrolled in an Apple Beta Software Program or AppleSeed for IT.


So to which category do you belong to >> Apple Developer, >> Apple Beta Software Program or >> AppleSeed for IT ?



Final Note to Apple Engineers


This bug is real, reproducible, and has persisted across multiple macOS generations, including Tahoe 26.2. It disproportionately affects:
• Power users
• Multi-display setups
• Accessibility users
• Long-running work sessions
This is not an edge case. It is a core UI reliability issue that needs engineering-level attention.

These are User to User Forums.


Most answers come from fellow users just like you and me - Not from Apple


Posting in these forums ,expecting Apple Software Engineers to offer up an acknowledgement for some software issue is Fruitless


The only Apple Personal who may read this posting would be the Apple Moderation Team

macOS “Phantom Focus” Bug – Window Focus Switches to Nothing, Keyboard Input Stops Working

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.