Git worktrees

git worktree lets one repo have multiple simultaneous checkouts — each branch checked out in its own directory, sharing the single object database. For humans it’s a niche convenience; for running parallel coding agents it’s the enabling primitive: each agent gets a branch + its own worktree, so nobody stomp’s on anybody’s checkout or index.

The catch, as @banteg puts it: “git worktree ux is horrible.” Two wrappers make it painless:

• git-wt (OSS) — banteg’s tool of choice: a very simple additional git command. git wt feat/name = create branch + check out worktree + cd, in one step (Go, 562★).
• workmux (OSS) — the more opinionated workflow, built for coding agents: spin up a worktree in one command as a tmux window (Rust, 2755★).
• Both can be configured to automatically copy ignored files (.env, local config) into new worktrees — the paper cut that usually kills worktree workflows.

Pattern: this is the multi-agent sibling of the Git hooks distribution problem — the mechanism is local and old, the UX gap only got painful when agents made parallel worktrees the default instead of the edge case.

The productized end: Orca (ADE for agent fleets)

orca (OSS) (86.1k★ MIT TS, Stably AI — “The AI Orchestrator for 100x builders”; the ADE = Agent Development Environment) — worktree-per-agent as a full desktop product: run Codex, Claude Code, OpenCode, Pi side-by-side, each in its own worktree; fan one prompt across five agents in five isolated worktrees, compare results, merge the winner. Beyond the worktree core: mobile companion (monitor/steer from the phone, finish-notifications, follow-ups), SSH worktrees on remote beefy boxes (auto-reconnect, port forwarding — the doombox pattern), Design Mode (click any UI element in an embedded Chromium → HTML+CSS+cropped screenshot straight into the agent prompt), annotate-AI-diffs (comment on any diff line, ship back to the agent — plannotator’s loop, built in), GitHub/Linear native, and an orca CLI so agents drive Orca too (worktree create, snapshot, click, fill). Works with any CLI agent (30+ listed — including Hermes Agent and Pi); subscription-billed agents run under your own accounts with usage/rate-limit tracking and account hot-swap. This is the ceiling the small wrappers (git-wt, workmux) point at: worktree mechanics → fleet orchestration with review surfaces attached.

Related: Agent tests (parallel agents need isolated checkouts) · Diff tools (reviewing what each agent produced) · banteg tweet capture clippings/x-2006041343546777827.md

Worktrunk: the opinionated middle (2026-10-09)

worktrunk.dev + worktrunk (OSS) (max-sixty, 9,087★ Rust — “the most popular git worktree manager”; site + repo captured 2026-10-09): three core commands make worktrees as easy as branches — wt switch feat (create-if-missing + cd), wt remove, wt list with status. The differentiators beyond the wrappers: hooks (create/pre-merge/post-merge automation), LLM commit messages from diffs, one-command merge workflow (squash/rebase/merge/cleanup), interactive picker with streaming CI status + diff/log/PR previews, wt list --full with CI status and AI-generated branch summaries, PR checkout (wt switch pr:123), copy-on-write build-cache sharing (wt step copy-ignored: ten worktrees get target/, node_modules/ without building or copying — APFS/btrfs/XFS reflinks; not ext4), per-worktree dev-server ports via hash_port, aliases + per-branch variables. Ecosystem signal day-one: herdr plugin, stacked-branch sync, pi extension showing agent-busy markers.

Where Hermes sits natively (verified in source, hermes_cli/worktree_ops.py + cli.py): hermes -w = worktree-per-session, fully automated — random hermes-<id> name or --worktree-name, branch hermes/<name>, base = freshly-fetched remote tip (worktree_sync: true default; falls back to local HEAD), .worktrees/ gitignored + .worktreeinclude (the git-wt/workmux “copy ignored files” feature, built in), pid-lock at creation, exit cleanup keeps only trees with unpushed commits, background GC of stale trees (>24h) + pack-health maintenance, and hermes worktree list/prune for attended reclaim of what sessions accumulate. No switch/list/merge UX, no hooks, no CI status — by design: the session is the unit, not the branch.

The verdict for this household (USER question: “check how Hermes natively manages worktrees and what is better for our workflows”): Hermes-native is the better default for our actual pattern — vault/capture work is single-session, the tree exists exactly as long as the session, and cleanup/keeping-unpushed is exactly the right safety semantics; nothing to remember, nothing to prune by hand (hermes worktree prune covers accumulation). Worktrunk earns its install the day a workflow needs named, human-addressed, long-lived parallel branches with CI visibility — its CoW cache sharing doesn’t help here anyway (doombox root is ext4, no reflinks). The gap that would flip the verdict: if Hermes sessions started fanning out 5–10 parallel coding agents on one repo (the Orca lane), we’d want Worktrunk’s wt list --full CI+summary view over hermes worktree list’s age/size audit. Kin: git-wt (minimal), workmux (tmux), Orca (fleet ceiling), Worktrunk (opinionated middle with the agent-era features).