# terminal-browser
A real browser that runs inside your terminal
<video src="https://github.com/user-attachments/assets/abe2f43e-fc50-4866-b753-33388967945d" controls></video>
## Installation
### curl (macOS & Linux):
```bash
curl -fsSL https://terminal-browser.sh/install | bash
```
> Note: Run `terminal-browser upgrade` to upgrade versions
### Homebrew (macOS & Linux):
```
brew install terminal-browser
```
### Windows
To install on Windows you must be using WSL. Terminals with kitty graphics support are also very limited on Windows, the following are terminals I have tested that terminal-browser will work on inside Windows:
- https://noctty.com/
```bash
curl -fsSL https://terminal-browser.sh/install | bash
```
### Claude code plugin
[Install instructions here](/claude-code-plugin/README.md)
### Usage
```
terminal-browser # launches the browser
terminal-browser open <url> # opens the browser at a url
terminal-browser --split right # opens the browser in a split pane to the right
terminal-browser open --ssh <user@host> <url> # performs all network requests through a remote server
terminal-browser open --transparent <url> # the terminal background will show through pages without a background color
terminal-browser ls # lists open browsers
terminal-browser action # an agent-browser compatible cli for interacting with open terminal-browsers
terminal-browser upgrade # upgrade to the latest version
```
### Use cases:
- You can have a coding agent and website scoped to the same terminal tab
- Your agent has full access to interact with open terminal-browsers, which gives your agent the capability to use the web
- You can ask an agent to make HTML plans and then open them inside terminal-browser, which will automatically open in a split pane next to your agent
- terminal-browser works over SSH, which allows you to preview websites running on remote machines easily
### Shortcuts
| Action | macOS | Linux |
| --- | --- | --- |
| Quit | ctrl+q or ctrl+c | ctrl+q |
| New tab | cmd+t | ctrl+t |
| Next / previous tab | ctrl+tab / ctrl+shift+tab or cmd+alt+right / cmd+alt+left | ctrl+tab / ctrl+shift+tab or ctrl+pagedown / ctrl+pageup |
| Edit URL | cmd+l | ctrl+l |
| Command palette | cmd+p | ctrl+k or alt+k |
| Find in page | cmd+shift+f | ctrl+shift+f |
| Next / previous match | enter / shift+enter | enter / shift+enter |
| Reload | cmd+r | ctrl+r |
| Back / forward | cmd+[ / cmd+] or ctrl+[ / ctrl+] | ctrl+[ / ctrl+] |
| Zoom in / out / reset | your terminal's zoom keybind | your terminal's zoom keybind |
| Devtools | cmd+shift+i or f12 | ctrl+shift+i or f12 |
| Devtools console | cmd+alt+j | ctrl+alt+j |
| Copy / paste / cut | cmd+c / cmd+v / cmd+x | ctrl+c / ctrl+v / ctrl+x |
| Record page (start/stop) | ctrl+r | ctrl+shift+r |
| Complete recording review | ctrl+enter | ctrl+enter |
| Start element selection (send to agent) | ctrl+g | ctrl+g |
| Close popup / overlay | escape | escape |
### How does it work?
Terminals that support the kitty graphics protocol, including ghostty, kitty, cmux, vscode and many more, allow a program running in a terminal to display pixels in your terminal. We use this capability to display pixels generated by chromium.
We use [electrons offscreen rendering API](https://www.electronjs.org/docs/latest/tutorial/offscreen-rendering) to read pixels generated by chromium directly from the GPU. Any time a website visually changes, terminal-browser only sends small patches to the terminal that cover changed regions. These choices allows terminal-browser to render smoothly without dropping any frames.
After the browser engine starts and is displaying pixels in the terminal, it needs to be able to read user input for websites to actually work. terminal-browser listens to mouse clicks, mouse position, and keyboard events from the terminal, and then sends synthetic events to chromium based on that data. For any user input events that are not retrievable from the terminal, we read directly from the operating system using a background swift app to listen for input events (non intrusively). This is what allows terminal-browser to implement smooth scrolling, and listen to trackpad events (websites with infinite canvases work great inside terminal-browser!)
The outer UI of the browser is implemented using a graphics engine built on top of rust. The actual UI is defined inside react with a custom react renderer, which allows us to build the UI for the browser using typescript. The UI of the outer browser and the browser content itself is all drawn to the same shared canvas inside the rust engine, which allows us to layer UI on top of the browser.
The underlying logic described here has been abstracted into a javascript library that you can use to build your own graphical applications in the terminal - [`pixel`](./pixel)
### SSH
The recommended way to use terminal-browser over ssh is running `terminal-browser --ssh <ssh arguments>`.
The alternative is running terminal-browser directly on the machine you are shh'd into. This will work, but:
- requires every single frame drawn by the website to be sent over the network
- all user input must be sent over the network before a website can react
- misses out some [extra optimizations](https://sw.kovidgoyal.net/kitty/graphics-protocol/#local-client)
`terminal-browser --ssh` improves on this by running the website on your local device, and simply proxying all network requests made by the browser via the remote machine over ssh. This means you can load any website running on `localhost` of the remote machine on your local device.
### Embedded mode
terminal-browser supports embedding inside of existing TUIs. See
[examples/embedded](examples/embedded/) for a reference implementation
### Telemetry
terminal-browser collects psuedo-anonymous usage events that gives me the ability to see how many people are using the project, which is extremely helpful information for improving the project.
telemetry can be disabled by any of the following:
- DO_NOT_TRACK=1
- TERMINAL_BROWSER_NO_TELEMETRY=1
- disabling via the settings GUI in general
- terminal-browser config set telemetry.usage off
All data that is sent is appended to `~/.local/state/terminal-browser-*/logs/telemetry.jsonl`, which allows you to audit no sensitive or identifying information is leaving your machine.
terminal-browser also collects crash reports if terminal-browser fails to start or unexpected errors occur internally. This can be disabled by any of the following:
- DO_NOT_TRACK=1
- TERMINAL_BROWSER_NO_TELEMETRY=1
- disabling via the settings GUI in general
- terminal-browser config set telemetry.crashReports off
If you are using [pixel/](pixel/), no telemetry is ever active and there is nothing to disable.
### Roadmap
- linux support ✅
- design mode ⏳
- chrome extensions ⏳
### Contributing
- PR **descriptions** must be authored by humans and explained well, otherwise we will close them
- When making a PR, the motivation must be clearly defined in the description
- Minimize the size of your PR for the best chance to get it landed
To get a local development setup of terminal-browser, the recommended way is to ask a coding agent.
### Terminal support
terminal-browser exposes an API that terminals can implement which will allow terminal-browser to reliably script the terminal it is running inside. This allows terminal-browser to open new panes, split panes, send text to a coding agent, and focus panes. Terminals that implement this API can be used to run terminal-browser in a more integrated way.
#### Implementing the API in your terminal
A terminal implements the API by listening on a unix socket and telling terminal-browser where it is:
1. On launch, listen on a unix socket (for example `$TMPDIR/<your-app-id>.terminal-browser.sock`). Only accept connections from the same user.
2. Set `TERMINAL_BROWSER_TERMINAL_SOCKET=<socket path>` in the environment of every shell you spawn.
3. Handle requests. Whenever terminal-browser needs something from the terminal it connects to your socket, writes a JSON request terminated by a newline, and waits for a JSON reply terminated by a newline. Once you have written the reply, close the connection. Every request gets its own connection, so there is no session state to keep.
A request is a JSON object with the method to run, its params, and who is asking. `caller` is the process that ran terminal-browser:
```json
{ "id": "<unique string>", "method": "<name>", "params": { ... }, "caller": { "pid": 12345, "cwd": "/path" } }
```
Reply with the same `id` and either a `result` or an `error`:
```json
{ "id": "<same id>", "result": { ... } }
{ "id": "<same id>", "error": { "message": "..." } }
```
The first request is always `hello`. Your reply lists which methods you implement, and terminal-browser disables any feature that depends on a method you leave out:
```json
→ { "method": "hello", "params": { "protocol": 1 } }
← { "result": { "name": "my-terminal", "methods": ["getCurrentPane", "split", "listPanes", "neighbor", "sendText", "pasteKey", "focusPane"] } }
```
A pane is `{ "id": string, "tab": string }`. `id` is any stable identifier for the pane, `tab` is shared by every pane that is visible on screen together
API:
| method | params | result | powers |
| --- | --- | --- | --- |
| `getCurrentPane` | `{ tty, cwd }` | `{ pane }` or `{ pane: null }` | `ls`, `new-tab`, picking where `--split` goes |
| `split` | `{ from: pane, direction, command: string[], size, tty }` | `{}` | `--split` |
| `listPanes` | `{ tty }` | `{ panes: [{ id, tab, tty, command }] }` | finding the coding agent's pane |
| `neighbor` | `{ from: pane, direction }` | `{ pane }` or `{ pane: null }` | opening next to an existing browser |
| `sendText` | `{ pane, text }` | `{}` | sending page content to a coding agent |
| `pasteKey` | `{ pane }` | `{}` | sending images to a coding agent |
| `focusPane` | `{ pane }` | `{}` | jumping between the browser and the agent |
Extra notes:
- `direction` is one of `right`, `left`, `down`, `up`. `size` is the fraction of the space the new pane should take (`0.4`) or `null` for your default.
- `split` should run `command` (an argv array, quote it for the shell yourself) in the new pane, in the caller's `cwd`.
- `getCurrentPane` receives the caller's `tty`, but the caller may be under a nested pty (a multiplexer, a coding agent wrapper) that no pane owns. When no pane matches the tty, walk the ancestors of `caller.pid` and return the pane whose tty appears first in that chain.
- `listPanes` entries carry the pane's `tty` and the command line of its foreground process, or `null` when unknown.
- `pasteKey` must deliver a literal ctrl+v keypress (byte `0x16`), not a bracketed paste, so a coding agent treats it as a key and reads the clipboard.
The client side, including the exact schema terminal-browser accepts for every result, is [shared/src/terminal-socket.ts](shared/src/terminal-socket.ts). A minimal terminal written in node that answers every method is the `fakeTerminal` in [shared/test/terminal-socket.test.js](shared/test/terminal-socket.test.js), which is a good starting point.
#### Built in support
If a terminal does not implement this API itself, terminal-browser ships built in implementations located in [pixel/packages/pixel/src/terminal/terminals](pixel/packages/pixel/src/terminal/terminals) for: ghostty, kitty, wezterm, cmux, tmux, vscode, tty7, herdr, and supacode. These implement the same operations as the socket methods above as the `Terminal` interface in [pixel/packages/pixel/src/terminal/terminal.ts](pixel/packages/pixel/src/terminal/terminal.ts), using each terminal's own scripting cli. To add support for another terminal or multiplexer, add a file there that implements `Terminal` and register it in `terminals/index.ts`.
### [Discord](https://discord.gg/t3jzHHfc6z)
### Acknowledgments
- the [kitty](https://github.com/kovidgoyal/kitty) project for developing the kitty graphics protocol
- [awrit](https://github.com/chase/awrit) - the first attempt to embed chromium inside a terminal