Reading Cua Driver 0.26.1 Computer Use Internals — Pinning the Window Target and Separating Action Facts from Postconditions

I recently wrote back-to-back code-reading tours of Hermes Agent and Open Interpreter Computer Use. Both delegate the actual OS operations to an external cua-driver, so the natural next question was what happens on that other side of the boundary. This article is that follow-up, pinned to commit b4e3caec of the trycua/cua monorepo and scoped to Cua Driver 0.26.1. It follows one request from MCP, CLI, or the in-process SDK through to the OS input API, and back out through the public ActionResult and verify_state. Along the way it walks through eight design forks: the shared native dispatch, WindowTargetGuard, element_token, ScreenCaptureKit on macOS, WGC / PrintWindow on Windows, X11 / Wayland on Linux, the closed action contract, and the three-layer permission story.

Reading Hermes Agent v2026.9.7 Computer Use Internals — Capture as Target Binding and Background-First Verify → Escalate

I wrote two Hermes Computer Use posts recently (a selection review and a macOS setup log), and while watching the agent drive Calculator in the background I kept wanting to know what a single computer_use call actually does under the hood. This article is that follow-up: a code-reading tour pinned to Git tag v2026.9.7, tracing one model tool call through to a real OS action and back. Along the way it hits the five design forks I found most instructive: capture doubling as sticky-target binding, background-first with verify → escalate, mutation-safe behavior on MCP timeout, the three image return routes, and the two separate approval layers between Hermes and cua-driver.

Reading Open Interpreter rust-v0.0.42 Computer Use Internals — From the QA Skill to cua-driver CLI

I recently wrote a code-reading tour of Hermes Agent v2026.9.7 Computer Use. Open Interpreter's README also documents cua-driver usage, so I wanted to know how much of the agent-side implementation is actually shared and where it diverges. This article is that follow-up: a source-only tour pinned to Git tag rust-v0.0.42, tracing one QA request through the qa-testing skill, the cua-driver CLI, and the Cua daemon, then back to the model with the result and screenshot. Along the way it hits six design forks: a QA skill embedded in the binary, delegation to external CLIs instead of a bespoke tool schema, generic command execution and approval, the view_image bridge for images, the three-layer permission story, and the reproducibility gap because pinning the OI tag does not pin the Cua version.