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.