Version 0.1.1 contains a driver and a decision loop
Version 0.1.1 packages two tools that deserve separate decisions. arc-driver exposes macOS windows, accessibility elements, menu commands, screenshots, and input through Python or MCP. Your existing agent chooses each action, and the driver needs no model key. arc-cua adds a loop in which a decision model picks from the actions currently available for a bounded subtask. That separation lets a team adopt the driver without adopting JEV.
The driver targets one exact window by process ID and window ID. A snapshot records elements and the actions each one offers, then freshness checks can refuse an action when the app or target changed. This is a better contract than telling a model to click whatever happens to occupy a screen coordinate. It also lets Claude Code, Codex, or another MCP client inspect a background app without taking over the user's pointer.
What happened when we ran it
Our sandbox installed commit 74ffae1 in 20 seconds, pulled 44 packages, and used 63 MB on disk. The build succeeded in 2 seconds. The checkout itself had 100 files, about 19,853 lines of source, and occupied 1.1 MB. We found a tests directory, no Dockerfile, and 0 CI workflow files.
Pytest failed with exit 1 after 33 seconds. Its summary reported 360 passed, 8 failed, and 1 skipped of 368. Every failure shown in the supplied log was tied to the macOS path: ApplicationServices was unavailable, or the runtime asked for pip install 'arc-cua[macos]'. The result does not show eight unrelated product defects. It shows that the default Debian install cannot complete the full suite.
Pip-audit reported 2 known vulnerabilities, without advisory details in the measurement block. That count deserves investigation before deployment, but naming affected packages would be guesswork. The 360 passing tests are encouraging for a young codebase. They do not replace a macOS test on the exact OS version, permissions, and applications an agent will control.
Version 0.1.1 needs macOS privacy permissions
Version 0.1.1 requires Python 3.12 or newer and the macos extra for native desktop work. The process hosting the driver needs Accessibility permission; screenshots add Screen Recording. macOS grants those rights to the terminal or application that launched the MCP server, so a correct uvx command can still fail until the host process is approved in Privacy and Security settings.
Hidden and minimized windows are part of the appeal. The driver can use accessibility directly, or move a window onto an invisible display when real input or pixels are required, then restore it. Windows on another Space remain unreachable, HTML5 drag and drop is unsupported, and menu commands act on the app's key window. Those limits matter when several documents from one app are open.
Four open issues affect action accuracy or safety
Four issues opened on October 6 and 7, 2026 describe failures that cut into the core promise. Issue 4 reports pixel actions landing offset by the window's origin. Issue 5 shows an unlabeled title-bar close button escaping the close risk check. That second report says the decision loop clicked a TextEdit close control without allowed_risks permitting it.
Issue 6 finds that saving an untitled TextEdit document in the background does nothing, even though the driver returns done with reacted: false. Issue 7 reports stale screenshots for a covered Spotify window, including 2 byte-identical frames taken 10.9 seconds apart while playback state changed. These are precise reports with reproduction details, which is useful, but adopters still inherit the unresolved behavior.
One decision model chooses only offered actions
The decision loop can use JEV through TypeSafe, or a custom transport that returns typed choices, confidence, and probabilities. The caller supplies the goal, verification criteria, literal inputs, action cap, and allowed risk categories. Secret inputs are hidden from model-facing text, although screenshots are explicitly not redacted. Invalid model choices execute nothing and can be retried once by default.
That design narrows what a fast model may do, but issue 5 shows why labels cannot be the only safety boundary. An unlabeled close button slipped past a word-based check even though backend metadata knew its role. Until that path is fixed, run dry checks where possible, keep destructive tasks supervised, and verify outcomes outside the driver rather than treating done as proof.
The October 6 push follows the v0.1.0 release
GitHub showed 283 stars and 6 combined open issues and pull requests after a push on October 6, 2026. Release v0.1.0 arrived on October 3, while the checked-in package metadata says 0.1.1. The repository is moving and issue reports received detailed technical write-ups, but it is still an early release with action-layer defects found within days.
Try the standalone driver first, on a spare macOS user account and a harmless app. Its exact-window model, MCP surface, and background control are distinctive enough to justify that test. Delay unattended use of the decision loop until the risk guard and pixel paths are fixed, then rerun the suite with the macOS extra and review the 2 audit findings.