Hands Lets MCP Click Real Chrome

Hands-Rust MCP/CLI that sees the Windows desktop and clicks real Chrome is an independent developer’s Show HN project for letting an agent operate a Windows PC through normal screen, mouse, keyboard, and browser surfaces. It deals with a stubborn automation gap: 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. That is the practical answer behind how to check enabled mcp in codex: inspect the active MCP tools, then keep 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.

The trap is confusing 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 related training topic 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.

Common questions

• Is how to check enabled mcp in codex really just codex mcp list?

  Usually, yes, but only if your Codex CLI build includes that MCP subcommand. The safer answer is to check the enabled server list, confirm the command behind each server, and review the exposed tools before starting the session. A desktop server with click and type deserves more scrutiny than a read-only search tool.

• Can Hands replace Playwright for browser tests?

  No, Hands should not replace Playwright-style CI tests. Its value is driving a real Windows desktop and daily Chrome profile for exploratory checks, local repros, and visual debugging. Keep deterministic browser tests in CI, then use Hands when the interesting failure depends on the messy human environment.

• Is clicking real Chrome safe for a Codex agent?

  It can be safe only inside a tight boundary. Use localhost, staging sandboxes, fake accounts, and visible confirmation before any action that mutates external state. The moment the agent can type into a real profile, the risk changes from “tool call” to “someone else is using my keyboard.”

• Should I enable a codex cli mcp server globally?

  For desktop control, no. Enable it for the specific task, verify the tools exposed, and disable it when the session is done. Global MCP access is more reasonable for read-only systems like documentation search, but mouse and keyboard control should be treated as temporary capability.

Best ways to use this research

• Best for: Codex users evaluating whether a desktop MCP bridge is useful for local UI debugging, not readers looking for a generic browser automation tutorial.
• Best first artifact: Add the AGENTS.md desktop MCP boundary note before enabling any tool that can click or type.
• Best comparison angle: Compare Hands against Playwright by job, not by ambition: Hands is for real-profile exploratory interaction; Playwright is for repeatable browser tests.
• Best safety check: List enabled MCP servers, identify which ones expose write-like tools, and keep observe-only access as the default starting point.

Further reading

• OpenAI Developers — Codex CLI
• OpenAI Developers — Codex CLI features
• Model Context Protocol — 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.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.