Remote worktrees
A paired runner's worktrees are not in a separate window or a separate mode. They sit in the sidebar under the same repos as your local ones.
In the sidebar
A remote worktree nests under the local repo it belongs to, matched by clone
URL rather than by path — a filesystem path means nothing on another machine,
but origin means the same thing everywhere. Where a runner has a repo you
have not registered locally, its worktrees appear under their own heading
instead of being hidden.
Creating one
The same + you use for a local worktree. When you have runners paired, the
dialog adds a choice of machine: this Mac, or a runner by name.
That choice decides more than where the files land. It decides which filesystem the work happens on and which git credentials it uses — which is why the picker names the machine rather than saying "cloud". A remote worktree is created by the runner cloning the repo itself; no credentials travel from your machine.
Only online runners can be picked. Creating on an offline box would queue nothing and fail at the first request.
One thing to know before you do this: on a runner that has podman or docker installed, a newly created worktree is put in its own container, and its git layout differs from a normal checkout. That happens by itself, with nothing to configure — see sandboxes.
What is different once it is open
Heads up
The VS Code tab and the Browser tab are absent on a remote worktree, and so are the Logs button, the diff, and the changes rail. All of them read local process or git state, so on a runner they would show nothing at all. They are left out rather than shown empty.
The desktop does not infer this from "is it remote". It asks the runner what it supports and hides what the answer does not include — see runners for why that distinction matters.
Two smaller differences worth knowing:
- A remote session's tab is labelled with the runner's name, because where a shell runs changes what it can see.
- Closing a remote tab detaches from the session rather than killing it. The process stays alive on the runner.
Where to go next
- Remote ports — reaching a dev server on the runner
- Runner updates
- Runners