gwm vs lazyworktree vs gwq

People compare tools before they install one. That comparison is going to happen whether or not it happens here, so this page is the version written by someone who read the other two projects rather than guessed at them.

It names where gwm is behind. A comparison page that only lists its author's wins reads as marketing, and the audience for a terminal worktree manager is exactly the audience that will go and check.

the three in one line each

• gwm (Rust, MIT OR Apache-2.0): a CLI and a ratatui TUI in one binary, built on vendored libgit2, aimed at people who script their worktrees as much as they browse them.
• lazyworktree (Go, Apache-2.0): a Bubble Tea TUI with a keyboard-first workflow, aimed at people who live in the interface.
• gwq (Go, Apache-2.0): a fuzzy-finder CLI in the spirit of ghq, aimed at people who want cd $(gwq get feature) and nothing more.

the numbers

Measured 2026-08-12 from the GitHub API. They move, so treat them as a snapshot rather than a standing claim.

	gwm	lazyworktree	gwq
Stars	126	281	461
Language	Rust	Go	Go
Licence	MIT OR Apache-2.0	Apache-2.0	Apache-2.0
First commit	2026-05-18	2025-12-28	2025-05-26
Last push	2026-08-12	2026-08-10	2026-05-02
Interface	CLI + TUI	TUI (plus a CLI surface)	CLI + fuzzy finder

gwq is the star leader and the oldest of the three, and it has not taken a commit since 2026-05-02: its latest release is v0.1.1. lazyworktree ships regularly. gwm is the youngest by seven months.

which one to pick

• You want the smallest thing that works. Take gwq. gwq add -b feature/x, cd $(gwq get x), done. Its surface is a fraction of the other two and that is the feature, as long as its dormancy does not bother you.
• You want to live in a TUI. Take lazyworktree or gwm and try both; this is genuinely down to taste, and the two are closer than their feature lists suggest.
• You want worktrees driven by config and scripts, not only by hand. Take gwm. The per-repo .gwm.toml, the JSON contracts and the daemon exist for the case where a worktree is created by a hook, a CI job or an agent rather than by a keystroke.

where gwm leads

Worktree operations do not shell out to git. gwm links vendored libgit2, so creating, listing, pruning and removing a worktree are library calls. Neither of the other two carries a git binding in its manifest (checked in both go.mod files): they drive the git CLI, which is why lazyworktree documents a Git 2.31+ requirement. gwm shells out for a few things it chooses to (gwm sync, the review diff launcher, the sidebar's git status and git log), and nothing else.

A daemon and a machine contract. gwm daemon is a JSON-RPC 2.0 server over a unix socket (a named pipe on Windows) with a subscribe push stream, and gwm statusline is a dependency-free consumer of it for tmux, starship or a zsh prompt. --format=json on list / doctor / path carries a frozen, version-stamped schema with tests pinning it. Neither of the others has a daemon.

Declarative per-repo bootstrap. .gwm.toml describes what a fresh worktree needs: files to copy across (.env, local certs), regex guards that refuse a copied secret pointing at production, invariants that keep node_modules or vendor from being symlinked between worktrees, and lifecycle commands over six phases. gwm init --preset seeds it for seven stacks. lazyworktree covers the executable half of this with per-worktree .wt hook files; the copies, the guards and the no-symlink invariants have no equivalent in either project.

Undo. gwm undo and gwm history are backed by an operation journal, so a removal is recoverable, from the CLI and from the TUI alike.

A trust gate on config that executes. A .gwm.toml can run commands, and a .gwm.toml arrives with a clone. The first bootstrap in a repo prompts before executing anything, TOFU style, with the decision recorded per repo. Both other projects also run commands out of config; neither gates it.

Multi-repo workspace. gwm --workspace ~/Projects opens one TUI across every repo below a root, with a REPO column and repo-aware creation. gwq covers part of this from the CLI with its global (-g) flag over a configured root.

Bilingual documentation. Every page ships in English and French.

where lazyworktree leads

Rich per-worktree metadata. Description, colour, icon and tags, editable from the interface. gwm deliberately does not have this: it keeps notes as plain Markdown and stops there, on the view that colour and tags are organisation for a permanent list, while a worktree is meant to be short-lived. That is a design opinion, and if you keep fifteen long-running worktrees it is the wrong one for you.

Per-worktree hook files. .wt files live with the worktree, so a hook can be added without touching a shared config. gwm's hooks are all declared centrally in .gwm.toml, which is better for a team convention and worse for a one-off.

A longer track record. Seven more months of use, more than twice the stars, and a docs site with screenshots of every pane. On anything below, lazyworktree has simply had more people run into the corners than gwm has.

where gwq leads

Doing less. No TUI, no config schema to learn, no daemon: a fuzzy finder, a handful of verbs and a status --watch dashboard. If your whole need is jumping between worktrees, the other two are asking you to adopt more than you wanted.

A mature global mode. Managing worktrees across every repo from anywhere was gwq's premise from the start, in the ghq tradition it takes its name from.

The caveat is dormancy: no commit since 2026-05-02, at v0.1.1. That is fine for a tool that is finished, and a real risk if you need a bug fixed.

where all three are level

Roughly at parity, with differences of shape rather than presence:

• tmux and zellij integration
• a command palette
• shell helpers and completions (bash, zsh, fish)
• custom commands bound to keys
• running commands across worktrees

gwm and lazyworktree, additionally:

• an agent sessions pane (Claude, Codex, Copilot)
• running a worktree's commands in a Docker or Podman container
• GitHub and GitLab support, with PR/MR status and CI results
• per-worktree Markdown notes
• creating a worktree from a PR or an issue

Those last five are worth calling out, because until recently they were lazyworktree's lead and this page would have said so. They are parity as of gwm 1.7.0.

corrections

These are two moving projects and this page is written by gwm's author. If something here is out of date or wrong, please open an issue: a comparison that drifts is worse than no comparison, and a correction from the other side is the fastest way to catch it.