fix(cua-driver-rs)(windows): skip cua-driver-uia spawn at High IL (suppresses AIS error dialog) - #1634
Conversation
…on is at High IL (#1602) Since PR #1630 the autostart task runs the main daemon at RunLevel=Highest, which puts cua-driver.exe at High IL with full UWP / AppContainer UIA access. The sibling cua-driver-uia.exe worker is therefore redundant for the common case — and worse, attempting to ShellExecute the (currently unsigned) uiAccess'd worker from a High-IL parent pops a Windows AIS error dialog ("A referral was returned from the server" = AIS refusing to elevate an unsigned uiAccess binary). The dialog blocks daemon startup and visibly confuses users. Repro: run `cua-driver autostart enable` from a standard admin user (non-RID-500), accept the UAC prompt, then `cua-driver autostart kick`. The main daemon starts at High IL, tries to spawn the uia worker via ShellExecute, AIS refuses, error dialog pops up over the desktop. ## Fix maybe_spawn_uia_worker() now gates on three conditions: 1. Main daemon is NOT at High IL (checked via PowerShell WindowsPrincipal.IsInRole(Administrator)). At High IL the worker is redundant. 2. CUA_DRIVER_RS_SPAWN_UIA_WORKER=1 env var is set. Default-off until the worker is actually EV-signed (#1602) and the spawn doesn't trip AIS. 3. The worker binary actually exists on disk next to cua-driver.exe. All three must be true for the spawn to fire. Common case (RunLevel=Highest install via the canonical install.ps1 + cua-driver autostart enable flow): condition (1) trips first — no spawn, no dialog, no UWP regression because the High-IL main daemon already does what the worker would have done. ## Future EV-cert path When we ship a signed cua-driver-uia.exe (the long-term #1602 answer), users running the daemon at Medium IL can opt into the worker by setting CUA_DRIVER_RS_SPAWN_UIA_WORKER=1. Default-off gives a no-surprises upgrade path: existing users on Medium IL stay on whatever path they're already on, and the explicit env var keeps us honest about which path is being exercised during the signed-binary rollout. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe Windows daemon's UIA worker spawning is now gated by privilege level and environment variable. A new ChangesUIA Worker Spawning Controls
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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 |
Summary
Since PR #1630 the autostart task runs the main daemon at `RunLevel=Highest` — full High IL, full UWP UIA access. The sibling `cua-driver-uia.exe` worker is redundant in that mode, and attempting to ShellExecute the unsigned uiAccess'd worker from a High-IL parent pops a Windows AIS error dialog ("A referral was returned from the server" = AIS refusing to elevate unsigned uiAccess).
This patch gates the worker spawn on three conditions:
Common case (Highest autostart task per #1630) trips condition 1 → no spawn → no dialog → no regression (High-IL daemon already does what the worker would).
Repro of the dialog
After this patch: same flow, no dialog. Daemon serves requests, UWP automation works (already verified by the cuademo dogfood for Calculator).
Future EV-cert flow
When the worker is EV-signed and properly elevates to UIAccess, set `CUA_DRIVER_RS_SPAWN_UIA_WORKER=1` to engage it. Default-off keeps the rollout honest — explicit opt-in during the signed-binary transition.
Surfaced
cuademo's fresh-install dogfood right after v0.2.11 — `autostart kick` brought up the daemon and immediately popped the AIS dialog.
🤖 Generated with Claude Code
Summary by CodeRabbit
Bug Fixes
Documentation