Claude Code Remote Control vs Bernato: One Session vs Every Machine

Anthropic shipped Claude Code Remote Control (/rc) and it's a genuinely useful feature. You're on your laptop, you start a session, and you can drop into the same chat from your phone an hour later. The QR-code handoff is slick. For a lot of people that's exactly enough.

It's also bounded by what it set out to do. The official documentation calls out two limits in plain text:

• "Your terminal must remain open."
• "Your machine must stay online."

Bernato is the answer for the case after that. A small Go daemon (bernatod) on every machine you own — laptop, GPU rig, Mac mini under the TV, homelab box — and one dashboard that talks to all of them. Spawn an agent on the GPU rig from your laptop. Watch it from your phone. Review a permission request from Bernato.

Feature matrix

Where Claude Code Remote Control wins

Zero install. If you already have a Claude Code subscription, you type /rc and you're done. Bernato needs you to download the daemon. Five minutes is still five minutes more than zero.

It's official. Anthropic builds and supports it. Bug reports get fixed. Usage is bounded by your existing plan.

Resume the exact session. Your conversation history, your tools, your project — it's the same Claude Code instance. Bernato spawns new processes; it doesn't fork your existing terminal session.

Where Bernato wins

Fleet view across machines. Three Macs, a GPU rig, and an old NUC running training? One screen, all of them, every running process tagged by host. Remote Control gives you one session at a time.

Survives terminal close. The daemon owns the agent. Quit your terminal, close your laptop, plug in your laptop a day later — the agent is still where you left it (or done with its work and queued in history).

macOS sandboxing available. Every macOS spawn wraps the agent in a Seatbelt profile generated from capability tokens (workspace_rw, network, subprocess). The agent reads/writes the workspace by default; broader reads require explicit read:<path> or read_anywhere grants. Linux supports opt-in bwrap when available; Windows has limited Job Object containment without filesystem/network isolation. Spawn decisions, grants, toggles, and lifecycle incidents land in the local activity log; per-deny Seatbelt ingestion is planned.

Not just Claude Code. Codex, Aider, your own python script that takes 6 hours to scrape, a Playwright run, a Go binary that compiles overnight. Anything that runs in a PTY runs under Bernato.

Spawn, not just resume. "Run codex --auto on the GPU rig with these env vars" from your phone. The phone is not a viewer; it's a spawn point.

When to use both

Use them together. Daily-driver coding session: Claude Code Remote Control on your laptop. Long-running agent that needs to outlive your terminal, or runs on a different box: Bernato spawns it as a supervised process. The two don't conflict — Bernato can spawn claude --print as a non-interactive run, or open a PTY that you attach Claude Code to.

Migration: from "ssh + tmux" to Bernato in 5 minutes

1. Download the daemon from bernato.dev/download.
2. Open the dashboard, sign in with Google, click the tray icon → "Pair this machine."
3. Repeat on every other machine.
4. Replace tmux new-session 'claude' with the dashboard's "Spawn" button. Pick the host, paste the command, hit Run.

The terminal still works (bernatod ctl). Tmux still works. SSH still works. Bernato is additive, not destructive.

Honest tradeoffs

Bernato is younger than Anthropic's feature. The launch is free for 3 paired nodes; paid checkout stays hidden while billing and support are verified. macOS is the primary daemon target today; Linux and Windows builds are preview/manual; Linux supports opt-in bwrap when available, and Windows has limited Job Object containment.

If "single Claude Code session resumed from phone" is the entire job, Remote Control wins on simplicity. The moment that job grows by one machine or one non-Claude process, you've outgrown it.