Git worktrees.
Shared storage.

A copy-on-write (COW) copy can work well if you already handle Git setup and cleanup yourself. Riftri gives you a repeatable way to create real Git worktrees, reuse a verified base from an exact Git tree, check storage support, and recover interrupted operations. You get those checks every time, without relying on an agent to remember each step.

For a small project or an occasional copy, your existing approach may be enough. Riftri is useful when you create and retire worktrees regularly.

Yes. Git registers each worktree with its own HEAD and index, while repository history is shared. Your usual Git commands, editor, and build tools still work. Riftri handles how the checkout files are stored; ordinary reads and writes go directly through the native filesystem.

Compatible worktrees starting from the same Git tree share the unchanged tracked file data through one immutable base. Edits allocate private storage. Dependencies such as node_modules, build output, caches, and Git metadata still take space. Savings depend on the workload and filesystem; summing directory sizes can count shared blocks more than once. See the measurements and their limits.

Not always. The first worktree needs a base to be built, and cached worktrees still go through integrity and Git checks. Our published APFS experiment used much less additional disk space but took longer to create the worktrees. Expect storage savings on compatible workloads, not a guaranteed speedup.

You can create a worktree with Riftri and point any agent at its directory. For normal Git command interception, run riftri enable in the repository, then launch your agent with riftri exec -- claude(or another command). Tools that call Git through PATH inherit the shim. Tools using their own Git library or an absolute Git path bypass it. See agent setup.

No. riftri enable opts in one repository. Interception also needs an activated shell hook or riftri exec. Even a hook in your shell profile leaves other repositories on ordinary Git, and existing worktrees are not converted. Use riftri shell status to check the scope and riftri disable to opt the repository out. See activation and deactivation.

Optimized worktrees need APFS on macOS, Btrfs or reflink-enabled XFS on Linux, or ReFS on Windows. Linux can also use OverlayFS when mount permissions or Riftri’s explicitly installed helper allow it. Ordinary NTFS is not supported.

Run riftri doctor --destination ../app-auth from your repository first. Some checkout settings are unsupported, and Riftri stops with an explanation instead of silently making a full copy. Keep important work committed or backed up.

Riftri records lifecycle progress in durable journals. riftri repair uses them to recover interrupted operations and preserves changed or ambiguous state for inspection. riftri status shows what is retained.

Use riftri worktree remove <path> for a finished, clean worktree. Its base stays cached for reuse. riftri gc previews unused-base cleanup; only riftri gc --apply deletes eligible bases. Cleanup is explicit, and dirty work is not automatically discarded.

Writes through one worktree’s files stay private; they do not update the shared base or a sibling worktree. That isolation is not a security sandbox. An agent with permission to access another directory can still edit it directly, and Git branches and history belong to the shared repository. Use a container or VM when you need to isolate untrusted code.