DEVELOPMENT DOCUMENTATION / COMPUTER USE

Desktop operations behind an explicit policy.

The computer.v1 adapter targets a locally supervised CUA Computer Server. It is not an unrestricted proxy to the server's entire API.

Pinned backend

The reviewed backend is cua-computer-server 0.3.46, a Python sidecar. The profile pins its /cmd command surface. CUA Driver is an optional backend of that server, not a separately supported Rust or stdio service.

Read-only VM evidence

The repository now records a read-only probe inside a disposable Ubuntu 24.04 arm64 VM at 1280 by 800 and identity scale, using synthetic screen markers. It queried server status, commands, screen/cursor state and screenshots for native, VNC and CUA Driver variants. No input was sent and no tunnel device ran in the guest. This is backend observation, not end-to-end CUA acceptance: CLI export wiring, input side effects, non-identity scaling and macOS/Windows guest verification remain open. No VM or desktop probe was run for this website review.

Capability mapping

Parameter compatibility

Command and parameter names are now pinned against the released backend source. Drag is sent as a two-point path; scroll uses x and y as wheel amounts, not cursor coordinates. These are source-backed compatibility corrections, not a real-backend test result.

Known backend limitations

• Display selection: capture and screen information accept only the backend's default display, index 0. Other indices are refused before dispatch with DisplayNotSelectable; multi-display targeting is not supported.
• Scroll location: the consumer schema takes only dx and dy; requests naming a position are refused. Scroll acts at the cursor, so positioning requires a separate move. Positive dy means up in the pinned backend sources; Android's swipe mapping remains an inference. On CUA Driver, a nonzero vertical delta drops the horizontal delta, and two zero deltas produce a dispatched failure. Real-backend units and behavior still require verification.
• Capture identity: dimensions now come from a checksum-validated PNG header, not nonexistent response fields. JPEG captures do not yield a coordinate identity. Scale must be explicitly declared on the device; absent scale refuses coordinate input with ScaleUndeclared. How a real device obtains that declaration remains undecided and needs a disposable-VM probe. The pinned macOS backend resizes wide captures, so image dimensions alone do not establish input-coordinate scale.

Routing and input leases

computer.v1 is not yet routed through the relay. Device-local fixture mechanisms now release leases when they learn a newer grant revision or end a session, and ignore stale revisions. Production delivery of those signals remains unimplemented; no through-relay CUA revocation gate has passed. A stale lease can still block another agent until the device-side session ends. A non-revoking grant change can also release a lease between a move and a click, allowing another agent to intervene; do not assume multi-operation input sequences are atomic.

Excluded surfaces

The initial profile does not expose arbitrary shell commands, host file APIs, clipboard, PTY, Playwright execution, the backend's MCP server or its responses API. Filesystem access has its own confined service.

The shipped provision-catalog workflow does not create computer-use services. Its MCP, ACP and filesystem provisioning support does not establish a CUA setup path or real-desktop acceptance.

Response semantics

The pinned /cmd implementation can return HTTP 200 with a failure payload. Its response uses data-framed JSON with a text/plain media type, so callers must not infer success from the status code alone or assume ordinary JSON.

Input is a side effect

A lost click response does not mean the click never happened. Never repeat input automatically after reconnect. Capability discovery must intersect backend support, local export policy and the caller's grant. Synthetic fixtures do not prove real parameter schemas, permission prompts, display scaling or focus behavior.