When you build a UI in Claude Code, checking the actual page often means moving between a terminal and a browser. Terminal Browser puts a real graphical browser in a compatible terminal, and its experimental Claude Code plugin can place that view beside the conversation. Project repository.
The useful part is seeing what was built while discussing the change. A successful command is still only one piece of evidence. The page itself needs inspection.
What is happening inside the terminal?
The project renders Chromium pixels through terminal graphics support. It is not a text-only reconstruction of a website. The standalone CLI and the embedded Claude Code plugin have different compatibility requirements. How it works, plugin documentation.
| Environment | What the plugin documentation says |
|---|---|
| Ghostty or Kitty | Supports the required graphics features |
| Supported libghostty derivatives | Listed as compatible options |
| Other terminals | Verify graphics and Unicode-placeholder support |
| Multiplexers | Can rewrite output and break embedded graphics |
The docs specifically distinguish standalone tmux support from the plugin's limitations. Do not assume that a terminal working with the CLI guarantees the embedded view works too.
Install without losing existing settings
The project documents Homebrew as an installation route:
brew install terminal-browser
claude update
In ~/.claude/settings.json, merge the following into the existing env object. Keep your other settings:
{
"env": {
"CLAUDE_CODE_ENABLE_FUNCTION_HOOKS": "1"
}
}
Then add the marketplace and install the plugin:
claude plugin marketplace add zenbu-labs/terminal-browser
claude plugin install terminal-browser@terminal-browser
Inside Claude Code, use /browser. These steps come from the current plugin README, which describes the hooks API as experimental and potentially unstable across releases. Installation.
Preview a real local app
Start your app using its normal development command. Use the actual local URL reported by that command, rather than assuming a port.
The standalone CLI also accepts a URL:
terminal-browser open http://localhost:YOUR_PORT
Replace YOUR_PORT with the number your app reports. This walkthrough is illustrative; it does not claim I installed the plugin on your machine or tested your app through it.
A better inspection prompt
Open the local app at [actual URL].
Inspect the page before making changes.
Check navigation, empty state, a populated state and the main action.
Report what you actually observed, including errors.
Name the smallest fix and the files it needs.
After the fix, repeat the affected flow and show evidence.
Do not submit real purchases, send messages or modify production data.
Viewing the app and giving the agent browser tools are separate parts of the setup. Confirm the available interaction commands rather than assuming that showing a browser automatically grants every action.
Common problems
If the UI becomes garbled, confirm your terminal supports the required graphics protocol. The author documents redraw and mouse-position limitations. Multiplexers can introduce another layer of trouble. Caveats.
Keep a normal browser available while evaluating the plugin. Compare the same page in both views when something looks wrong; that helps separate app bugs from terminal rendering issues.
The creator's 30 September v0.13 post reports lower CPU use. That is a reason to check the new version, not an independently measured improvement from my setup. Creator update.
FAQ
Does this work in every terminal?
No. Check the plugin's compatibility requirements before changing your workflow.
Can I use it without the Claude Code plugin?
The standalone CLI is a separate documented route. The embedded experience needs the plugin and its requirements.
What should I test first?
One small local UI with no sensitive data. Confirm rendering and basic navigation before adding agent-driven interactions.
Sources
Checked 1 October 2026. Experimental setup instructions can change between versions.