terminal-browser: A Real Browser in Your Terminal Your Coding Agent Can Drive

Your coding agent can edit every file in the repo, but it cannot see the page those files render. You paste screenshots back and forth and describe what went wrong in words. terminal-browser — a 3k-star MIT-licensed tool — closes that gap by running a real Chromium browser inside your terminal, where your agent already lives.

Why This Skill Matters

Headless browser tools give agents DOM snapshots, but you and the agent still look at different things. terminal-browser renders actual pixels in the terminal window using the kitty graphics protocol, so you watch the same page the agent drives, in the same tab, next to your editor. The README's use cases follow from that: a coding agent and a website scoped to the same terminal tab, an agent that can interact with open browser instances, HTML plans that open in a split pane as soon as the agent writes them, and remote servers previewed over SSH.

It is a native app, not a skill folder — the agent side works through the CLI and an optional Claude Code plugin.

Installation

On macOS or Linux, install with curl or Homebrew:

curl -fsSL https://terminal-browser.sh/install | bash

brew install terminal-browser

The Claude Code plugin route adds the /browser command. The plugin README calls itself experimental with known limitations, and the setup has one prerequisite beyond a current Claude Code version: enable UI plugins in ~/.claude/settings.json:

{
  "env": { "CLAUDE_CODE_ENABLE_FUNCTION_HOOKS": "1" }
}

Then install the plugin:

claude plugin marketplace add zenbu-labs/terminal-browser
claude plugin install terminal-browser@terminal-browser

Run /browser inside Claude Code and the browser opens in your terminal.

Real Workflow: Let the Agent Verify Its Own Frontend Change

Ask your agent to fix a layout bug, then have it open the result instead of describing it. With the plugin installed, /browser opens the browser; without it, do the same from the shell:

terminal-browser --split right
terminal-browser open http://localhost:3000

The browser opens in a pane to the right of the agent's code, and terminal-browser open <url> points it at your site. The agent drives the open browser through terminal-browser action, which the README describes as an agent-browser compatible CLI for interacting with open terminal-browsers. When you want to point the agent at a specific element yourself, press ctrl+g: the shortcut table lists it as starting element selection to send to the agent.

One terminal requirement decides whether any of this works: your terminal must support the kitty graphics protocol. The README names ghostty, kitty, cmux, and vscode among terminals that do.

Tips

• terminal-browser ls lists every open browser instance when a long session leaves several running.
• Over SSH, prefer terminal-browser open --ssh <user@host> <url>: rendering stays on your machine and only the network requests are proxied through the remote server, so remote localhost sites load at local speed.
• Scrolling and trackpad events work because a background helper listens for input the terminal cannot deliver — the README documents this as a background Swift app reading OS-level events.
• Update both parts separately: terminal-browser upgrade for the app, claude plugin update terminal-browser@terminal-browser for the plugin.

When Not to Use This

If your terminal does not support the kitty graphics protocol, the core rendering approach does not work — there is no fallback documented in the README. If you need Chrome extensions, that is a roadmap item, not a shipped feature. And if you only need an agent to scrape page content with no shared visual context, a plain headless browser remains the lighter option; this tool earns its keep precisely when you and the agent should be looking at the same screen.

See the leaderboard for more skills.