Isolated branches

Two agents on one repository used to overwrite each other. Turn isolation on for a conversation and it gets its own branch and its own checkout of the repo: the agent edits, installs and tests in there, and your working copy is never checked out, never stashed and never touched. Five agents can run at once on the same project, each on its own branch.

Isolation is opt-in per conversation. The default stays the main checkout, so if you never reach for it, nothing about a normal session changes.

Arming it in the composer

The control is a chip in the composer, next to the engine and mode pickers, because "should this run on its own branch" is the same kind of decision as "which model". There is no launcher to walk through and no extra step in starting a chat.

Two things follow from where the chip sits:

• Arming cuts the checkout immediately, while you are still typing, and dependency preparation starts there too. Cutting a checkout and preparing a monorepo takes real seconds, and the worst possible place to spend them is between pressing enter and the agent starting. By the time you send, the branch exists.
• The chip locks after your first message and becomes the branch badge. An engine's working directory is fixed when its conversation is created, so a control that still looked editable would be lying to you.

Branch names are always English, even when you write your request in another language, and they follow the convention your repository already uses rather than imposing one, with a namespace per engine so it is obvious where a branch came from. The name is derived from your first message in the background, while the agent is already working, so naming never delays anything. If no model is reachable the branch keeps a neutral English name instead of the session failing.

A parallel agent is not a context-blind one

An isolated checkout lives outside the folder your workspace is bound to. Taken naively, that means an agent working in it resolves to no workspace at all: no memories, no rules, no skills, and every working-directory-bound tool call failing. Isolation would have made Pathrule blind inside its own feature.

So Pathrule resolves an isolated checkout back to the workspace it was cut from. A parallel agent receives exactly the same path-scoped context as an agent in the main checkout, delivered the same way, before its first tool call. Extra checkouts you cut by hand before any of this existed can be adopted, so they stop running without context too.

This is the part that does not come for free with a git command. Isolation is a checkout; keeping the knowledge layer attached to it is the product.

A checkout the agent can actually build in

A fresh checkout carries no installed dependencies and none of your ignored files, so on most real projects an agent would land somewhere it cannot install, build or test. Studio closes that gap, and asks first:

• It reads your lockfile, names the exact command it would run (pnpm install --frozen-lockfile, npm ci, yarn install --immutable, bun install --frozen-lockfile), and lists the ignored files it would copy across, typically .env and .env.local.
• You answer once per project: Skip, Run once, or Always. On Always, later sessions in that project prepare silently. No command is ever run in your repository before one of those two answers.
• Preparation state is visible on the conversation while it happens: preparing, ready, failed, or skipped. A failed preparation keeps the checkout and its output, because that output is the only diagnosis you have.

When the lockfile in the new checkout is byte identical to the one in your main checkout, Studio shares the installed dependency tree instead of installing a second copy, which is instant and saves the several hundred megabytes each session would otherwise cost. The consent line says "shared" out loud, because an install run inside one session is then visible to the others. If sharing is not safe, a dependency bump, a different base branch, or a package manager that already hardlinks from a global store, it installs properly instead.

Skipping is a legitimate answer. The agent can still read and edit; it just cannot install or test, and the conversation says so rather than letting you find out from a confusing failure.

Seeing what the isolated agent did

Isolation without visibility reads as "the agent did nothing". Source Control gains a checkout switcher: pick a checkout and the file status, the per-file diff, staging, commit, the branch menu and push all operate on that one. There is a single changes view rather than a second surface to keep in sync with the first. You can also open a terminal in a checkout or reveal it in Finder.

Watching several at once

Tabs stop working when five agents are running, so the chat splits into panes and each pane carries its own identity: the branch, the engine, and what that session is doing right now. A session waiting on a human gets an accent ring, an icon and a "needs you" label, because with five agents running the bottleneck is always the one blocked on an answer. Colour alone would not carry that.

Panes are deliberately not reordered when a session starts waiting. You built that layout by dragging; moving panes under you is a worse problem than the one it would solve.

Landing the work

This is where isolation stops being a parking space. A landing bar sits under the changes list, and one explicit action takes the branch home.

• Merge into the base, as a squash, a fast-forward, or a merge commit. Squash is offered first: agents produce a lot of small commits, and your history probably does not want all of them.
• Pull request, pushed and opened for you. The agent may draft the title and body from its own work; you edit them and press the button. Draft PRs are one toggle.

Everything here is executed by the desktop, never by the model: Studio runs git and gh, and an engine is never asked to do it instead. That has consequences worth stating.

• A checkout with uncommitted changes is refused with the reason, not merged half way.
• A conflict stops and leaves your working copy untouched, naming the files that conflicted. Pathrule reports a conflict; it does not resolve one for you.
• If gh is missing or not authenticated, the error names the missing tool. There is no silent fallback.
• After a successful merge, Studio asks whether to remove the checkout, and names the disk it is holding. It never deletes silently, and it never leaves gigabytes unmentioned.

Nothing lands automatically. There is no flow in Pathrule that merges an agent's branch without you pressing something.

Lifecycle, disk and privacy

A conversation and a checkout are separate things. Closing a conversation leaves its checkout and its branch alone, because the work in there may still be the thing you care about. Removing a checkout warns you about uncommitted changes with the count, and asks separately whether the branch should go too; by default the branch is kept.

Checkouts live in one predictable place, ~/Pathrule/worktrees by default and configurable, outside your repository. That is deliberate: nested copies of a project would be walked by every file watcher, project scan and index you have, and one folder is what you can exclude from a backup or clear out in a single action.

Housekeeping stays conservative. Studio removes a checkout that was armed and never used, and prunes records whose folder is gone, but a checkout that holds a change is never swept. If a checkout disappears from under a conversation, that conversation reopens on the main checkout and tells you so rather than silently relocating the agent.

Checkout records stay on your machine and are never synced to your teammates. Paths are machine specific, and a preparation command is a shell command: a synced record would let one person's setting run on another person's laptop.

Tasks cards can be isolated too

On the Tasks board, "run in an isolated branch" is a per-run action on a card rather than a board setting, so the default stays the main checkout there as well. A card that ran isolated carries the branch and the base it ran on, and shows them on its face. If cutting the checkout fails, the run continues on the main checkout with the reason reported instead of dying over bookkeeping. Parallel board runs appear in the same checkout list as chat sessions, so there is one place where every extra checkout on the machine is visible.

What isolation does not do

• It does not merge or open a pull request on its own. Landing is always a human action.
• It reports conflicts and stops. There is no conflict resolution UI.
• It is entirely local. Nothing runs in the cloud, and no checkout, path or preparation command is synced.
• It does not translate one engine's permission or sandbox settings into another's. A session in an isolated checkout keeps whatever its own engine's permission model does.
• With the chip off, a conversation behaves exactly as before: your workspace root, no checkout, no branch.

What to read next

• The Tasks board for running a card on its own branch.
• Pathrule Studio for the surfaces around the chat.
• How hooks work for what reaches an agent before its first action, isolated or not.