mnzsss/ivar

Multi-repo worktrees for coding agents. One feature across repos, as one unit: one branch, one plan, one pull request per repo, inside the Claude Code, OpenCode or OMP session you already use.
sh
curl -fsSL https://ivar.run/install | sh
Add an avatarUrl field to the user profile: the agent describes it in shared-types, returns it from api and renders it in web, with all three mounted as real git worktrees on the avatar-url branch. Repos you haven't promoted are guarded (kernel-enforced on Linux; see Limitations).
Your harness: Claude Code, OpenCode or OMP, with MCP servers declared once in ivar.json (ivar mcp add figma).
Plan first: /ivar-plan stops for your approval after requirements, analysis and plan.
Code graph: one local SQLite graph of every repo. In a two-repo benchmark, discovery took a median 460k tokens instead of 738k.
On your disk: single Rust binary, Apache-2.0, no account, macOS and Linux. Pull requests go through gh.
Quickstart · Docs · Why not just git worktree?
## The model
ivar is a local Rust CLI built around five small ideas:
1. Hall — a committed directory that declares the repositories a team works
across in ivar.json.
2. Feature — one branch name shared by the repositories participating in one
change.
3. Promotion — the explicit decision to make a repository writable on that
feature. Everything else stays guarded read-only (kernel-enforced on Linux).
4. Session — a view directory opened for you or an agent.
5. View Dir — symlinks to the right real worktrees: feature worktrees for
promoted repositories, and for the rest the feature's base (the parent's worktree, the root's base branch, or the default branch).
text
Hall
api ────────── promoted ──► avatar-url worktree (writable)
web ────────── promoted ──► avatar-url worktree (writable)
shared-types ─ promoted ──► avatar-url worktree (writable)
infra ────────────────────► main worktree (read-only)
Session / View Dir
api · web · shared-types · infra · plans
From the view dir, one agent session describes the field in shared-types,
returns it from api and renders it in web. The plan, branches, and
worktrees remain on disk when the conversation ends.
## Why not just git worktree?
Use git worktree directly when one repository is the problem. ivar uses Git
worktrees underneath, then adds the multi-repository parts:
one committed Hall definition that teammates can clone and ivar sync;
a shared feature branch across the repositories you promote;
read-only guards for repositories outside the feature's write scope;
per-repository setup scripts for untracked runtime state; and
a session view with provider configuration, plans, and durable run receipts.
Read the detailed, candid comparison: Why not just git worktree?.
## Install
sh
curl -fsSL https://ivar.run/install | sh
The installer defaults to zero telemetry, and the installed ivar binary never
sends analytics. Its only unrequested request is the update check: at most once
per 20 hours it asks GitHub for the latest release tag, sending nothing but a
User-Agent (turn it off with IVARNOUPDATECHECK=1). To optionally help
count successful installations:
sh
curl -fsSL https://ivar.run/install | IVARINSTALLANALYTICS=1 sh