Hands Lets MCP Click Real Chrome

The matching Show HN is “Hands-Rust MCP/CLI that sees the Windows desktop and clicks real Chrome.” This piece never stored that URL. Treat the tool names below as the record from the day we wrote this.

Hands is an independent developer's Show HN project for letting an agent operate a Windows PC through normal screen, mouse, keyboard, and browser surfaces. Coding agents can edit code well, but still struggle when the next step lives in a real Chrome profile, a desktop app, or a local UI that was not built for APIs. The takeaway for OpenAI Codex CLI users is simple: a Codex CLI MCP tool like Hands can be powerful, but you should verify which MCP servers are enabled before you hand it click and type permissions. In practice that means checking the active MCP tools first, then keeping desktop control behind a narrow boundary.

Understand what Hands actually exposes

Hands is a Rust MCP server and CLI that exposes desktop actions as callable tools. MCP is a protocol that lets an agent discover and call external tools through a server, instead of baking every integration into the agent itself.

The interesting part is not that Hands can “control a browser.” Plenty of browser automation stacks can do that. The author’s point is sharper: Hands uses the real Windows desktop and a real daily Chrome profile, not a special Playwright, Puppeteer, or Chrome DevTools automation session.

In the Show HN description, a harness such as OpenAI Codex, xAI’s Grok, or Anthropic’s Claude Code can call tools like observe, click, type, and scroll. observe returns a screenshot path plus a small element list from Windows UI Automation and, optionally, Chrome DOM IDs. click uses Windows input events rather than a DevTools click.

That design matters because it tests the same surface a human uses. It also raises the stakes. A tool that can click a real browser profile can click the wrong tab, send a message, approve a payment, or mutate production data if you expose it casually.

See why developers cared about real Chrome

Most coding-agent workflows get awkward at the browser boundary. The agent can change a React component, run unit tests, and explain a diff. Then someone still has to open Chrome, sign into a test account, navigate a local app, click through the bug, and confirm the UI now behaves.

Hands points at a different loop. Codex could edit code, start a local server, ask Hands to observe Chrome, click the failing control, type into a form, and observe the result. The workflow becomes less “agent writes, human verifies” and more “agent writes, agent drives the verification surface, human reviews the risky moments.”

A real repo example is a billing settings page running at localhost:3000. Codex changes a validation rule. Hands observes the page, clicks the “Add tax ID” field, types a fake value, submits the form, and observes whether the error state appears. That is useful precisely because the browser is ordinary Chrome with ordinary extensions, cookies, and rendering.

Don't confuse this with deterministic browser testing. It is not a replacement for Playwright suites in CI. It is closer to a manual QA assistant with hands: useful for exploratory checks, local repros, and UI debugging, but not something you should treat as a stable test runner.

Wire desktop control to a verification loop

The safe day-to-day shape is a loop: observe, explain intended action, act, observe again, then run a normal repo verification command. Codex should not get a blank check to operate the desktop just because a task mentions Chrome.

A good local loop looks like this:

npm run dev
npm test -- --watch=false
# then, inside Codex, allow a narrow MCP session:
# observe the local page -> click one target -> observe the result -> run tests again

Put the rule where Codex will keep seeing it. In a repo using Codex AGENTS.md instructions, add a small boundary note near the testing instructions:

## Desktop MCP boundary

When a desktop MCP tool is enabled, use it only against local dev URLs,
throwaway accounts, and non-production data.

Before any click or type action, describe the intended target and wait for
confirmation if the action can change account settings, billing, production
content, browser profile settings, or external messages.

Do not enter passwords, API tokens, payment data, recovery codes, or private
customer data through desktop tools.

Prefer observe-only debugging unless the task explicitly requires interaction.

This is boring on purpose. Boring boundaries are what keep a neat demo from becoming an accidental account action. For more patterns like this, the CLI workflows collects Codex CLI workflows that pair agent actions with verification commands.

Check enabled MCP before Hands gets a mouse

Before trying Hands as a codex mcp server, check what the current Codex session can actually call. On Codex CLI builds with an MCP subcommand, start with codex mcp list; if your build does not show that command, run codex --help and inspect the CLI config location documented for your version.

The practical version is not just “is Hands listed?” Check three things: the server name, the command it starts, and the tool surface it exposes. A read-only server that can search docs is a different risk class from a desktop server with click and type.

Here is the small decision table I would use before enabling a desktop MCP server in a real coding session:

The boundary note is simple: treat Hands as a high-trust Codex CLI MCP server, closer to granting a remote keyboard than adding a documentation search tool. That does not make it bad. It makes the permission line visible.

Keep the clever part small

The clever part of Hands is that it makes the agent operate the same UI you do. The practical part is deciding when that realism is worth the risk.

Use it when the bug only appears in a real browser profile, when a local UI needs visual inspection, or when a one-off repro is faster than writing a full automated test. Avoid it when the action touches durable external state, secrets, money, production records, or any browser session you would be nervous to lend to another person.

This is the same reason verification loops matter in ordinary Codex work. In A Week Choosing Codex Over Claude, the durable lesson was not that one agent should be trusted blindly. It was that the loop around the agent decides how safe the work feels.

Further reading

• hands on GitHub
• Show HN: Hands
• Codex CLI docs
• MCP specification

Try the next step

Try Hands only in a disposable Chrome profile against a local app, then write down the exact tools Codex could call. If that list still feels safe after you read it out loud, you have a reasonable first experiment.