Cua Previews Background Agent Input Isolation on Wayland

A computer-use agent that clicks and drags inside an app usually has to fight for the same pointer the person at the keyboard is using, which is why running an agent 'in the background' while someone keeps working is a genuinely hard problem. In a thread about a technical preview shown at an Omarchy meetup, Cua laid out two ways it tried to solve that on Hyprland, the Wayland compositor Omarchy uses.

The first path delivers synthetic input directly to the target window's own wl_pointer resource, the low-level object Wayland uses to track where a pointer is over a given window. The second gives the agent's automation a separate wl_seat, effectively a second virtual input device, so its clicks never touch the user's own pointer-focus state. Cua reports that both approaches kept a real foreground drag intact while the background input was being delivered, demoed live running from Cua Fleet.

This is explicitly a technical preview, not a shipped feature. Cua's stated next steps are finishing keyboard support, resolving Chromium-specific Wayland behavior, and completing device creation through the libei/portal path, followed by an RFC that would define the permissions and threat model before proposing the change to compositor projects.