What Subshell is

Subshell is a self-hosted control plane for interactive agent subshells: real CLI coding agents (Claude Code, OpenCode, Codex, Hermes, and pi) running in tmux panes on machines you own.

You create, watch, type into, and terminate those panes from a browser. The product is local-first: the panes live on your hardware, the data lives in a SQLite file you can back up, and the only network it assumes is one you control.

If you have ever left a coding agent running and spent the evening refreshing a terminal over SSH, Subshell changes the shape of that evening. The server keeps the agent's pane alive, not your laptop, so you can close every tab and the work continues. Any other device you open (another laptop, a tablet, or a phone) gets the same pane as a live terminal you can type into. Your laptop, the build box in the closet, and the mini in the office can all host panes at once.

What it gives you

Durable panes

Every subshell is a tmux session on the machine running it, streamed to the browser over a WebSocket with replay on attach. Detach by closing the tab, and reattach from any device. The browser cannot tell whether a pane runs on the control-plane host or on an enrolled remote node, because both stream identically.

Many machines, one control plane

The control plane keeps the UI, the database, the terminal transport, and the decision logic; nodes execute. Commands travel signed, and a node refuses anything that does not verify. Harnesses are plugins: the control plane owns which ones exist, one install at Settings → Plugins arms every node, and detection answers per machine. A node is only ever offered the harnesses actually installed on it.

Other people, when you say so

A subshell is private to its owner by default: invisible, not merely forbidden, to everyone else. The owner can grant view (a read-only live terminal) or edit (type, rename, restart) to specific users or to everyone signed in. Deletes, re-shares, and notifications stay with the owner.

Agents that coordinate

Each subshell boots with a small MCP server wired in. Through it, the agent can message its siblings over end-to-end-encrypted channels (the control plane stores ciphertext it cannot read) and can launch or restart other subshells. One pane can fan work out across the fleet.

On every device

The web UI adapts to the screen you are on: a full grid on a monitor; drawer nav, tab workspaces, and a terminal key bar on a phone. Add to Home Screen makes it a standalone app. The native mobile companion handles what a web page cannot: push notifications when an agent needs attention, badge counts, and lock-screen actions.

The three words

Everything in this documentation follows one naming rule: no word names two things.

Your control-plane host can certainly run agents too, but then it is also a node, and the docs say so. The control-plane host's row in the Nodes list is named by an admin and defaults to "Server". The instance itself has an admin-editable display name shown in the sidebar, so someone running several planes can tell them apart.

What it deliberately is not

Subshell is not a hosted agent service. There is no Subshell cloud: you run the server, and you hold the keys.

Subshell is not internet-grade by design. It assumes a trusted network (a VPN, a tailnet, an SSH tunnel), and its threat model says out loud what that posture does not defend against.

Subshell is not a chat wrapper around one vendor's model. The agents are real CLIs in real panes, with all the escape hatches that implies.

The Security model covers all three boundaries.

Where to go next

New here: Get started takes you from nothing to a running subshell. Evaluating: How it works explains the moving parts, and Supported platforms says whether your machines are in scope. Ready to widen the fleet: Nodes overview is where that begins.

Edit on GitHub