#Drive the browser you are already signed in to

reins is a CLI that hands your coding agent the real Chromium browser you already use. Claude Code, Cursor, Codex, anything with a shell. The logins, the cookies and the sessions are already there, because it is your browser. No debug profile, no launch flags, no MCP server to register.

##Install

Three pieces, and the second is the one people skip. Without the skill, your agent has the CLI installed and no idea the commands exist.

1. The CLI. The daemon rides inside it and starts on demand.
   $npm i -g @karnstack/reins
2. The skill, so your agent knows the command set. Agents without skill support can read reins help instead, but do not skip this if yours supports it.
   $npx skills add karnstack/reins
3. The extension, in every browser you want agents to reach. It finds the daemon on its own, and the toolbar icon turns green once it connects.

   Add reins from the Chrome Web Store

Then reins status shows what is connected.

$ reins snapshot  e3: input "Email"  e7: button "Sign in"$ reins click --ref e7  ✓ clicked e7

##What it does

• Every tab, every browser. List, open, focus and close tabs across Chrome, Brave, Edge, Arc and Dia. One daemon serves every browser that connects to it.
• Act on the page. Click, type, fill, select, hover, scroll, press keys, upload files, answer dialogs, resize the window.
• Refs, not selectors. reins snapshot lists the interactive elements with stable refs, and commands act by ref. A CSS --selector is there when you need it.
• Read the page. Visible text, and screenshots your agent can open and reason about.
• Console and network, without opening DevTools. Recent messages and requests, filtered by level, age or URL.
• An escape hatch. reins eval runs JavaScript in the page. reins cdp sends a raw Chrome DevTools Protocol command when the curated set is not enough.
• Site permissions. Every host resolves to deny, read or full, and the extension enforces it before a command touches a tab.
• An audit trail. Every command the daemon runs, and every one the policy blocks, appends one line to ~/.reins/logs, with the values redacted.

##The loop

Every page interaction is the same three beats: look, act, check. The commands that act on a page or a tab share three flags: --tab <id> (the active tab by default), --browser <id> (only when more than one browser is connected) and --json for raw output.

$ reins snapshot  e3: input "Email"  e7: button "Sign in"$ reins type --ref e3 --text "you@work.dev"$ reins click --ref e7$ reins text  Signed in as you@work.dev

→Full command reference

##How it works

Three pieces with one narrow contract between them, and all three run on your machine. The daemon ships inside the CLI and starts on demand, so there is nothing to keep running and nothing to register per agent.

your agent            your machine                  your browser
shells out            daemon, starts on demand      extension, MV3
reins <cmd>  ───────► 127.0.0.1  ──────────────────► chrome.debugger, CDP

The extension finds the daemon by probing a small set of localhost ports, and authenticates by its chrome-extension://<id> origin, a header the browser stamps itself and a page cannot forge. Chrome shows its native debugging banner the whole time it is attached.

→How the three pieces fit together

##Site permissions

Every site your agent touches resolves to one of three tiers. The check lives in the extension, the one place no process on your machine can reach around, so a misbehaving agent cannot skip it.

Granting more access takes a click in the extension popup. That is a user gesture, and an agent in your shell cannot perform one. From the CLI, reins policy can inspect the policy and tighten it. It can never loosen it.

→How site permissions work

##Facts

##Limits

##More

No Chrome Web Store access? reins extension stages the bundled copy for Chrome's Load unpacked, with no reins allow step.

Press ⌘K anywhere on this site to search the docs.

→Setup guide

→Source