Windows: apps launched by launch_app inherit the daemon's High IL, then the driver's Medium-IL input worker cannot inject into them (UIPI)

[wrlm]

[Bug] Windows: apps launched by launch_app inherit the daemon's High IL, then the driver's Medium-IL input worker cannot inject into them (UIPI)

Summary

On Windows, when the cua-driver daemon runs elevated (High integrity level), any app launched via launch_app inherits High IL. The driver's input-injection worker, however, runs at Medium IL, so UIPI silently blocks all subsequent automation of that app. The net effect: the driver launches an app it then cannot control — launch_app followed by click/type_text/press_key against that app fails, even though the exact same app works fine when launched from Explorer.

Environment

• cua-driver 0.23.2 (Windows x64, stable channel)
• Windows 11 Pro x64 (also observed on Win10), UAC enabled, user is in Administrators group
• Daemon started elevated (autostart scheduled task / admin console) → daemon runs at High IL
• Target app: LxMainNew.exe (Sinopec IM client, CEF-based) — but this is not app-specific; any child of the elevated daemon is affected

Repro

1. Start the daemon elevated (High IL). Verify with Process Explorer / a token query: cua-driver.exe token integrity = 0x2000 (High).
2. Use launch_app to start a desktop app (e.g. LxMainNew.exe).
3. Observe the spawned process: integrity level = 0x2000 (High) — inherited from the daemon.
4. Try to automate the launched app:
   • click with delivery_mode: "background" → fails with 0x80070005 (E_ACCESSDENIED)
   • type_text / press_key with delivery_mode: "foreground" (after bring_to_front) → silently no-ops: the call returns without error, but the app receives no input (button does not respond, no text appears)
5. Kill the app. Relaunch the identical exe from Explorer (double-click, Medium IL), or via a plain scheduled task with default RunLevel.
6. Now the same click / type_text / press_key calls all work against the same app.

Root cause is plain UIPI: the input-injection worker is Medium IL and cannot send input to a High-IL process. launch_app creates High-IL children whenever the daemon is elevated, i.e. the driver arranges the exact condition that disables its own input path.

Expected behavior

At least one of:

• launch_app spawns children at Medium IL (the level the input worker can actually inject into), e.g. via ShellExecute through the shell / a duplicated token with medium integrity; or
• The input-injection worker runs at (or above) the daemon's IL, so children of the daemon are always controllable; or
• launch_app detects the mismatch and either warns or refuses, instead of returning success and leaving the agent with an uncontrollable window.

Actual behavior

launch_app succeeds, list_windows shows the new window, but every input injection into it fails (hard error in background mode, silent no-op in foreground mode). From the agent's perspective the app is a dead window with no actionable error explaining why.

Workaround (verified)

Launch the target app so that the real parent is a Medium-IL process:

• Have cua-driver simulate a double-click on the desktop shortcut (input High→Medium is allowed by UIPI; ShellExecute via Explorer spawns the child at Explorer's Medium IL), or
• Use a plain scheduled task with default RunLevel (no elevation) to start the app, or
• User double-clicks the icon manually.

After that, all background clicks and foreground input work normally.

Related

• cua-driver-rs (Windows): Calculator (and likely other restricted-UIA UWP apps) returns sparse 1-element tree from get_window_state — UIPI ceiling #1601 / cua-driver-rs (Windows): ship with uiAccess="true" manifest + signed binary to unblock UWP automation (SendInput / UIA against Calculator-class apps) #1602 — UIPI ceiling on the target side (driver too low for restricted apps); this issue is the inverse: the driver raises its children above its own input worker.
• cua-driver-rs autostart docs vs reality: RunLevel=Highest doesn't actually elevate non-RID-500 admin daemons on AtLogon trigger #1638 — autostart RunLevel elevation behavior; related to why the daemon ends up High IL.
• cua-driver-rs check_permissions still misreports IL — Rust impl disagrees with equivalent C# Win32 read (#1640 followup) #1646 — IL misreporting in check_permissions.

Happy to provide IL dumps (token integrity via GetTokenInformation) for the daemon, the launched child, and the worker process if useful.