System input becomes unresponsive when Accessibility permission is revoked while a CGEventTap is active

We are seeing a reproducible system-wide input hang when Accessibility permission is revoked from an application that has an active Quartz event tap.

The behavior reproduces on macOS Sequoia, Tahoe, and Golden Gate.

I have created the standalone diagnostic app(EventTapPassThroughTest) isolates an active Quartz event tap implementation. It creates a session-level event tap for keyboard and mouse events and returns every event unchanged. It does not register for Accessibility-change notifications, suppress events, recreate the tap, or re-enable a tap disabled by macOS. It contains only the following behavior:

• Requests Accessibility access using AXIsProcessTrustedWithOptions.
• Creates a session-level, head-insert CGEventTap with .defaultTap.
• Observes common keyboard and mouse event types.
• Returns every received CGEvent unchanged with Unmanaged.passUnretained(event).
• Adds the tap to the main run loop and enables it.

It does not suppress or modify events. It does not register for Accessibility-change notifications, recreate the tap, or re-enable a tap disabled by macOS.

In both the disable and delete cases, local keyboard and mouse input become unresponsive. A forced restart is required when no remote session is available.

The result reproduces even though the event-tap callback always returns the event unchanged. We did not observe a tapDisabledByTimeout or tapDisabledByUserInput callback before input became unresponsive.

System logs show TCC modifying or deleting the Accessibility record. WindowServer then checks the running application's kTCCServicePostEvent/kTCCServiceListenEvent access and receives a denied or unknown result. Input subsequently stops being delivered normally.

Expected result

Revoking the permission should invalidate or disable the application's event tap without affecting system-wide input. If the application is expected to perform cleanup, it should receive a documented notification or tap-disabled callback early enough to disable and invalidate the tap safely.

Questions

1. Is revoking Accessibility permission while an active .defaultTap event tap exists expected to be supported?
2. Is there a documented notification that an application can observe before or when its Accessibility/PostEvent access is revoked?
3. Is there a supported way to ensure an existing event tap is safely disabled when the user turns off or deletes the application's permission?
4. Should WindowServer automatically invalidate the tap in this situation?