Run agents and terminals on the machine where the code lives.

What runs remote today — and what doesn’t

The remote boundary used to be the process. It isn’t anymore. Agent CLIs and terminal PTYs spawn on the remote host and the task works in the repo root there — and the git-shaped features go with it: per-task worktrees are created by the remote daemon, diff review (hunk and line staging, discard, blame, history, update-from-base with its conflict resolver) computes on the host, the repo panel reads the remote repo, and Create PR pushes and files the pull request on the remote host — with the compare-page fallback intact when the GitHub CLI isn’t signed in there. Automations’ open-pr and run-command actions run on the remote machine, global search greps remote roots daemon-side with .gitignore honored, and the repo file tree lists remote directories — both merged into the same views with the host named on each result. The database studio reaches remote databases through the SSH tunnels of the host they’re attached to. Agents survive network drops, and secrets cross per spawn without persisting.

What still does not cross the wire, named here so the boundary is one you read, not one you hit: scoped MCP permissions with Ask approvals don’t reach remote agents — a remote spawn gets its policy environment, but the per-call permission gate and live Ask prompts need the app’s database, which lives on your machine. Automations running headless — flows firing in the keep-running daemon with no app connected — can’t create worktrees or run agents on remote projects; those flows need the app running. And if a remote host is unreachable or its daemon is too old for these ops, you get an honest refusal that says so — the fix is to stop the remote agent and reconnect so it picks up the current build — never a silent wrong answer.

A bootstrap you don’t have to trust blindly

Muster installs its remote daemon itself, and the install is engineered to be safe to repeat: idempotent, version-checked, and verified by checksum and signature before anything runs.

You reach the remote two ways. A loopback socket over an SSH tunnel, or direct TLS with MUSTER-PAIR pinned-certificate pairing. Host-key handling stays strict either way: an unknown key is refused everywhere except one interactive prompt that shows you the fingerprint, and a key that has changed is refused outright.

Secrets visit; they don’t move in

Credentials an agent needs on the remote are forwarded per spawn and never persisted there. The store of record stays on your machine — the OS keychain by default. Nothing about running remotely turns your server into a copy of your keychain.

Authentication is key-based on all three platforms. Password authentication works on macOS and Linux, and is refused up-front on Windows rather than failing mid-connect.

Built for connections that drop

A dropped connection doesn’t kill a running agent. Sessions and port forwards carry dead-session detection, so a wedged tunnel flips to reconnecting instead of sitting “live” forever on a dead socket.

The full SSH client underneath

The same host connection gives you the rest of the remote toolbox, in the same window as your agents:

• Interactive terminal sessions
• Dual-pane SFTP/rsync file manager with drag-drop, resume over rsync (3.1+ on both ends) and four-way conflict handling
• Atomic staged uploads — a file stages to a temp path, then swaps; no half-written file on the server
• Local, remote and dynamic port forwards, with live state
• A host monitor: the top-20 CPU processes and disk usage, without leaving the app