---
title: gwm vs lazyworktree vs gwq
description: An honest side-by-side of the three git worktree managers: what each one is built on, where each one leads, and which to pick for your workflow.
---

# 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](https://github.com/kbrdn1/gwm-cli)** (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](https://github.com/chmouel/lazyworktree)** (Go,
  Apache-2.0): a Bubble Tea TUI with a keyboard-first workflow, aimed at
  people who live in the interface.
- **[gwq](https://github.com/d-kuro/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, zellij and herdr 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](https://github.com/kbrdn1/gwm-cli/issues/new/choose): a
comparison that drifts is worse than no comparison, and a correction from the
other side is the fastest way to catch it.