Accessibility API desktop automation, without the mouse.

Two things. First, it exposes a tree of UIElement nodes with role, name, AutomationId, BoundingRectangle, and other semantic properties. Second, it exposes Control Patterns (Invoke, Toggle, ExpandCollapse, Value, Selection, Scroll, RangeValue, Window, Transform, Text) that represent what you can actually do to each element. Calling a pattern is a write operation. It fires inside the target process, talks to the app's UI thread through the accessibility bridge, and returns without ever generating a WM_MOUSEMOVE or a SendInput call. Tree enumeration is the read path. Patterns are the write path.

invoke() calls `get_pattern::<patterns::UIInvokePattern>()` on the element and then `invoke_pat.invoke()`. No cursor motion, no focus check, no visibility check, no monitor bounds math. The pattern runs inside the UIA surface in the target process. click() resolves the element's bounding rectangle, computes a click point in absolute screen coordinates, converts to normalized (0 to 65535) coordinates, and calls SendInput with MOUSEEVENTF_ABSOLUTE, MOUSEEVENTF_MOVE, MOUSEEVENTF_LEFTDOWN, and MOUSEEVENTF_LEFTUP. That requires the element to be visible on a monitor and the window to accept foreground input. Both methods exist because not every control exposes InvokePattern; for the ones that do, invoke() is faster, quieter, and does not fight the user's cursor.

crates/terminator/src/platforms/windows/element.rs lines 838 to 859. Nine lines of Rust: grab the UIInvokePattern from the element, branch on two distinct error modes ('not support' and 'UIA_E_ELEMENTNOTAVAILABLE' become an UnsupportedOperation error pointing the caller at click_element, everything else becomes a PlatformError), then call invoke_pat.invoke(). The mouse path lives in crates/terminator/src/platforms/windows/input.rs starting at line 38 in the send_mouse_click function. That function is the entire truth of what a click means on Windows.

The action dispatcher at element.rs lines 1490 to 1560 handles 'invoke' via UIInvokePattern, 'toggle' via UITogglePattern (for checkboxes and switches), 'expand_collapse' via UIExpandCollapsePattern (for tree items and dropdowns), and the standard 'click', 'double_click', 'right_click' which fall back to SendInput. setSelected for radio buttons and list items uses SelectionItemPattern. typeText uses ValuePattern when the element is a real edit control, otherwise falls back to keyboard simulation via SendInput. Pattern-first, input-second.

Because a radio button in UIA is backed by SelectionItemPattern, not InvokePattern. Sending a mouse LEFTDOWN/LEFTUP over its bounding rectangle is ambiguous: Windows might route the click to the label, to the control's hit-test region, or to a parent group box that swallows the event. The deterministic path is to call setSelected(true) which resolves SelectionItemPattern.Select() inside the target process. The ambiguity never comes up. Same story for checkboxes and TogglePattern. This is documented directly in the llms.txt pitfalls list: 'Radio button clicks do not register: use setSelected(true) instead of click()'.

Yes. Pattern invocation does not touch the cursor. Terminator markets this as 'does not take over your cursor or keyboard', and that statement is literally true for every action that resolves to a UIA pattern: invoke(), toggle(), expand/collapse, setSelected, and typeText against a ValuePattern edit control. It is only true for click() when the target window can be activated in the background without SetForegroundWindow; for foreground-dependent apps, Terminator still restores cursor position if you pass restore_cursor=true to send_mouse_click (input.rs line 45 through 50).

You get a typed error with a specific fallback suggestion. element.rs line 848 detects the substring 'not support' or 'UIA_E_ELEMENTNOTAVAILABLE' in the underlying uiautomation crate error and rewrites it into AutomationError::UnsupportedOperation with the message 'Element does not support InvokePattern. This typically happens with custom controls, groups, or non-standard buttons. Try using click_element instead.' The ExpandCollapse and Toggle paths do the same routing. That means your agent can catch the error type and fall back to click() without parsing a stack trace.

Terminator ships Windows UIA today. The core trait AccessibilityEngine in platforms/mod.rs is designed to accept future adapters, but the mod.rs file contains `#[cfg(not(target_os = "windows"))] compile_error!("Terminator only supports Windows. Linux and macOS are not supported.");`. That is the current truth. macOS has AXUIElement with its own AXPress and AXActions surface that maps to the same idea (fire an action, skip the mouse); Linux has AT-SPI2 with Action interfaces. The pattern-first approach is portable in concept, and adapters for the other platforms are a roadmap item.

Three ways. First, background execution: the agent can act on elements in a window that is not focused, without stealing the cursor from the human. Second, determinism: pattern invocation has a binary outcome (pattern fired or element does not support it) where SendInput has a continuous outcome (depends on where the cursor landed, which window has focus, whether an OS notification popped up mid-click). Third, speed: no animation, no debouncing, no 'wait for the cursor to arrive' delay. In practice that means an agent can execute hundreds of UI actions per second instead of one every few hundred ms, which is how Terminator claims >95% success rate at CPU speed rather than LLM-inference speed.

`npm install @mediar-ai/terminator`, then `const desktop = new Desktop(); await desktop.locator('process:notepad >> role:Edit').first(3000).then(el => el.typeText('hi'));`. Or hook it straight into Claude Code as an MCP server with `claude mcp add terminator "npx -y terminator-mcp-agent@latest"`. Both paths land on the same Rust core and the same element.rs:838 invoke() implementation.