Treehouse reuses worktrees instead of recreating environments
A normal Git worktree gives one repository another working directory, which is useful for parallel coding sessions. The annoying part comes after creation: dependencies, generated files, and build caches must often be recreated. Treehouse keeps managed worktrees in a pool and returns a clean existing slot when it can prove that slot is safe. The next agent gets isolation without paying the full environment setup cost again.
The default command acquires a slot and opens a subshell inside it. Exiting triggers process cleanup, verifies that no foreign process remains, resets the worktree, and returns it to the pool. Our checkout was small by developer-tool standards: 89 files, about 17,767 source lines, and 1.1 MB. There is no daemon. Commands coordinate through an atomically written state file protected by a lock.
Durable leases make the pool usable from automation
A subshell lifetime works for a person, but a background agent may have no long-lived parent shell. treehouse get --lease reserves a worktree until an explicit treehouse return. It can emit JSON containing a path, holder label, acquisition time, and random lease identity. Later returns can require the exact identity, preventing an old cleanup retry from releasing a newer allocation of the same slot.
Leased worktrees are excluded from ordinary prune and bulk destroy operations. Treehouse also keeps reservations while acquisition, return, and pruning are running. These protections matter when several agents start together. The 27 packages installed in our Go environment are a modest implementation footprint for that coordination, though every consuming repository may retain far larger dependency and build caches inside its pooled slots.
What happened when we ran it
Our fresh Debian sandbox cloned commit 35b8a41 with 3 CPUs and 8 GB of RAM. Go installed 27 packages in 32 seconds. The build then succeeded in 111 seconds. The repository had 4 CI workflow files, no Dockerfile, and no conventional tests directory. That last signal did not prevent the project from exposing a working Go test command.
Tests completed successfully in 232 seconds. The harness reported 10 passed and 0 failed out of 10. We did not use Treehouse to allocate a real project, launch concurrent agents, terminate lingering processes, corrupt its state, or delete a pool. The passing suite covers the code's own checks in our environment; destructive lifecycle behavior still deserves a disposable-repository exercise before adoption.
Cleanup fails closed unless the operator opts into risk
Treehouse looks for tracked changes, untracked files, running processes, leases, and whether HEAD is merged into the exact reset target. Pruning is a dry run unless --yes is supplied. A normal bulk destroy removes only clean, merged, idle, unleased slots. Dirty, unmerged, in-use, leased, or unverifiable entries require separate include flags, and leased entries cannot be removed through bulk --all.
That caution is the project's best feature. State recovery also errs toward retention: an empty or truncated state file is rebuilt from worktrees on disk, and recovered entries are marked leased until a person verifies them. Still, return operations can terminate processes and reset work. Test the 232-second suite result alongside a throwaway pool containing untracked files, an unmerged commit, and a stubborn child process so your team sees the prompts and exit codes before valuable work is involved.
Default-branch assumptions limit some team workflows
Pooled Git worktrees use detached HEAD and reset to whichever local or remote default branch is further ahead. get fetches origin unless --no-fetch is used. This suits short tasks that begin from main and later create their own branch. It is awkward for release trains or stacked work where acquisition must begin from a named integration branch. Issues 67 and 58 request configuration for that base.
Status also does not yet show each pool slot's checked-out branch according to issue 74. Issue 64 reports that stalled Git operations can leave get waiting without a timeout or diagnostic. These limitations are specific enough to test: disconnect the remote, use a slow credential helper, and confirm how your orchestration handles a command that does not return. The clean 10-of-10 test result does not simulate your network or repository conventions.
Shell and operating-system behavior still has edges
Treehouse installs through Unix and PowerShell scripts, Nix, Go, or source. It supports macOS, Linux, and Windows, but open issue 73 says the built-in updater cannot replace its running executable on Windows. Issue 61 says a spawned zsh does not load expected user initialization files. Issue 72 reports a non-TTY return path that can leave a pool slot dirty and unavailable for reuse.
The new Jujutsu backend in v2.3.0 is explicitly experimental. Existing slots retain the backend with which they were created, and changing configuration does not convert them. Markerless slots are treated as damaged rather than recycled. This is sensible behavior, but jj users should expect a smaller production history than Git users and keep their first pool disposable.
August activity supports a trial, not blind cleanup
GitHub recorded 1,468 stars, 21 combined issues and pull requests, and a last push on August 25, 2026. Release v2.3.0 was published three days earlier. It added the Jujutsu backend and fixed reuse of slots containing unlanded work plus cleanup ordering after forcefully stopped processes. Those changes go directly to the tool's main risk: recycling the wrong directory.
Treehouse solves a real problem for parallel agents, and our 32-second install, 111-second build, and 232-second clean test run make it easy to evaluate. Start with one expendable repository, use leases for automation, retain lease identities, and inspect every prune preview. If the team needs arbitrary base branches or unattended non-TTY returns today, reproduce the relevant open reports before trusting the pool.