Your code never leaves your machines. Verify it yourself.

Last reviewed: 30 October 2026

Offsite has no cloud that sees your work. Your agents run on your machines. Your devices mirror them over SSH. This page explains exactly what travels where, and how to check every claim with your own tools.

The architecture, in three sentences

The host runs on your Mac or Linux box. It owns your sessions, your files and all state. The Mac and iPhone apps are thin mirrors that connect over SSH, directly or through an optional relay. There is no Offsite account, no Offsite database with your data, and nothing of ours in the data path that could read your traffic.

Connection paths

Every connection races the available paths and takes the fastest one that works:

• Local network. Direct SSH to your host. Nothing leaves your LAN.
• Your own VPN or Tailscale. Direct SSH through your own tunnel.
• The Offsite relay, optional. A bridge for when no direct path exists. Inside it runs the same SSH session, encrypted end to end between your device and your host. The relay forwards encrypted bytes and cannot decrypt them. Host-key pinning means even a malicious relay cannot impersonate your host. You can switch it off per host, and the connection pill in the app always shows which path you are on.

What leaves your machines, exactly

One honest nuance, because it is the only place where words describing your work leave your machine. A push notification has to be readable text, or your phone could not show it on the lock screen, so it is not encrypted end to end. It carries the name of the session and of its workspace. Agent sessions name themselves after what they are working on, which is what makes the notification useful and also means the name can describe your work. If a project name is sensitive, rename the session yourself, which always wins, or turn notifications off for that device. One more case: when an agent task you asked for finishes (Ask an agent, or a worktree setup), the notification body is the agent’s own one-line summary of the result, cut at 180 characters for Ask an agent and at 512 for a worktree setup, so you can decide from the lock screen whether to look now. The content of your terminal never travels.

A push is also only sent to a device that is not currently connected in the foreground. While the app is open and attached, the same event arrives over your own encrypted connection and no third party is involved.

Keys and authentication

• Every device generates its own ed25519 key on first run. Private keys never leave the device.
• A device connects through Offsite’s own paths only after you authorise it on that host: by pairing with a QR code or an eight-character host code, both single-use and valid for about ten minutes, or by answering one question after you connect with a password or your SSH key.
• Each host keeps its own list of authorised devices. A device revokes its own access from its host menu, and on the host offsite-host relay remove revokes any device. The host refuses the key at once and closes its open connections within seconds. That works while the relay is unreachable, and the relay cannot bring a revoked device back.
• Your host’s SSH key is pinned on first connect. If it changes, Offsite blocks the connection and shows you both fingerprints instead of reconnecting quietly.
• Host state lives in ~/.offsite with owner-only permissions: directories 0700, files 0600.

Agent permissions

Agents run in one of two modes, per session. Auto limits what the agent may change: the CLI’s own sandbox keeps writes inside the workspace, and its approval rules cover the rest. YOLO is full autonomy: the agent can do anything your user can do on that host. We do not soften that sentence, because that is what makes unattended overnight work possible.

In both modes the agent can read what your user can read. That includes the other workspaces on the host and the transcripts of your other sessions, and Offsite hands the agent a tool for exactly that, so one session can see what the others did and carry on from there. A workspace is how you organise work, not a wall between clients. Work for two clients that must not see each other belongs on two hosts, or on two user accounts on one host. Run work you do not trust in auto mode, or on a host that holds nothing else.

The threat model, in plain words

• SSH access to your host means full host access. Offsite does not add a second permission layer behind SSH. Protect the host the way you protect the machine.
• Anyone with your user account on the host can read Offsite’s state directory. That is a property of running on your machine instead of in our cloud.
• An agent session is one of those programs. It can read your other sessions’ transcripts and files on the same host. Separate clients by host or by user account, not by workspace.
• On a Mac, the device key is a file in Offsite’s folder, so programs running under your user can use it too. The dialog that offers the authorisation after a password or SSH-key login says so.
• A compromised relay could drop or delay your connection. It could not read or modify your session, because it never holds keys or plaintext.
• Offsite disappearing does not lock you out. Your sessions are plain tmux plus the official CLIs, on your own machine.

Verify it yourself

Do not take our word for any of this.

• Watch the wire. Run Little Snitch or tcpdump while you work. You will see SSH to your host, our notification function when an event fires, and a version check. Nothing else.
• Check the state permissions. ls -la ~/.offsite
• Read what the host runs. The host is readable Python on your own disk, at ~/.offsite/bin. Open it.
• Compare the pinned host key with your server’s: ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

On our side, every commit runs the host test suite, a fresh install end to end, the Swift tests and a secret scan before a build can be published.

Reporting a vulnerability

Found something? Email hello@offsite.sh with "security" in the subject. We answer fast and we credit finders.