Qwen Code's Computer-Use Driver Ships Prebuilt: macOS Signs It, Windows Makes You Sign It

Qwen Code’s computer-use driver now arrives as a downloadable binary for all three desktop platforms, and the release note is unusually blunt about who is responsible for trusting it. The cua-driver-rs v0.27.0 tag was published by the github-actions workflow on 30 Oct and is labelled Pre-release on the project’s releases page. Its headline is “Qwen CUA Driver prebuilt binaries (vendored under packages/cua-driver)”, and its body gives three different answers to one question: who signs this?

One release, three trust postures

Platform	What the tag ships	What you still owe it
macOS	Codesigned and notarized universal binary, plus QwenCuaDriver.app	Ship the driver outside ASAR, sign and notarize your own app around it, and run on macOS 13 or newer
Linux	Unsigned x86_64 and arm64 builds, glibc 2.31 floor	Verify the release checksum and supply your own trust policy
Windows	Unsigned UIAccess worker plus native SDK payload for x86_64 and arm64	Sign the worker and trust it on the target machine before UIAccess activation

The Windows row is the operational change worth writing down. The release note says deployments “must sign and trust the worker on the target machine before UIAccess activation”, and the @qwen-code/cua-sdk package page spells the mechanics out from the other side: Windows installs use the normal input path by default, and setting CUA_DRIVER_USE_UIACCESS=1 stages the optional worker under Program Files and “requires a valid trusted signature”. macOS is the opposite case. The binary arrives signed and notarized, but the SDK README is explicit that the application must spawn the daemon from the process that owns the Accessibility and Screen Recording grants, because launching through a gateway, a terminal or open changes the responsibility chain.

Our earlier Windows endpoint policy for computer-use agents treated entitlements as the hard part on Windows. They still are, but as of this tag the binary itself has joined the entitlement problem. Signing a worker is a routine CI step for a team that already ships a signed Windows app. It is a new step for a team that was running the normal input path and had never had to touch the worker.

Two switches, both off by default

The same tag adds two environment switches that change agent behaviour rather than packaging:

# cua-driver-rs v0.27.0 - both default off
CUA_DRIVER_RS_COORDINATE_SPACE=1     # relative coordinates
CUA_DRIVER_RS_COORDINATE_SCALE=1000   # optional scale factor
MCP_MODEL_PAYLOAD_FILTER=1           # textual MCP payload filtering, affected model API routes

CUA_DRIVER_RS_COORDINATE_SPACE defaults to 0, meaning off, and the note offers an optional CUA_DRIVER_RS_COORDINATE_SCALE whose example value is 1000. The tag does not define the coordinate contract beyond the name, so treat the scale as a hint rather than a specification: enable it on one lane, compare targeting accuracy, and only then let it near a fleet. A coordinate space is exactly the kind of change that moves the model’s clicks, and mis-set targets in a desktop agent are not a compile error.

MCP_MODEL_PAYLOAD_FILTER=1 is narrower. It is textual MCP payload filtering for “affected model API routes”, and the tag does not say which routes count as affected. The useful move is to switch it on for the routes you actually use and measure the effect on context pressure, rather than assume it applies fleet-wide.

Three details that argue for treating this tag as a checkpoint

The driver and the CLI are separate trains. On the releases list, cua-driver-rs v0.27.0 sits above Release v0.26.4, which was published the previous day and whose feature list includes feat(cua): enable default cursor and live macOS PiP. The driver tag’s own changelog also carries fix(cua): align input and session repairs with 0.27.0. The CLI release is the artifact most people will actually install, and it is where a computer-use behaviour change is most likely to reach you.

The registry may not have caught up. The npm page for @qwen-code/cua-sdk still listed version 0.26.0 as the latest published version when we captured it, with the last publish eleven days earlier. The tag says the same workflow publishes the SDK “after a clean install against these release assets”, and the same-version browser SDK and @qwen-code/node-repl-mcp after MCP protocol smoke tests. That SDK’s 0.26.0 also matches the driver’s previous tag range, cua-driver-rs-v0.26.0...cua-driver-rs-v0.27.0, which is how the two artifacts have been versioned together. Plan against the release assets rather than against a registry bump you have not seen.

Windows signing is still in motion. The v0.27.0 changelog carries fix(cua): sign Windows UIAccess workers before publishing, upstream work aimed at signing the worker at publish time. As of this tag the obligation still sits with the deployer. Signing policy for desktop agents is the kind of thing that changes again in a release or two, which is why a per-host register of driver build and signature state, of the kind we argue for in host inventory for computer-use agents, is worth more than a per-team note.

What to do this week

On a fleet that drives real desktops:

1. Record the driver build and its signature state per host, not per team. macOS (notarized), Linux (unsigned, glibc 2.31 floor) and Windows (unsigned until you sign it) are three different rows in that register.
2. If you want UIAccess on Windows, sign in CI and trust the worker on the target machine before the agent starts. Otherwise the activation simply does not happen.
3. Leave both new switches off in shared lanes until one host has measured them, then enable them deliberately and write down which routes you turned on.
4. Check the release list before you pin, and confirm the trust posture of the driver build your pinned archive actually carries. The Qwen Code documentation recommends a standalone archive when one is available and tells you to keep SHA256SUMS next to an offline archive, which is exactly the evidence a trust register needs.

What this release does not do is make desktop agents safer or easier to roll out. It makes the supply chain legible: one tag, three signing postures, two opt-in behaviour changes, and a checklist you can put in a runbook. That is the same discipline behind OSWorld 2.0’s trajectory checkpoints: you cannot debug a desktop agent’s behaviour if you do not know which binary, which signature and which coordinate space produced it. We have covered Qwen Code’s CLI train before, including session permission rules and the durable mid-turn queue; the driver is the part of that project that actually touches a person’s screen.