VibeTunnel: Put a Mac Terminal in Any Browser

The problem VibeTunnel picks, and who has it

The README frames the motivation as a question: checking on AI agents while away, monitoring a long-running build from a phone, or sharing a terminal session with a colleague "without complex SSH setups." That is a narrower problem than remote shell access in general. SSH already solves remote shell access, and it does so with a mature authentication model. What it does not do is hand a colleague a URL, or let you watch a process from a browser tab on a device that has no terminal client installed.

VibeTunnel's answer is to proxy terminals into the browser rather than expose a shell protocol. The stated audience is people running coding agents and long builds on a Mac who want a second screen, not a replacement for a real SSH workflow. The topics on the repository (remote, terminal, vibecoding) match that framing.

It is worth being precise about the shape of the tool, because the README's own wording is specific: the banner says "Turn any browser into your Mac terminal." The macOS app is the recommended path and requires an Apple Silicon Mac (M1 or later); Intel Macs are excluded from the native app. The npm package is the path for Linux servers, Docker containers, and headless macOS systems, and it runs on Node.js 22.12 through 24.x.

How the proxy actually sits between your shell and the browser

The README describes the mechanism in two layers. The first is a server that VibeTunnel starts, reachable at http://localhost:4020, which serves a dashboard listing all terminal sessions. The second is the `vt` command, described as "a bash script that internally calls `vibetunnel fwd` to forward terminal output." So a session is created when you launch a command through `vt`, and the server makes that session visible to any browser pointed at the dashboard.

The `vt` wrapper is not a thin alias. According to the README it also handles shell alias resolution and session title management, which explains why `vt gs` can expand your own `git status` alias and why custom aliases like `vt claude-danger` resolve. The npm installation adds a detection step: when you run `vt` from the npm package, it checks for `/Applications/VibeTunnel.app`, and if that app is present it forwards to the app's `vt` instead of the npm-installed `vibetunnel fwd`. That is a deliberate preference for the native implementation when both are installed.

One detail in the README deserves attention because it affects first-run behaviour. On the first session, a working directory scanner looks for Git repositories, and by default it scans your home directory. That can trigger macOS permission prompts for protected folders such as Desktop, Documents, Downloads, iCloud Drive, or external volumes. The README offers two ways out: navigate to your projects directory before opening a session, or accept the one-time prompts. This is a side effect of discovery, not of the terminal forwarding itself.

Installing VibeTunnel and forwarding your first command

There are two installation routes and they lead to different things. The macOS app is a direct download or a Homebrew cask, and it lives in the menu bar. The npm package gives you the full server with the web UI but no menu bar app. Start with the cask if you are on an Apple Silicon Mac:

brew install --cask vibetunnel

On Linux, in a container, or on a headless Mac, install the npm package globally. The README pins the supported runtime range to Node.js 22.12 through 24.x, so check your `node --version` before installing:

npm install -g vibetunnel

With the Mac app, launch VibeTunnel from the menu bar and click the icon to start the server. With the npm package, the server is started from the CLI. Either way, the dashboard is served on port 4020, and the README's step four is simply to visit it:

# after the server is running
open http://localhost:4020

Now forward something. The `vt` command wraps whatever you give it, so the first real test is a command whose output you would want to watch from elsewhere:

vt pnpm run dev

The README also lists `vt npm test` and `vt python script.py` as examples. What you should see is the command running as it would in your terminal, with a corresponding session appearing in the dashboard at http://localhost:4020. If you want an interactive shell rather than a single command, the README gives `vt --shell`, with `vt -i` as the short form. For watching a branch, `vt follow` follows the current branch, `vt follow main` switches to main and follows it, and `vt unfollow` stops.

Where VibeTunnel is the wrong tool

The README is explicit that Windows is not yet supported, and links to issue #252 for that. If your fleet is Windows, this is not a fit, and no amount of browser access changes that.

