The Git Worktree Trick That Kills Cold Starts

Git worktrees offer a powerful way to manage multiple branches concurrently. They share a single repository's history, but each worktree maintains a separate working directory. This separation is fantastic for parallel development, like when you're juggling several features or deploying multiple AI coding agents.

Here’s the catch: a fresh worktree starts almost empty. Git copies your code, but it intentionally ignores untracked files and directories. This means crucial components like node_modules for JavaScript projects, ..env configuration files, or Rust’s target/ build directory are completely absent.

Consequently, every new worktree demands a full cold install and build process. You must reinstall dependencies, recompile code, and regenerate caches. Imagine running five or ten coding agents, each needing its own .environment.

Each agent then performs its own npm install, cargo build, or other setup. This multiplies the burden: five agents mean five separate installs, five cold builds, and five times the disk space consumed. Before any useful work even begins, you've spent significant time, CPU cycles, and gigabytes of storage just getting things ready.

Worktrunk, an open-source Rust CLI, offers a clever workaround with its wt step copy-ignored command. This utility leverages copy-on-write (CoW), a filesystem feature, to bring selected ignored files into a new worktree almost instantly, without a traditional full copy.

Copy-on-write is a neat trick: files initially share the same underlying disk blocks. When you modify a file in one worktree, the filesystem copies only the changed blocks to a new location. This preserves isolation between worktrees while avoiding the upfront cost of duplicating massive files. It's like having multiple copies that magically only take up space when they actually diverge.

This approach dramatically speeds up setup. The video highlights impressive gains: copying a 14 GB Rust build folder reportedly drops from about two minutes to roughly 20 seconds. Even better, a first build, which might normally take around 68 seconds on a fresh worktree, can fall to just three or four seconds.

These are author-reported results, demonstrating the potential on filesystems that support reflinks, such as macOS APFS or Linux btrfs and XFS. While not a guaranteed outcome for every setup, these figures illustrate the significant cold start reduction CoW can provide, especially when working with large build caches or node_modules directories.

Before expecting instantaneous results, it’s crucial to confirm your system’s capabilities. Copy-on-write (CoW), or reflinks, depends on your filesystem and configuration. Many Macs running APFS and Linux filesystems like btrfs and XFS support this feature, but unsupported setups will fall back to a traditional, slower copy.

Crucially, CoW is distinct from hard links or shared mutable directories. When you modify a file in one worktree, the filesystem duplicates only the changed blocks, ensuring that the other worktree’s file remains untouched. This prevents silent, unexpected changes across your parallel .environments.

To truly understand the impact, you should test Worktrunk’s wt step copy-ignored command on your actual project and drive. Measure both the elapsed time and disk usage. Factors like package managers, build tool caches, and even .worktreeinclude configurations (for granular control over what gets copied) can influence the results.

For example, a 14 GB Rust build folder copied normally takes around two minutes and consumes an additional 14 GB. With reflinks, this can drop to about 20 seconds and virtually zero additional disk space. This dramatically reduces cold build times from approximately 68 seconds to just 3-4 seconds. Learn more about optimizing your Git workflows for parallel AI agents with Worktrunk at Worktrunk — Git worktree management for parallel AI agent workflows. Remember, these numbers are illustrative; your mileage may vary!

Automate wt step copy-ignored by adding it to Worktrunk's lifecycle hooks. This ensures new worktrees automatically inherit useful caches, but use a .worktreeinclude file to specify which ignored paths to copy. For example, include target/ for Rust projects or node_modules/ for JavaScript, but exclude temporary log files.

Select paths deliberately. ..env files often contain secrets and should generally not be copied. Caches and generated artifacts can also be stale or .environment-specific, potentially leading to hard-to-debug issues. Not every ignored file is safe or beneficial to share; choose carefully.

Roll out this optimization cautiously. First, try it on a single worktree. Verify proper isolation and build correctness. Benchmark the new worktree’s cold start against a completely clean setup to confirm the speedup, which can be as dramatic as reducing a 68-second Rust build to 3–4 seconds.

Once validated, automate the copy step for your team’s agent workflow. This ensures consistency and maximizes the benefits of near-instant worktree provisioning, transforming cold starts into warm, productive beginnings.

What does Worktrunk’s copy-ignored command do?

It copies gitignored files from an existing worktree into a new one, using copy-on-write where the filesystem supports it.

Does copy-on-write work on every drive?

No. It depends on filesystem and platform support. APFS, btrfs, and some XFS configurations support reflinks; otherwise, copying may use more time and disk space.

Are .env files safe to copy into another worktree?

Only if the same secrets and configuration are appropriate there. Review what you include and avoid sharing credentials with untrusted projects or agents.

How do I use the command?

Install Worktrunk and run wt step copy-ignored as part of your worktree setup. Check Worktrunk’s documentation for current options and configuration.