[BUG] Claude Desktop registers as UIAutomation accessibility client on startup, causing 30-60s whole-system keyboard/input freeze on Windows

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When Claude Desktop is open, it registers as a Windows UIAutomation (UIA) accessibility client on startup. This forces every browser on the system (Chrome, Firefox, Edge) into full accessibility mode — meaning the browser must rebuild and maintain a complete accessibility tree for every DOM change on every page.

On sites with heavy real-time DOM updates (poe.trade, live search, autocomplete dropdowns), typing a single character triggers hundreds of simultaneous DOM mutations. The browser's UI thread is completely consumed updating the accessibility tree and cannot process keyboard or mouse input for 30–60 seconds. The entire PC appears frozen — mouse jitters, keyboard is unresponsive, all browser tabs and apps affected.

Root cause confirmed via WPR ETL trace + xperf UIDelay analysis:

Claude Desktop loads UIAutomationCore.DLL and OLEACC.dll in its main process on every startup. This signals all running browsers via WM_GETOBJECT, activating their full accessibility trees system-wide.

Confirmed by:

1. Chrome and Firefox both loading UIAutomationCore.DLL only after Claude Desktop starts
2. xperf uidelay report showing chrome.exe thread input queue (SinceOldestInput) growing from 234ms → 43,000ms during typing — a 43-second input freeze
3. Issue disappears completely when Chrome is launched with --disable-renderer-accessibility
4. Issue disappears completely when Claude Desktop is not running
5. Issue returns immediately after Chrome restart with Claude Desktop still open

This is NOT caused by:

• Cowork VM (freeze occurs with CoworkVMService stopped and VM failed to start)
• Claude in Chrome extension (disabled, still freezes)
• MCPs (removed all mcpServers, still freezes)
• Hardware acceleration setting (tested both on and off)
• Number of monitors (tested with single monitor)
• Specific browser (Chrome, Firefox, Edge all affected)

What Should Happen?

Claude Desktop should not register as a system-wide UIAutomation accessibility client on startup. UIAutomation should only be activated when a feature that actually requires reading browser content (e.g. Claude in Chrome) is actively in use — not unconditionally on every launch.

Electron provides app.setAccessibilitySupportEnabled(false) specifically for this purpose. Calling this in Claude Desktop's main process would prevent browsers from being forced into accessibility mode.

Error Messages/Logs

xperf UIDelay analysis (freeze window):

UIDelay, Input Delay, chrome.exe, PID 30524, Thread 33384
  StartTime: 16,425,969,700 ns
  SinceOldestInput grows: 234ms → 1,344ms → 3,047ms → 9,000ms → 22,031ms → 43,000ms
  MessageId: 256/257 (WM_KEYDOWN/WM_KEYUP stuck in queue for 43 seconds)

Processes with UIAutomationCore.DLL loaded (only after Claude Desktop starts):
  chrome.exe  — UIAutomationCore.DLL, OLEACC.dll
  firefox.exe — UIAutomationCore.DLL
  claude.exe (main process) — UIAutomationCore.DLL, OLEACC.dll  ← trigger

System CPU during freeze: ~88% idle — thread blocking issue, not CPU overload.

WPR ETL trace available: freeze_capture3.etl (2.76 GB, GeneralProfile + DiskIO)

Steps to Reproduce

1. Open Chrome (Claude Desktop NOT running)
2. Navigate to poe.trade
3. Click the search/filter input — results load, no freeze (baseline)
4. Type any character — no freeze confirmed
5. Launch Claude Desktop — leave running in background, do not interact with it
6. Return to Chrome, go to poe.trade, click the search input
7. Type any character
8. OBSERVE: whole PC freezes 30–60 seconds — mouse jitters, keyboard unresponsive, all apps affected
9. Wait for freeze to resolve, close Chrome completely, reopen Chrome
10. Repeat step 7 — freeze returns immediately (Claude Desktop still running)
11. Fully quit Claude Desktop, restart Chrome, repeat step 7
12. OBSERVE: no freeze

Shortcut to confirm root cause:

• Launch Chrome with --disable-renderer-accessibility while Claude Desktop is open
• Type on poe.trade → no freeze
• This confirms browsers are being forced into accessibility mode by Claude Desktop's UIA registration

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude 1.569.0 (49894a) 2026-04-02T20:01:42.000Z

Platform

Other

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

System specs:

• CPU: AMD Ryzen 9 9950X3D (32 logical cores, dual-CCD)
• RAM: 96 GB
• GPU: NVIDIA RTX 4080 Super
• Browsers affected: Chrome, Firefox, Edge (all versions, incognito included)

Related issues:

• #26302 — Claude Desktop severe UI lag and mouse stutter on Windows
• #29045 — Claude Desktop / vmcompute performance bug

Electron fix reference:
https://www.electronjs.org/docs/latest/tutorial/accessibility
app.setAccessibilitySupportEnabled(false) — prevents Claude Desktop from activating accessibility mode in other applications.

Workaround (user-side): add --disable-renderer-accessibility to Chrome, Firefox, Edge, and all Electron app shortcuts. This prevents browsers from responding to Claude Desktop's UIA client registration but is fragile and requires per-app configuration.