Most desktop automation breaks in one specific way: it moves your cursor and steals your keyboard focus. That is fine for a script that runs while you are away and useless for anything that should work alongside you.
I spent an evening testing cua-driver, an open source background computer-use driver, on Windows 10 from inside WSL2. I installed it, wired it into an agent, pointed it at a live WeChat window, and mapped exactly where it stops working. Everything below is measured, including the parts that failed.
The setup that surprised me
My agent runs inside WSL2. The driver binary is a Windows executable. Those are two different operating systems sharing a filesystem, and it worked with no bridging layer on my side.
The Windows binary opens a named pipe at \\.\pipe\cua-driver. A Windows process launched from my Linux shell reaches that pipe because the process itself is a Windows process. The health check confirmed it by reporting session 1 has an attached interactive desktop, which is the line that decides whether a remote-shell host can drive the desktop at all.
The practical upshot: a Windows-native agent and a WSL agent can both use the same install.
What it does in the background
Reading a live WeChat window returned 138 elements: 74 buttons, 60 list items, 2 edit fields, 2 lists. The message previews came back as complete sentences. When I screenshotted the same window and ran a vision model over the image, I got truncated fragments instead. A UIA tree carries text as text, and pixels carry it as pixels.
Element addressing is the other real improvement. My old scripts clicked hardcoded coordinates, so a moved window meant clicking the wrong thing. This addresses an element by a stable token like s00000005:122.
I watched the focus stay put. Launching Notepad returned "active": false, and my foreground process stayed on msedge.exe. A background click against the WeChat input box moved focus inside WeChat while the OS-level foreground still did not change.
Where it stops
Typing in the background does not work. cmd returned background_unavailable with the reason background input is dropped by this surface, naming the class ConsoleWindowClass. Windows 11 Notepad returned delivery_failed. WeChat returned delivery_failed too, even after a successful background click put the caret in the input box.
I verified the failure rather than assuming it. A zoomed capture of the input box measured 26 dark pixels out of 61,000, which is 0.04 percent, so the box was empty.
The escape hatch is a foreground escalation that briefly swaps the foreground window and restores it. That will drop your keystrokes if you happen to be typing.
The speed finding that had nothing to do with this tool
I measured my own automation calls while testing:
powershell.exe -Command "..." 44 to 47 seconds
powershell.exe -NoProfile -File x.ps1 0.99 seconds
Same machine, same moment. The cost was PowerShell loading its profile on every invocation, and a full desktop action is a dozen calls. I had been blaming the cross-OS boundary for months. It was a startup flag.
Two related traps if you automate from WSL: write your .ps1 files with CRLF rather than LF, because PowerShell 5.1 fails to parse embedded C# here-strings with LF endings and reports a confusing error about using directives. And do not pass multi-line PowerShell through powershell.exe -Command from bash, because $_ and your quotes get eaten by the shell layer.
The verdict
Reading, locating, launching without fronting, and clicking all work, on a real Chinese-language app rather than a demo. Typing in the background does not, and for an auto-reply bot that is the half that matters.
If your task watches a window and clicks things, this is the best tool I have used for it. If it holds a conversation, plan for a second machine so the agent can front a window without competing with you. I planned for the second machine.
Full review with every number: https://saas.pet/reviews/cua-driver/
Originally published on https://saas.pet
Top comments (0)