Remote Hosts

How Daintree runs a window's whole backend on another Mac or Linux machine over your own SSH: what runs where, how it connects, the host chip, requirements, a quick start and the limits.

Updated Oct 17, 2026

Reviewed Oct 12, 2026

Run Daintree on Another Machine

A Daintree window can run its whole backend on another Mac or Linux machine. That machine is a host. Its projects, Git worktrees, terminals, agents, plugins and MCP server all live there, and the window on the machine in front of you shows them and takes your keyboard. Everything travels over your own ssh.

The point is to put agents where the compute is. Run a dozen agents on a Mac Studio or a Linux server while you work from a laptop, spread projects across several machines and move between them from one window, or keep long jobs on an always-on box. Close the laptop and the host keeps the terminals and agents running. When you open it again, the window reconnects, the terminals replay what they printed in the meantime (or redraw from the host's screen after a long or busy outage), and anything waiting for review is still there.

A Daintree window running on a host. The toolbar shows the Atlas Ledger project on branch main and, beside it, a bordered pill with a server icon reading SSH · studio-01. The sidebar lists the atlas-ledger worktrees: main with 2 active agents, then dependency-bump, rounding-drift with 1 file changed, reconciliation one commit ahead with 2 files changed, and multi-currency. Two Claude agent panels fill the grid, titled Statement matcher @studio-01 with a working indicator and Rounding audit @studio-01 with a waiting indicator; both show a folder trust prompt for /Users/Shared/Projects/atlas-ledger. — A window on studio-01: the chip and the @studio-01 panel titles say where the work runs

Every page in this section covers one part of it:

Add a Remote Host: the SSH you need, then Settings → Hosts → Add host: find, check, install, enable and advise. Managing, updating and removing hosts.
Switch Between Hosts: the host chip and menu, what a switch opens, new windows, and getting back to this machine.
Continue a Branch on Another Host: bring the project and branch you are on to another machine through Git, cloning it there if needed.
Working on a Host: whose settings apply, agent CLIs, files and images, localhost, notifications, plugins, MCP and who has control.
Hosts Overview and Ports: every machine's load and agents in one dialog, cross-host fleets, and forwarding a host's ports.
Set Up a Mac as a Host: Remote Login, the logged-in session, sleep, and the host's own view of who is connected.
Set Up a Linux Host: headless servers and desktops, the systemd user service, linger and the commands to manage it.

The trust model has its own page, Remote Host Security, and so do the failure modes, Troubleshooting Remote Hosts.

What Runs Where

A window is bound to exactly one host at a time. The interface itself always loads from the machine you are sitting at; everything about the work comes from the host.

On the host	On the machine you sit at
Projects, their files and the project list	The window, its size and the panel sizes
Git, worktrees, branches and remotes	Theme, keybindings and terminal font
Terminals and agent sessions, which keep running when you disconnect	Voice input, privacy and update settings
Installed agent CLIs and their sign-ins	The host list and this machine's own Host mode
Agent settings, environment variables, forge credentials and notification rules	Sound, and how notifications are shown
Plugins and their settings, and the MCP server agents talk to	Plugin views, which render here; a host plugin's view code loads from the host once you allow it

Nothing is synced between machines. Each host signs in to its own agents and forges, keeps its own plugins and its own settings, and a window on that host reads and edits the host's copy. Settings pages say whose value you are changing: Settings on studio-01 on a page that belongs to the host, This Mac (or This machine on Linux) on one that belongs to your machine, and pages with both mark each section. Working on a Host has the full split.

Your Own SSH, No Relay

The Remote Hosts connection uses no relay, cloud service or server run by Daintree. It is the system ssh you already use, so your ~/.ssh/config, your keys, your ssh agent (including 1Password and Secure Enclave keys) and Tailscale SSH all apply. Daintree adds only its own non-interactive and connection-sharing options, and turns agent and X11 forwarding off for its connection.

On the host, Daintree in Host mode listens on a Unix socket that only your user can open. It opens no network port for the link.
Your machine reaches that socket through an ssh connection to the host and forwards it locally. Normally one shared connection per host carries everything, including forwarded dev-server ports.
Daintree runs ssh non-interactively. It never shows a password prompt and never stores a password, so the host must accept your key.

Every copy of Daintree on macOS and Linux can be both: the window you use day to day, and a host for your other machines. There is no separate server build. On a Linux server with no display, the same package runs headless.

Requirements

Your machine: Daintree on macOS or Linux. Windows builds do not include Remote Hosts at all: no host chip, no Hosts settings, no Host mode.
The host: a Mac (Apple silicon or Intel) or a Linux machine on x64. There is no arm64 Linux build yet. A Mac host serves while a user is logged in to it; a Linux host can run with nobody logged in.
SSH with a key: ssh you@the-host 'echo ok' must print ok without asking for anything. A password or passphrase prompt fails the connection.
The same Daintree release on both is the safe default. A different version still connects, best effort, with a warning. Only a different link protocol is refused, and Daintree offers the update.

The Host Chip

Once you have added a host, a small chip appears just right of the project name in the toolbar. In a window on this machine it shows an Apple or Linux mark and This Mac (or This machine on Linux). In a window on a host it becomes a larger bordered pill, like the project pill beside it, with a server icon and SSH · studio-01, so a remote window is never mistaken for a local one. A short word after the name reports trouble: no reply, connecting…, unreachable, can't connect, not connected, or viewing when another machine has control of the project.

Click it for the host menu: every machine, its state, and the ways to move this window, open a new one, or bring your branch along. Option-Shift-Command-H Unavailable on this platform Control-Alt-Shift-H opens the same menu (macOS and Linux only). Switch Between Hosts covers it item by item.

Quick Start

Check that ssh you@the-host 'echo ok' works from this machine without a prompt. On a Mac host, turn on Remote Login first.
Open Settings → Hosts and click Add host. Pick the machine from the list or type its SSH target, then Check host.
Install the matching build if the dialog offers it, then Turn on Host mode, then Add host. See Add a Remote Host.
Click the host chip and choose the host. The window opens the project you last used there, or a list of the host's projects.
To carry the branch you are on across, use Continue this branch on… in the same menu. See Continue a Branch on Another Host.

Tip

A switch never pushes, clones or creates anything. It moves the window to the host as it is. Bringing work across is always the separate, explicit Continue this branch on…, and every push in it is your click.

Remote Hosts and Remote Compute

The names are close and the features are different. Remote Compute attaches an external environment, such as a container or a cloud VM, to one worktree through lifecycle hooks you configure, while Daintree and the agents stay on your machine. Remote Hosts moves Daintree itself: the window's projects, terminals and agents all run on the other machine, which runs its own Daintree.

Limits

Not a sandbox. Agents on a host run as your user on that host, with what that account can reach. Another machine is not an isolation boundary.
One machine has control of a project at a time. Windows on other machines showing it are viewers until they take control. See Who Has Control.
Work moves through Git. Uncommitted changes stay on the machine they were made on; unpushed commits move only if you push them, or send the whole repository as a copy. Files move when you drop, paste or attach them.
Credentials are never copied or synced. Each host signs in to its agents, forges and plugins for itself.
A headless Linux host usually has no keyring, so plugins can't store secrets there. Projects, terminals and agents work as usual.
No Windows clients, no published arm64 Linux package, and no direct WSL connection yet.