max-sixty/worktrunk

Worktrunk is worth a look if you already run several coding agents in parallel on one repository and find raw git worktree plumbing slow. It is a convenience layer over native Git, not a new version-control model.

The problem

A developer wants five coding agents working on five features at once without them editing the same files. Git worktrees solve this by giving each agent its own checkout, but the workflow is awkward: creating one means repeating the branch name in a path, then changing directory manually. Worktrunk keeps the same worktrees but addresses them by branch name, computing paths from a configurable template. The loop becomes creating or switching with one short command, listing the state of every worktree, and merging or removing a branch when finished.

What's different

The design decision is to treat a branch name as the handle and derive the filesystem path from configuration. wt switch --create feature-auth creates the branch and worktree and moves the shell there; wt list shows each worktree's staged changes, commits ahead of main, unpushed commits and age; wt merge main commits, rebases and fast-forwards back locally. Shell integration is what allows a CLI to change your current directory, which is why setup includes installing shell hooks rather than only placing a binary.

The trade-off is coupling to Git conventions and shell behavior. Worktrunk adds conveniences such as hooks and optional LLM-generated commit messages, but it still stores state in ordinary branches and worktrees, so paths and naming are governed by your configured template. Parallel agents remain parallel Git checkouts: each needs its own directory, and understanding what wt list reports still requires reading Git status columns and symbols. The project is also young, so documented commands are the most dependable guide.

Who should try it

Good fit: someone running Claude Code, Codex or similar agents on several branches of the same repo, who wants faster worktree creation and a single overview of in-flight work. The wt merge path also suits developers who merge locally rather than through pull requests. Poor fit: a solo developer who works on one branch at a time, or a team standardized on an IDE's Git integration, will gain little from another CLI layer. If a workflow depends on GitHub or GitLab pull requests, the documented PR path still calls gh or glab between Worktrunk commands.

Requirements and limitations

You need Git with worktree support and one of the documented install routes: Homebrew, Cargo, Winget, Arch's package manager, or Conda/Pixi. Shell integration (wt config shell install) is required for directory-changing commands, so expect to modify shell configuration — on Windows, Winget installs the binary as git-wt to avoid conflicting with Windows Terminal's wt alias. The README offers a workaround: disable the terminal's alias to keep wt.

Hooks for automated setup and LLM commit messages are separate setup steps, and the LLM feature presumably depends on a configured model provider. The repository ships a test suite that needs bash, zsh, fish, nushell and pwsh plus jq if you plan to run integration tests. Ongoing care is ordinary Git hygiene: prune merged branches, keep the path template consistent, and review what a generated commit message contains before pushing.

HotRepo's take

HotRepo recorded 9,454 stars with +31 on 2026-10-24 and 9,457 stars with +31 on 2026-10-25, two daily-board appearances. That is a snapshot, not a trend; persistence cannot be judged from two dates. The project was created on 2025-10-17, so it is about a year old. Before adopting, verify the Claude Code integration and the configured worktree path template against the tools you actually run.