What our run establishes
Our run was recorded on 2026-10-09 at commit a5ab29f. In our sandbox, installation succeeded in 15 seconds, the build step succeeded in 22 seconds, and the test step succeeded in 70 seconds.
The harness records each step's success flag, exit code, elapsed time and timeout status. All three recorded exit code 0 without a timeout. This supports a successful command-level check in that environment. It does not establish that we allocated a project pool, ran concurrent coding agents, exercised process termination or tested destructive cleanup separately.
The stored parser summaries report 24 passed, 0 failed and 24 total. Treat those as stored parser summaries, not 24 verified individual tests. The raw output contains package-level results repeated beneath a summary heading, plus an internal/ui package with no test files. That package is not a failure. No new execution or complete-log reconciliation was performed for this correction.
The record contains no audit result, and dependency scan coverage is unknown. It supports no security clearance. MrKeyoor's testing methodology explains how command outcomes and their limits reach the prose; its current page does not establish which methodology revision governed this October run.
Why choose a reusable pool?
Treehouse keeps worktrees available between sessions rather than treating every session as a fresh directory. The project documents preservation of dependencies and build caches, which is the practical reason to consider pooling. We did not measure setup savings, allocation latency or storage savings in a consuming repository.
A normal acquisition opens a subshell. A durable lease instead keeps the allocation reserved without requiring a process to remain inside it. The supplied README says each acquisition receives a random lease identity, and return can require that identity. For automation, retain that identity with the path so a delayed cleanup request can be checked against the allocation it originally received.
Cleanup still requires an operator decision
A non-interactive dirty return aborts without cleaning, and prune will not reclaim that slot. This behavior is documented in both the supplied current README and the README pinned to the measured commit. An unattended caller must handle that outcome rather than assume the directory became available again.
Return can terminate lingering processes and reset the worktree. The documented sequence verifies that foreign processes have stopped before clearing the lease and recycling the slot; a termination or verification failure leaves the worktree and lease in place. These are documented safeguards, not lifecycle behavior independently demonstrated by our command results.
Prune is a dry run unless deletion is explicitly enabled. Ordinary leases exclude slots from later acquisition and pruning, and bulk destroy does not remove them. Those distinctions make leases useful, but they do not replace inspecting the directory before authorizing cleanup.
Base-branch selection is available
The README pinned to a5ab29f documents base_branch configuration and an acquisition override for choosing a base other than the repository default. It also documents creating a new branch at the acquired commit. Issue 67 is closed as completed, with a later comment identifying v3.0.0 as the release addressing it.
Keep the historical release separate from our measurement: the supplied v2.3.0 release page identifies commit 35b8a41, while our attached run identifies a5ab29f. The v2.3.0 release notes cannot establish the exact release version of the measured checkout.
Which alternative fits the job?
Worktrunk addresses worktrees by branch name and supports hooks for local workflow automation. Consider it when branch-oriented navigation is your main requirement. Its supplied README also describes cache sharing, but we have no comparative measurements of either tool's savings or speed.
Branchlet provides an interactive menu for creating, listing and deleting worktrees, plus scriptable commands. Consider it when you want that workflow and configurable file copying or post-create actions. Neither alternative needs to run alongside Treehouse to perform the role described here; they are candidates to replace its worktree-management workflow, not required complements.
How to read the ratings
These are editorial ratings, not benchmark results. The scale runs from 1 for substantial documented obstacles, through 3 for a usable but limited evidence base, to 5 for thorough evidence within the dimension's stated scope. A 2 indicates more obstacles than support; a 4 indicates strong support with a material qualification.
Setup ease is 4 because installation and build succeeded in our sandbox and several installation routes are documented, while other operating systems remain untested here. Documentation is 5 for its explicit treatment of acquisition, leases, return, recovery and destructive operations; this rates the supplied documentation's coverage, not the correctness of every implementation path. Community is 3 because issue 67 shows a public report, maintainer discussion and a completed resolution, while adoption and support responsiveness across the project remain unknown. Maturity is 3 because lifecycle safeguards are documented and command checks succeeded, but this evidence contains no independent production deployment or concurrency exercise.
Start with a disposable repository. Check that your automation retains lease identities, handles dirty returns and leaves unfinished work intact before relying on the pool for valuable tasks.