The native macOS app requires Apple Silicon. Intel Macs are directed to the npm package, which works on Node.js 22.12 through 24.x, so an Intel Mac is not excluded outright, but the recommended menu bar experience is not available there.

There is a subtler limitation in the model itself. VibeTunnel forwards terminal output from processes you start through `vt` or the app. A session is tied to the server that proxied it. If you need a terminal that persists independently of the host machine, survives the Mac sleeping or rebooting, and reconnects from a different network, that is a job for a multiplexer on a always-on host, not for a proxy whose server is the Mac you are sitting in front of.

The README also documents an authentication section but the excerpt here does not spell out the mechanism. That matters more than usual, because the whole point of the tool is that a browser somewhere else can reach your shell. Anyone exposing port 4020 beyond localhost should read the authentication documentation at docs.vibetunnel.sh before doing so, and should treat the dashboard URL as a credential until they know otherwise.

VibeTunnel compared with plain SSH and with tmux over SSH

The search question "vibe tunnel vs ssh" is the right one to ask, and the difference is architectural rather than cosmetic. SSH gives you a shell protocol with key-based authentication, and the client is a terminal program. VibeTunnel gives you an HTTP dashboard with terminal sessions rendered in a browser, and the client is any browser. The README's own pitch is that this removes SSH keys and port forwarding from the setup.

That trade has two sides. You gain reach: a phone, a tablet, or a colleague's laptop with no terminal client can open the dashboard. You also gain a shared view, which is what makes the "share a terminal session with a colleague" use case work at all. You give up the authentication model you already understand, and you move the trust boundary to a web port.

The closer comparison is tmux over SSH. tmux gives you persistence: the session lives on the server independent of your connection, and you reattach from anywhere. VibeTunnel's sessions are proxied from processes launched through `vt`, so the persistence story depends on the host staying up and the server staying reachable. If your actual requirement is "reattach to a build from a hotel wifi," tmux on a remote box is the more direct answer. If your requirement is "see what my agent is doing without installing anything on this device," VibeTunnel is aimed squarely at that.

Maintenance, licence, and what upgrading costs you

The repository is not archived, and the last push was on 2026-08-05. Recent releases are all pre-1.0: v1.0.0-beta.18 on 2026-07-11, beta.17 on 2026-07-03, and beta.16 on 2026-06-16. The gap between the last release and the last push is worth noting, because it means the main branch has seen work since the most recent tagged beta.

VibeTunnel is MIT licensed. In practical terms that permits commercial use, modification, and redistribution provided the copyright notice and permission notice are preserved. It says nothing about the security of the proxy, and nothing about whether running it on a corporate machine complies with that organisation's policies. That is a question for your own legal and security people, not something a licence file answers.

Upgrade cost is shaped by the beta cadence. With the macOS app, the README advertises automatic updates, so the app tracks releases for you. With the npm package, `npm install -g vibetunnel` is the upgrade path, and you are responsible for running it. The `vt` wrapper's smart detection adds one wrinkle: if you install both the app and the npm package, `vt` prefers the app at `/Applications/VibeTunnel.app`, so a globally installed npm version may not be the one executing. If you are debugging a version mismatch, check which installation `vt` is actually resolving to before you reinstall anything.

Editorial conclusion

Adopt VibeTunnel if you keep long-running agents or builds on an Apple Silicon Mac and want to check them from a phone or a second browser without setting up SSH keys or port forwarding. Skip it if your machines are Windows, if you need a terminal that survives the host going to sleep, or if shared access has to be audited rather than handed out as a URL. Before rolling it out, verify three things on your own hardware: that `vt --shell` opens a session on http://localhost:4020, whether the first-session Git scan triggers macOS permission prompts for your Documents or Desktop folders, and what the authentication section of the README says about who can reach that port once it is exposed beyond localhost.

Frequently asked questions

Official sources

1. amantus-ai/vibetunnel on GitHub
2. License: MIT
3. Project website
4. README
5. Releases