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 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.