Running agents in containers

Point three coding agents at the same repo on your laptop and they start stepping on each other. One runs an install while another is mid-build. One leaves a stray node_modules, a global tool, a half-applied migration. To keep them apart you reach for git worktrees: a checkout per task, a branch per checkout, a mental map of which directory is which. It works until it doesn't. Orb takes a different line: each session can run inside its own container, and the clean starting point is a real bootable environment instead of a checkout dance.

macOS 26 ships Apple's native container runtime, and Orb builds on it directly. A session backed by a container profile is fully isolated: its own filesystem, its own installed tools, its own processes. The agent can rm -rf its heart out and your machine never notices.

The shape of a session

A container-backed session is a single isolated environment that Orb starts once and keeps alive for as long as the session exists. What you see in the dock are two live panes over that one environment, and you flip between them in the header:

• The Claude pane is the agent working, inside the container, in its workspace.
• The Terminal pane is you, in that same filesystem, at the same time.

Both panes are attached into the same running container, so they share one disk. When the agent writes a file, the Terminal pane sees it immediately. You can inspect what it wrote, diff it, or roll a bad change back while the agent keeps its exact place. You are not watching the agent through glass. You are in the room with it, on the same disk, from a second door.

And because the whole thing is a container, nothing the agent does reaches your real Mac. Rolling a change back in the Terminal pane rolls it back inside the container, never in your actual working copy.

Snapshots are the primitive

Here is the part that replaces worktrees. You set a container up once, by hand, until it is exactly the starting point you want: the right tools installed, the repo cloned into the workspace, dependencies already warm. Then you press Save Snapshot, and Orb freezes the entire environment as that profile's baseline.

From then on, a new session on that profile boots straight from the frozen baseline. No install step. No clone. No per-task setup at all.

   configure once            freeze              boot from frozen
┌──────────────────┐    ┌──────────────┐    ┌──────────────────────┐
│ install tools    │ →  │ Save         │ →  │ new session starts    │
│ clone the repo   │    │ Snapshot     │    │ ready, in < a second  │
│ warm the deps    │    │ (baseline)   │    │ no setup, every time  │
└──────────────────┘    └──────────────┘    └──────────────────────┘

That's the difference from a worktree. A worktree gives you a fresh set of files against a shared environment that keeps drifting underneath you. A snapshot gives you the environment too, sealed, so every session starts from the same known-good state instead of from whatever your machine happens to look like today.

Parallelism falls out for free

Once your starting point is a frozen baseline, starting many sessions from it costs almost nothing. Each one is a fresh copy of the same baseline, and the runtime shares the underlying data copy-on-write: every session gets its own writable view that begins byte-identical to the baseline and diverges only where that session writes.

                  ┌─ session 1  (rewrites the router)
   baseline  ───→ ├─ session 2  (rewrites the tests)
   snapshot       └─ session 3  (bisects a bug)
 
   same starting point · three writable copies · zero cross-talk

Three agents, three identical starting points, no way for one to see or corrupt another's work. You launch them from the same profile in the dock and let them run. This is the thing worktrees were always straining to approximate, done properly: real isolation instead of shared directories pretending to be separate.

Credentials never bake into a baseline

A snapshot is made to be reused, and often shared. That makes one thing non-negotiable: a baseline must never carry secrets. So Orb treats credentials as session-local, not part of the frozen image. At the moment you Save Snapshot, Orb removes the credential material before it freezes anything, then verifies its own work: it scans the exact thing that would be frozen and only lets the snapshot proceed once that scan comes back clean. If anything looks off, Orb aborts and keeps your existing baseline rather than risk sealing a secret inside one.

The practical effect: you sign in inside a session to get work done, and that login stays in that session. It does not survive into the baseline that every future session boots from. A shared starting point stays a starting point, never a leaked keychain.

One concept, pointed forward

A container profile and the plain Local profile (which runs on your host, with no container) are the same idea in Orb: a Profile is just "where and how this session runs." You pick it when you create a session. Local for quick work on the real machine, a container profile for isolation and parallel fan-out.

Keeping them unified is deliberate. "Where a session runs" is one seam, and once that seam exists, your host and a local container are simply the first two destinations behind it. A remote or cloud destination is the direction the seam points at: the same session, the same panes, the same snapshot model, just running somewhere other than your laptop. That part isn't shipped, and this post isn't promising it. But the model is built so it's a destination, not a rewrite.

Containers are available today on macOS 26. Set a profile up once, snapshot it, and stop juggling checkouts.