[earakely-scale]

What

macOS computers install CuaDriver.app from cua-driver-rs 0.47.10 instead of 0.38.0:

• env.toml [install.macos]: the release tarball's URL and sha256.
• install-app.sh: the tarball's folder.
• driver.py EXECUTABLES["macos/arm64"]: CuaDriver.app's executable sha256.
• mcp-macos.json: what 0.47.10's cua-driver mcp serves.
• env.toml [[known_failures.macos]] and the drivers README: the P6 and P7 waivers say what 0.47.10 does.

Linux's X11 build and Windows stay at 0.38.0. Omarchy is already on 0.47.4.

How mcp-macos.json was made

It's cua-driver mcp --direct on an EC2 Mac: initialize, then tools/list and resources/list, keeping the fields the drivers README names. Serialization follows the pinned file's conventions: every tool field present (null when absent), resources' missing fields left out, two-space JSON.

To check the method, the same dump of 0.38.0 reproduces the current mcp-macos.json byte for byte.

What changed in 0.47.10:

• The same 62 tools and 11 resources.
• Twelve input schemas gain optional fields: post_action_wait on the input tools, screenshot_format and screenshot_quality on get_window_state. Nothing the driver sends was renamed or removed.
• Ten descriptions, fifteen output schemas and the instructions changed.

Gate 3 on 0.47.10

13 macOS computers (the bench's BenchLab and three multi-app desktops) were composed at this branch's first commit on 11 EC2 Macs ([sandbox] default = "lume"). Every one is ready, with the same full probe: 49 checks passed, 1 not applicable, 1 failed.

• P6, typed text arrives as key events: fails in all 13, as waived. The text arrives whole (P6's Unicode check passes), but the fixture sees no key events for H, W, space or comma. Desktop type_text sends each character as a key-down and key-up of keycode 0 carrying the character as Unicode (type_text_global in cua-driver-rs 0.47.10). 0.38.0's waiver blamed only the key-up, so its reason is rewritten.
• P7, a drag starts and ends where it says: passes in all 13. The waiver stays. 0.47.10's foreground drag posts the same events as 0.38.0's (drag_at_xy_foreground_observed), and 0.38.0's failure was intermittent: feat(computer): macOS computers as VM bundles composed on a Mac, the lume provider, and cua-driver on macOS #484 saw it pass in one probe and fail in an earlier one. A probe it passes records it under unused_known_failures, so it's visible if it never fails again.

Does it work

• The bench's macOS cua-driver rerun ran on these computers: 7 models × 90 trials, 630 in all, every one exported. Claude Sonnet 5.5 passes 43 of 50 foreground trials (39 on 0.38.0) and 23 of 40 background ones (23).
• computer-ready held on every deploy: the executable's sha256 and the 62 pinned tools with their input schemas.

Tests

• tst/unit/drivers, tst/unit/bundle/shipped_bundles_test.py, tst/unit/bundle/computer_driver_env_test.py, tst/unit/env/envs/test_computer_env.py: 345 passed.
• ruff check src/agent_env/drivers tst/unit/drivers: clean.
• macOS has no CI tier, so gate 3 above ran by hand on the EC2 Macs.

🤖 Generated with Claude Code

Confidence Score: 5/5

The PR appears safe to merge; no actionable defect was established.

Summary

Updates macOS to cua-driver 0.47.10 and refreshes its pinned tool descriptions and schemas.

• macOS arm64 computers now install CuaDriver 0.47.10.
• macOS callers now see CuaDriver 0.47.10's updated tool options and guidance.

Validation here was limited to code inspection; no native macOS run was performed.

_{Reviews (1) · Last reviewed commit: "fix(drivers): cua-driver 0.47.10's macOS..." · Reviewed by Greptile}