Give your coding agent eyes: a browser it can drive and assert against

Every developer who has pointed a coding agent at a web app knows the moment: the agent announces "I've fixed the form validation" — and it hasn't opened a browser. It edited the code, the types check, maybe the tests pass. Whether the button actually does the thing when a human clicks it is, politely, a guess.

The fix isn't a smarter model. It's giving the agent the same feedback loop you have: a browser it can open, drive, and read back from — sitting right next to its chat, where you can watch it work.

A CLI the agent already has

Every process hang4r spawns for a session — the Claude Code, Codex, or Cursor agent itself, every terminal, even worktree setup scripts — gets a hang4r CLI on its PATH, pre-scoped to that session's embedded browser. There is nothing to install and no API key to wire up. Instructing an agent takes one sentence:

"Run hang4r browser --help and use it to verify your changes."

The help text teaches the whole workflow. The agent navigates, snapshots the DOM, interacts, and asserts:

hang4r browser goto http://localhost:3000
hang4r browser snapshot --compact         # DOM outline with [ref=eN] handles
hang4r browser click e12
hang4r browser type e7 "[email protected]"
hang4r browser wait --text "Saved"
hang4r browser eval "document.querySelectorAll('.todo-item').length"
hang4r browser console                    # did the page throw?
hang4r browser screenshot                 # visual evidence

Assertion is the point

Clicking is easy; proving is the feature. The command set is built so "it works" becomes a checked claim instead of a vibe:

• wait — block until the UI actually shows the result (or fail loudly with what it was waiting for).
• eval — run any JavaScript in the page and get JSON back: row counts, computed styles, store state.
• console — the page's captured console log, where the real errors live.
• screenshot — a PNG the agent can attach to its summary, so you review evidence, not prose.

And the classic automation trap is handled at the root: type and select set values through the native prototype setters and dispatch real input/change events — so React- and Vue-controlled forms update the way they would for a human, not silently ignore the robot.

Watch it happen

This isn't a headless browser bolted onto the side. The agent drives the same Browser pane you see in the session tile — tabs and all. When an agent opens your dev server, the tab surfaces on screen; when it clicks through a flow, you watch the pages change. Trust comes from visibility, and the whole design keeps the human in the loop: it's your machine, your subscription, your screen.

It's session-scoped, too. Five agents in five worktrees each get their own browser and their own control channel (a token-authed local socket, rotated every launch) — one agent can't drive another's tabs, and nothing is exposed off your machine.

What this unlocks

1. Self-verifying frontend work. "Build the settings page, then walk through it in the browser and screenshot each state" is now a single prompt.
2. Honest bug reproduction. Ask the agent to reproduce the bug in the browser before fixing it — then re-run the same steps after. The console log and screenshots are the receipt.
3. Review with evidence. Combined with hang4r's per-turn checkpoints and diff review, a web change arrives as: the diff, the assertion output, and the screenshot. You approve outcomes, not promises.

The fine print

The session's tile needs to be open (the browser is real, not headless — that's the point), and SSH sessions are excluded because a remote host can't reach your local socket. Both limits are stated in --help rather than discovered the hard way — the same honesty rule the rest of hang4r follows.