Agents from every major vendor.
One client, each sandboxed.

Both give you a shell; neither gives you a session that survives. Quit your terminal mid-exec and the process dies with the connection. Here the session lives in the container, so closing the app closes a WebSocket and nothing else — the next launch re-attaches from the byte where output stopped and restores the same split layout. The deployment model differs too: no kubeconfig on the client, no port-forward, and a credential that authorises one session rather than your whole cluster.

herdr is an agent multiplexer — tmux for coding agents. It gives each agent a real PTY, keeps them alive across disconnects, classifies every pane as working, blocked or idle, and exposes a CLI and a socket API. The persistence and the fleet view overlap with this app almost exactly. What differs is where the agents run: herdr runs them on the machine you invoke it on, sharing your user, your filesystem and your credentials. Here each session is its own container in your cluster — uid 1000, no sudo, no host credentials, read-only root, ephemeral workspace — reached over a WireGuard tailnet with no port exposed. The difference is sandboxing, not multiplexing. herdr also does things this does not: pane state classification, a scriptable local API, and running with no infrastructure at all. If you want nothing to deploy, herdr is the better answer.

An agent on your Mac runs as you. It can reach your SSH keys, your cloud credentials, your npm and GitHub tokens, and every repository on the disk — so a wrong command is a wrong command on your machine. Here the shell has none of that, the workspace is discarded with the session, and several agents can work at once without competing for the same working tree or the same ports. Your laptop can sleep or close without stopping anything. The cost is real: the agent cannot see your local files, so work arrives by git; the first pull of an image takes a few minutes; and you need a cluster or an AWS account. For a quick edit in a repo you already have open, running locally is simpler and this adds nothing.

Deliberately little. It opens as uid 1000 with no sudo, no service-account token and no host credentials, on a read-only root filesystem with an ephemeral workspace. A session shell can reach the runtime over loopback, which is why the admin credential is never inside the container: an attach token authorises exactly one session and expires.

No. The runtime binds 127.0.0.1 and holds no TLS key. A Tailscale sidecar in the same pod is the only thing with a network identity, and the two talk over loopback inside the pod's network namespace. Traffic reaches you over the WireGuard tailnet, which is what carries the encryption.

Nothing. There is no service here — every server the app talks to is one you deployed, in your own cluster or your own AWS account. No account, no sign-up, no analytics, no telemetry. Credentials you supply stay in the macOS Keychain and go nowhere except your own runtime.

Yes. The runtime is MIT licensed at openabdev/openab-pty, and the client contract is published, so you can write your own client instead of using this one. This app is one implementation of that contract and is not open source.

Yes. Demo Mode in the app menu runs two sample connections and a recorded terminal with no network connection of any kind. It exists so the app can be evaluated before you deploy anything.

Three clicks, then eight steps: a credential is minted into your Keychain, the namespace is ensured, the secret and volume are created, the pod is applied, and the app waits for it to run, waits for it to join your tailnet, and verifies the admin plane. No manifests to write. The first deploy of an image can take a couple of minutes because the cluster is pulling it.

Teardown is best-effort, and the app says so wherever it matters. Only the first kill domain is implemented, so a process that leaves its process group may outlive its session until the pod or task is replaced. The workspace is ephemeral: deleting the session discards it.