feat(cua-driver-rs/windows): cua-driver-uia worker for UWP automation (uiAccess prototype)#1604
Merged
Merged
Conversation
… (uiAccess prototype) Adds a Windows-only sibling binary, `cua-driver-uia.exe`, that runs at UIAccess integrity to bypass UIPI for UWP apps (modern Notepad, Settings, File Explorer). The main `cua-driver.exe` (CLI + MCP) stays a normal `asInvoker` PE so all existing CLI / stdio MCP entrypoints keep working via CreateProcess — UWP-blocked tool calls just transparently route through the sibling worker over its own named pipe when present. This is a prototype: production rollout still needs an EV cert to sign `cua-driver-uia.exe` (tracked in #1602). Without a trusted signature the worker fails to elevate on default-policy machines and UWP tool calls fall back to the Medium-integrity path (UIPI blocking, same as today). The main binary is unaffected — it never required uiAccess. ## What changed - `crates/cua-driver-uia/` — new crate (~200 LOC). Tiny PowerShell-style pipe server hosting the same `platform_windows::register_tools()` registry over `\\.\pipe\cua-driver-uia`. Build script embeds a manifest with `requestedExecutionLevel level="asInvoker" uiAccess="true"` via `embed-manifest` (no `mt.exe` / `rc.exe` required). - `cli.rs` — `run_call`, `should_use_daemon_proxy`, and `run_mcp_via_daemon_proxy` all prefer `\\.\pipe\cua-driver-uia` on Windows when it's listening, falling back to the main daemon pipe. The CLI / MCP transport doesn't need to know which one it's talking to: both pipes speak identical line-delimited JSON. - `serve.rs` — when `cua-driver serve` starts, it auto-spawns the sibling worker via `ShellExecute` (PowerShell wrapper, no new deps). This works because the spawn originates from a Session-2 process with an interactive desktop attached — Task Scheduler's own action paths fail with ERROR_NOT_LOGGED_ON for uiAccess binaries. - `autostart.rs` — single task only (`cua-driver-serve`); the worker is serve's child, not a separately-scheduled task. Old standalone `cua-driver-uia` task is best-effort-cleaned-up by `disable` for upgrade idempotency. - `install.ps1` — copies `cua-driver-uia.exe` from the release stage dir when present (older releases without the worker still install cleanly). - CD workflow — builds both binaries and zips both into the Windows release archive. - Docs — new "UWP automation and the uiAccess worker" section in `autostart.mdx` covering when the worker kicks in, what it unlocks (modern Notepad UIA tree, SendInput across UIPI), what it doesn't fix (Calculator-class DirectComposition surfaces — #1601), and the signing prerequisite for production. ## Empirical evidence (Windows 11 VM, self-signed cert + EnableSecureUIAPaths=0) | Scenario | element_count | Result | |---|---|---| | Modern Notepad UIA tree, in-process Medium integrity | 0 | UIPI blocking | | Modern Notepad UIA tree, via uia worker (TokenUIAccess=1) | 30 | Full tree | | `type_text` via UIA `ValuePattern.SetValue` across UIPI | — | `0x00000000` (success) | | MCP stdio (`cua-driver mcp`) routed through uia pipe | 30 | Routing confirmed end-to-end | Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (11)
📝 WalkthroughWalkthroughThis PR introduces a Windows UIAccess-elevated worker binary ( ChangesUIAccess Worker Implementation and Integration
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related issues
Possibly related PRs
Poem
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint skipped: no ESLint configuration detected in root package.json. To enable, add Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a Windows-only sibling binary,
cua-driver-uia.exe, that runs at UIAccess integrity to bypass UIPI for UWP apps. The maincua-driver.exe(CLI + MCP) stays a normalasInvokerPE so all existing CreateProcess-based entrypoints keep working — UWP-blocked tool calls transparently route through the sibling worker over its own named pipe when present.Status: prototype. Production needs an EV cert to sign
cua-driver-uia.exe(#1602). Without trust, the worker fails to elevate on default-policy machines and UWP automation falls back to the existing Medium-integrity (UIPI-blocked) behavior. The main binary is fully unaffected — it never required uiAccess.Architecture
cua-driver.exe serve\\.\pipe\cua-drivercua-driver-uia.exe(auto-spawned by serve)\\.\pipe\cua-driver-uiaCLI (
cua-driver call X) and MCP stdio (cua-driver mcp) both prefer the uia pipe when listening, with byte-identical JSON protocol so the client doesn't need to know which one it's talking to.Empirical evidence (Windows 11 VM, self-signed cert +
EnableSecureUIAPaths=0)element_count = 30for modern Notepad's UIA tree via uia worker (vs0in-process Medium integrity → UIPI blocking)type_textvia UIAValuePattern.SetValueacross UIPI returns0x00000000(success)cua-driver mcpover JSON-RPC → daemon proxy → uia pipe → 30-element responsecua-driver autostart kickfirescua-driver-serve→ serve ShellExecutes sibling → worker process at TokenUIAccess=1 in Session 2Calculator stays unreachable — architectural limit (#1601).
Files
New:
crates/cua-driver-uia/— 4 files, ~200 LOC. Hosts the platform-windows tool registry over a named pipe. Embeds uiAccess manifest viaembed-manifest(no mt.exe / rc.exe needed).Edited:
crates/cua-driver/src/cli.rs— pipe-preference forrun_call,should_use_daemon_proxy,run_mcp_via_daemon_proxycrates/cua-driver/src/serve.rs—maybe_spawn_uia_worker()ShellExecutes the sibling at startupcrates/cua-driver/src/autostart.rs—disablecleans up legacy second-task entries for upgrade idempotencylibs/cua-driver/scripts/install.ps1— copies uia binary when present in release stage.github/workflows/cd-rust-cua-driver.yml— builds both binaries, zips bothdocs/.../autostart.mdx— new "UWP automation and the uiAccess worker" sectionWhat this does NOT include (deferred to #1602)
\Program Files\install path option (the existing%LOCALAPPDATA%flow works once policy is relaxed; production policy decisions deferred)Test plan
cargo build -p cua-driver -p cua-driver-uia --releaseclean on Windows VMtype_textUIA SetValue on modern Notepad returns successcua-driver autostart kickauto-spawns the worker🤖 Generated with Claude Code
Summary by CodeRabbit
Release Notes
New Features
Documentation