trycua/cua

Summary When the installer finishes and the install dir (~/.local/bin by default) is not on PATH, the post-install output never prints the copy-pasteable command to add it. The user is left with a working binary they can't invoke, and no instruction to recover. I hit this on a fresh macOS install: cua-driver 0.19.2 was installed correctly, the symlink was in place, but which cua-driver returned nothing and nothing in the install output told me how to fix it. Repro / evidence $ which cua-driver cua-driver not found $ ls -la ~/.local/bin/ lrwxr-xr-x 1 administrator staff 53 cua-driver -> /Applications/CuaDriver.app/Contents/MacOS/cua-driver $ /Applications/CuaDriver.app/Contents/MacOS/cua-driver --version cua-driver 0.19.2 # binary is fine $ case ":$PATH:" in *":$HOME/.local/bin:"*) echo YES;; *) echo NO;; esac NO ~/.zshrc existed but contained no PATH line, and ~/.zprofile / ~/.zshenv / ~/.profile didn't exist at all — so ~/.local/bin was never going to be picked up. W

Context PR #1980 just landed the SendInput half of #1979 — a fence-post in MOUSEEVENTF_VIRTUALDESK normalization that mis-routed clicks at the exact inter-monitor seam in negative-X layouts. 26 unit tests cover the math deterministically across 8 multi-monitor layouts, including the reporter's exact (-1920, 0, 3840×1080) setup. But the reporter's actual symptom in the original log goes through the PostMessage code path (post_click_screen / MAKELPARAM / ScreenToClient), which #1980 doesn't touch. A code-audit subagent is currently working on a follow-up fix for that path; PR will land separately. The ask We don't have a real multi-monitor Windows test rig, and we spent significant time trying to assemble one without success. Honest record of what we tried and where each path broke: Track A — Virtual Display Driver (VDD) on an Azure Windows 11 VM (server-side virtual displays) Downloaded VirtualDisplayDriver-x86.Driver.Only.zip v25.7.23 from itsmikethetech/Virtual-Display-Driver. p

Problem With multiple concurrent sessions (multi-agent — see #1798), each session has its own agent cursor, but they're all drawn into one shared overlay NSWindow. A single window can occupy only one z-band, so the overlay is pinned just above the last-active cursor's target window (acknowledged in cursor/overlay.rs:556-557: "a single NSWindow can occupy only one z-band, so the last-active cursor's target wins"). Consequence: a cursor that belongs to a background window can render on top of a foreground window — the cursor isn't z-correct relative to its own window. Desired Each session's cursor should sit at z(its session's target window) + 1 — visible above its own window, but correctly occluded by windows stacked above it. Proposal Replace the single shared overlay window with one borderless, click-through overlay window per session/cursor: create on the session's first cursor command, destroy on session_end / idle-TTL; render that cursor into its own surface (sized to the cu

Hi CUA team, I am trying to follow the official guide for using the Computer SDK in TypeScript: https://cua.ai/docs/cua/guide/get-started/using-computer-sdk The documentation shows the following example: import { Computer } from '@trycua/computer'; const computer = new Computer({ useHostComputerServer: true }); await computer.run(); // Connect to the host desktop However, I encountered several issues: I installed the latest NPM release (@trycua/computer v0.1.6) and earlier versions (0.1.2, 0.1.3, 0.1.5). In all cases, useHostComputerServer is not recognized as a valid parameter in the Computer constructor. Reviewing the TypeScript source code, I can only find CloudComputer and CloudComputerConfig. There is no apparent way to construct a Computer instance that connects to the local host desktop, as described in the documentation. The Python SDK works correctly with a local computer_server, so this seems to be specific to the TypeScript SDK. My questions: Which TypeScript SDK