Terminal-Browser: A Real Web Browser for AI Coding Agents, Rendered in Your Terminal

Terminal-browser renders live Chromium pixels inside a terminal pane using the kitty graphics protocol, not an ASCII approximation of a webpage and not a text-only reader mode. It's a free, open-source project from Zenbu Labs that's climbed to 1,917 GitHub stars since it was created on July 6, 2026, and it was still the fastest riser in a GitHub trending scan this week, up nearly 40 percent in a single day. That kind of velocity is worth a real look rather than a passing mention, so here's what it actually does, verified against the repo itself rather than the launch copy.

How a real browser ends up inside a terminal

The mechanism is the interesting part. Most terminals can only draw text, so showing a rendered webpage inside one has always meant faking it: stripping a page down to plain text, or drawing crude block-character approximations of images. Terminal-browser does neither. It uses Electron's offscreen rendering API to capture the actual pixels Chromium generates on the GPU, then pushes those pixels into the terminal using the kitty graphics protocol, a real image-transfer protocol supported by terminals like Ghostty, Kitty, cmux, and VS Code's integrated terminal. Mouse and keyboard input runs the other direction: terminal input events, plus OS-level input monitoring through a background Swift app, get synthesized back into events Chromium understands. The browser's own UI chrome is built in Rust with a custom React renderer.

The practical result is a browser that behaves like a browser, not a stripped-down substitute. Pages render with real layout, real images, real JavaScript. The tradeoff for that fidelity is the terminal requirement: this only works in a terminal that speaks the kitty graphics protocol. A default Terminal.app or an older terminal emulator without that support won't display it correctly.

Built to sit next to a coding agent, not replace your daily browser

Where terminal-browser earns its place is the specific workflow it's built around: split-pane browsing alongside a terminal-based coding agent, in the same pane you're already working in. If you're running Claude Code, Codex, or a similar CLI agent and need to check how a page actually renders, read a docs page, or watch a dev server update live, the normal move is tabbing out to a separate Chrome window and back. Terminal-browser keeps that inside the same terminal split instead.

The part that makes it more than a novelty for agent workflows is the CLI surface built for programmatic control. terminal-browser open <url> launches a browser at a given address, and terminal-browser action is described in the project's own docs as "an agent-browser compatible CLI for interacting with open terminal-browsers," meaning a coding agent can drive an already-open browser instance directly rather than only opening a new one. terminal-browser ls lists active instances, useful once more than one is running. There's also an --ssh <user@host> <url> mode that proxies the browser through a remote server, built for previewing a site running on a remote box without opening a separate SSH tunnel by hand.

The project's own docs are honest about a limitation worth knowing before relying on this for anything remote: running terminal-browser directly over a plain SSH session, without the --ssh flag, means every frame the website draws has to travel over the network, and every keystroke or click has to round-trip back before the page can react. That's workable for checking something quickly, but it's a genuinely different experience from a local terminal, and it's exactly the gap the --ssh flag is built to close by proxying more efficiently instead.

License, install, and what's actually verified

Terminal-browser is MIT licensed, confirmed directly against the repository rather than assumed from a badge in the README. MIT means there's no restriction on using it inside a commercial workflow or bundling it into something else you ship. Installation is a single shell command: curl -fsSl https://terminal-browser.sh/install | bash. There's no account, no signup, and no paid tier anywhere in the flow.

Platform support is macOS and Linux. There is no Windows build, and nothing in the repo suggests one is planned, so this isn't a fit for a Windows-based agent workflow today. Within macOS and Linux, the real constraint isn't the OS itself but the terminal: it has to be one of the kitty-graphics-protocol terminals named above, which rules out plenty of still-common terminal setups that haven't adopted that protocol.

Who terminal-browser is actually for

Terminal-browser fits a specific kind of setup: someone running a coding agent from the terminal for most of the day, on macOS or Linux, already using (or willing to switch to) a kitty-protocol terminal like Ghostty or Kitty, who finds tabbing out to check a page mid-task a real interruption to flow rather than a minor annoyance. For that person, the split-pane setup plus the agent-compatible CLI genuinely removes a context switch that happens dozens of times a day.

It's a weaker fit if your daily terminal is one that doesn't speak the kitty graphics protocol and you're not interested in switching, if you're on Windows, or if your actual need is a full-featured browser with extensions, saved logins, and a normal tab bar for general browsing rather than quick, agent-adjacent checks. Terminal-browser isn't trying to replace Chrome as a daily driver; it's solving the narrower problem of not having to leave the terminal to see what a page looks like.

The 1,917 stars and the reported acceleration are a genuine trending signal, not proof of maturity on their own, so it's worth treating this the way any month-old open-source project deserves: a real trial on a low-stakes task before it becomes the only way you preview a page mid-build.