Skip to main content

Remote sessions

The machine you are holding is often not the machine the work lives on. The checkout, the credentials, the CLI you already configured, the connectors you already approved. Those sit on one computer, and you are on the sofa with a phone.

A remote session bridges that. You type the intent on one device, and another device you own runs the whole task in its own environment, streaming back what it does as it does it.

Which device does what​

  • The device you type on chooses the work, shows the transcript as it arrives, answers approval prompts, and can stop the run.
  • The device that runs it does everything else: it picks the tools, runs the commands, uses its own files, sign-ins and working folder, and keeps its own history of what happened.

Nothing is executed on the device you typed on. That matters more than it sounds: a phone never needs your git credentials, and a laptop never runs a command its own approval rules would have refused locally.

Setting it up​

Both devices must be signed in to the same Celeris account.

  1. On the computer that should do the work, open Settings → Remote and turn on remote sessions.
  2. Give it a name under This device's name. That name is how it appears in the picker everywhere else, so make it one you will recognise, such as "work laptop" rather than "MacBook-Pro-3".
  3. On the other device, open the same page and turn it on too. Phones use the Android companion, which is only ever a controller.

Devices find each other through a relay, which is a meeting point and not a place your work runs. If your organisation hosts its own, put its address in Relay URL; leave it blank for the Celeris default.

Running something​

In the composer, use the Run on picker to choose a device, then type the task as usual. Follow-up messages stay on the same device, so a conversation does not drift between machines halfway through.

The picker remembers devices it has seen before. One that is powered off or offline still appears, marked offline with when it was last seen, and cannot be selected until it is back. That beats a device vanishing from the list the moment a laptop lid closes.

Both ends must be on compatible versions. If one is behind, it shows in the picker but will not accept work until it is updated; see Updates & channels.

Approvals across two devices​

Approval prompts appear where you are: on the controlling device. What they are approving is still decided by the device that runs the work, using its rules, not yours.

So the rules do not change. Reads run without asking, writes and sends stop and ask, and anything that cannot be undone or leaves the machine asks every time, exactly as described in Approvals & safety. The only difference is where the question appears.

Stop works the same way. Pressing stop on the controlling device stops the turn on the device actually running it.

Direct access and SSH​

When the relay is unavailable, two devices can still reach each other directly. Direct access pairs a controller to this device over a private HTTPS address or a Tailscale route using a one-time token; the executor still owns its tools, approvals, Stop and audit, and the Workspace relay is preferred again the moment it is back. Managed SSH only starts or reconnects a signed-in headless Celeris over your own SSH agent and strict known-hosts trust; tasks and approvals still run over the relay, and Celeris stores no password or key path.

What is not shared​

A remote session shares intent, the streamed transcript and your approval answers. It does not share files, tokens or command output beyond what the transcript shows, and the relay does not hold your credentials.

Next​