Mac, web, and iPhone are three equal doors into the same session. Start a run from your desk, your browser, or your phone. Steer it, approve the plan, merge the PR from whichever screen is in front of you. A Mac or an enrolled device does the compute; every surface is a full control surface, and none of them is the "main" one.
The native Mac app, the web app at continuumcode.ai/app, and the iPhone app are peers, not a hub and its remotes. Each one can start a session, steer it mid-turn, approve a plan, and merge a PR.
Compute lives on a Mac or an enrolled device. Everything else is a control surface with equal reach. Open a session on one, pick it up on another - same thread, same branch, same transcript.
Nothing forks, so nothing has to be reconciled. The host owns the agent process and writes the transcript; every other surface subscribes to it. No local copy drifts. Compare a worktree manager like Conductor, where the desk is the only door.
São Paulo · claude fable-5worktree · sp-1Pick a repo, pick a model, type a prompt, send. The session spawns in a worktree on your Mac and starts streaming - plan, diff, terminal, PR, all in one thread. This is the native workbench, and it hosts the compute for the other two surfaces.
Send does real work before the first token appears. Continuum cuts a git worktree so the agent never edits your main checkout, names the run after a city so parallel sessions stay tellable apart, launches the CLI at your model and effort, and takes a rollback checkpoint. The Claude Code worktree guide covers the plain-git version.
Nothing here is Mac-only. The same start flow - repo, model, prompt, send - is one tap away in the browser and on your phone. Your last pick is sticky: the device and repo chips survive a sleeping laptop, a Wi-Fi switch, and a relaunch instead of resetting to whatever host happens to be awake.
Sign in at continuumcode.ai/app on any machine, click New session, pick a repo, type a prompt. The run spawns on your paired Mac or an enrolled device and streams straight into the tab. No download, no local install.
A borrowed laptop, a work desktop, a Linux box with just a browser - all of them are full session starters. The relay between the tab and the host is end-to-end encrypted and can't read a byte.
The browser is a client, never a host. It does not clone your repo, hold your provider keys, or run the agent, which is why a locked-down work machine can drive a run executing on a Mac at home. A different bargain from Claude Code on the web, where your repo has to go to them.
Lisbon · claude fable-5worktree · clawdmeterTap +, pick a repo, dictate or type the prompt, send. The session spawns on your Mac or an enrolled device and streams to the phone in real time - chat, plan, diff, terminal, PR, the whole workbench in your hand.
Start a refactor on the walk to lunch. It's a real session the instant you tap send, waiting for you on every other screen when you get back.
The phone is not a read-only mirror. Session detail carries Chat, Plan, Diff, PR, Terminal, and Files as tabs, so you can read a hunk or merge a PR from a bus seat. Rather finish at your desk? Open on Mac hands the draft over with repo, agent, model, and effort already set.
Most remote-control tools ask the host "anything new?" on a timer. The phone stays seconds behind and the battery pays for the question. Continuum inverts it: the host opens a socket per session and pushes the transcript the moment it changes, coalesced so a fast reply arrives as a handful of frames instead of one per token.
Networks still fail. Elevators, planes, hotel Wi-Fi. So the client is written assuming it will drop.
Each open session gets its own stream off the host. Updates are debounced before they leave, so a long answer lands as a few frames and the radio stays quiet between them.
A dropped socket retries on a widening backoff with jitter. If it keeps refusing - a network that blocks sockets outright - the client drops to ordinary requests so you get updates instead of a frozen screen.
Every write - send, approve, interrupt, merge - carries an idempotency key. A retry replays the receipt instead of re-running the command, so a flaky connection can't merge a PR twice.
The queue is visible, not magic. Anything pending or permanently failed shows up on the session, so you retry or cancel it by hand instead of guessing whether your approval landed. That's what makes it safe to run several agents in parallel.
A session started on any surface keeps running while you move. The host keeps streaming while you're away from it. When the agent needs a call, the notification finds you - a banner with the session's city name and the reason it's waiting. Tap it and the same thread opens, mid-run, wherever you are.
Approve the plan from the train. Kill a runaway turn from the elevator. The session doesn't restart, doesn't fork, doesn't care which screen answered - it's one conversation on many screens.
The banner says why it fired, not just that something happened: which session, which repo, how long the turn ran, what it wants. A plan waiting for approval reads differently from a finished run, so you decide from the lock screen whether it's worth opening. See how plan mode works, then Plan & review.
"Peer" means every surface can start, steer, approve, and ship. It does not mean every surface renders every pane. Here is the actual shape.
The Mac is the reference host, the densest UI, and the only place the Spawn terminal grid lives. Web and the Windows/Linux desktop client render the same dashboard, so fixing one fixes both. iPhone carries the workbench tabs. Watch isn't an IDE: limits, waiting plans, approve, interrupt, voice reply.
Something always has to host. If you have been solving that with Claude Code over SSH and tmux, this is the same idea with a real client on the other end instead of a scrollback buffer. The peer model is agent-agnostic: a Codex session steers from the phone exactly like a Claude one.
every surface starts sessions · the host runs them
Short answers here, long answers in the docs.
Something has to host the compute, but it doesn't have to be a Mac you're sitting at. A Mac or any enrolled device - an old laptop, a Linux box, an EC2 instance, or a serverless burst - hosts the session; the Mac app, the web app, and the iPhone app are all full control surfaces onto whatever is hosting. Start on the phone against an enrolled device and the Mac never needs to be open at all.
Yes. New session, pick a repo, type or dictate a prompt - the full start flow lives on all three surfaces, not just the Mac. The run spawns on your paired host and streams back to whichever surface you started from, and to every other one at the same time.
Yes. Pair once by QR; traffic rides an end-to-end-encrypted relay (XChaCha20-Poly1305 - the relay sees envelope lengths, not contents) or your own Tailscale tailnet if you'd rather have zero third parties in the path. Every remote command is rate-limited and audit-logged on the host.
Yes - it's the same session, live everywhere. Type on the Mac, approve on the phone, watch it stream in the browser, all against one thread and one branch. Whichever screen you touch, you're driving the same run on the same host.
The write is queued locally with an idempotency key and retried on a widening backoff. If it lands twice the host replays the original receipt instead of running the command again, so no double prompt and no double merge. Anything undeliverable is parked and shown to you, never silently dropped.
The run lives on the host, so it stops only if the host stops. Close the laptop you were watching from and nothing changes; close the laptop that is the host and the session pauses with it. That's what enrolled devices and Cloud solve.
Five minutes from download to your first session - started wherever you happen to be.
requires an apple silicon mac or enrolled device to host · web & iphone are first-class