workmux
Git worktrees + tmux windows
Giga opinionated zero-friction workflow tool that orchestrates git worktrees and tmux windows to create isolated development environments.
Perfect for running multiple AI agents in parallel without conflict.
Philosophy
- One worktree, one tmux window: Each git worktree gets its own dedicated, pre-configured tmux window
- Frictionless: Multi-step workflows reduced to simple commands
- Configuration as code: Define your tmux layout and setup steps in
.workmux.yaml
Features
- Create git worktrees with matching tmux windows in a single command (
add) - Automatically set up your preferred pane layout (editor, shell, watchers, etc.)
- Run post-creation hooks (install dependencies, setup database, etc.)
- Copy or symlink configuration files (
.env,node_modules) into new worktrees - Merge branches and clean up everything (worktree, tmux window, branches) in
one command (
merge) - List all worktrees with their tmux and merge status
- Bootstrap projects with an initial configuration file (
init) - Dynamic shell completions for branch names
Installation
Quick start
- Initialize configuration (optional):
This creates a .workmux.yaml file to customize your workflow (pane layouts,
setup commands, file operations, etc.). workmux works out of the box with
sensible defaults, so this step is optional.
- Create a new worktree and tmux window:
This will:
- Create a git worktree at
<project_root>/../<project_name>__worktrees/new-feature - Create a tmux window named
new-feature - Automatically switch your tmux client to the new window
- When done, merge and clean up:
# Run in the worktree window
Merges your branch into main and cleans up everything (tmux window, worktree, and local branch).
Configuration
workmux uses a two-level configuration system:
- Global (
~/.config/workmux/config.yaml): Personal defaults for all projects - Project (
.workmux.yaml): Project-specific overrides
Project settings override global settings. For post_create and file operation
lists (files.copy, files.symlink), you can use "<global>" to include
global values alongside project-specific ones. Other settings like panes are
replaced entirely when defined in the project config.
Global configuration example
~/.config/workmux/config.yaml:
window_prefix: wm-
panes:
- command: nvim .
focus: true
- command: clear
split: horizontal
post_create:
- mise install
files:
symlink:
- node_modules
Project configuration example
.workmux.yaml:
post_create:
- '<global>'
- pnpm install
files:
symlink:
- '<global>' # Include global symlinks (node_modules)
- .pnpm-store # Add project-specific symlink
panes:
- command: claude
focus: true
- command: pnpm run dev
split: horizontal
Configuration options
main_branch: Branch to merge into (optional, auto-detected from remote or checks formain/master)worktree_dir: Custom directory for worktrees (absolute or relative to repo root)window_prefix: Prefix for tmux window names (default:wm-)panes: Array of pane configurationscommand: Command to run in the panefocus: Whether this pane should receive focus (default: false)split: How to split from previous pane (horizontalorvertical)
post_create: Commands to run after worktree creation (in the new worktree directory)files: File operations to perform on worktree creationcopy: List of glob patterns for files to copysymlink: List of glob patterns for files/directories to symlink
Default behavior:
- Worktrees are created in
<project>__worktreesas a sibling directory to your project by default - If no
panesconfiguration is defined, workmux provides sensible defaults:- For projects with a
CLAUDE.mdfile: Opensclaudein the first pane - For all other projects: Opens your default shell (
$SHELL) - Both configurations include a second pane split horizontally
- For projects with a
Shell alias (recommended)
For faster typing, alias workmux to wm:
Commands
add- Create a new worktree and tmux windowmerge- Merge a branch and clean up everythingremove- Remove a worktree without merginglist- List all worktrees with statusinit- Generate configuration fileopen- Open a tmux window for an existing worktreeclaude prune- Clean up stale Claude Code entriescompletions- Generate shell completions
workmux add <branch-name>
Creates a new git worktree with a matching tmux window and switches you to it immediately. If the branch doesn't exist, it will be created automatically.
<branch-name>: Name of the branch to create or switch to.
What happens:
- Creates a git worktree at
<project_root>/../<project_name>__worktrees/<branch-name> - Creates a new tmux window named after the branch
- Runs any configured file operations (copy/symlink)
- Executes
post_createcommands if defined in config - Sets up your configured tmux pane layout
- Automatically switches your tmux client to the new window
Examples:
# Create a new branch and worktree
# Use an existing branch
# Branch names with slashes work too
workmux merge [branch-name]
Merges a branch into the main branch and automatically cleans up all associated resources (worktree, tmux window, and local branch).
[branch-name]: Optional name of the branch to merge. If omitted, automatically detects the current branch from the worktree you're in.
Common options:
--ignore-uncommitted: Commit any staged changes before merging without opening an editor--delete-remote,-r: Also delete the remote branch after a successful merge
Merge strategies:
By default, workmux merge performs a standard merge commit. You can customize
the merge behavior with these mutually exclusive flags:
--rebase: Rebase the feature branch onto main before merging (creates a linear history via fast-forward merge). If conflicts occur, you'll need to resolve them manually in the worktree and rungit rebase --continue.--squash: Squash all commits from the feature branch into a single commit on main. You'll be prompted to provide a commit message in your editor.
What happens:
- Determines which branch to merge (specified branch or current branch if omitted)
- Checks for uncommitted changes (errors if found, unless
--ignore-uncommittedis used) - Commits staged changes if present (unless
--ignore-uncommittedis used) - Merges your branch into main using the selected strategy (default: merge commit)
- Deletes the tmux window (including the one you're currently in if you ran this from a worktree)
- Removes the worktree
- Deletes the local branch
Typical workflow:
When you're done working in a worktree, simply run workmux merge from within
that worktree's tmux window. The command will automatically detect which branch
you're on, merge it into main, and close the current window as part of cleanup.
Examples:
# Merge branch from main branch (default: merge commit)
# Merge the current worktree you're in
# (run this from within the worktree's tmux window)
# Rebase onto main before merging for a linear history
# Squash all commits into a single commit
# Merge and also delete the remote branch
workmux remove <branch-name> (alias: rm)
Removes a worktree, tmux window, and branch without merging. Useful for abandoning work or cleaning up experimental branches.
<branch-name>: Name of the branch to remove.
Common options:
--force,-f: Skip confirmation prompt and ignore uncommitted changes--delete-remote,-r: Also delete the remote branch
Examples:
# Remove with confirmation if unmerged
# Use the alias
# Force remove without prompts
# Force remove and delete remote branch
workmux list (alias: ls)
Lists all git worktrees with their tmux window status and merge status.
Examples:
# List all worktrees
Example output:
BRANCH TMUX UNMERGED PATH
------ ---- -------- ----
main - - ~/project
user-auth ✓ - ~/project__worktrees/user-auth
bug-fix ✓ ● ~/project__worktrees/bug-fix
Key:
✓in TMUX column = tmux window exists for this worktree●in UNMERGED column = branch has commits not merged into main-= not applicable
workmux init
Generates .workmux.yaml with example configuration and "<global>"
placeholder usage.
Examples:
workmux open <branch-name>
Opens a new tmux window for a pre-existing git worktree, setting up the configured pane layout and environment. This is useful if you accidentally closed the tmux window for a worktree you are still working on.
<branch-name>: Name of the branch that has an existing worktree.
Common options:
--run-hooks: Re-runs thepost_createcommands (e.g.,pnpm install).--force-files: Re-applies file copy/symlink operations. Useful for restoring a deleted.envfile.
What happens:
- Verifies that a worktree for
<branch-name>exists and a tmux window does not. - Creates a new tmux window named after the branch.
- (If specified) Runs file operations and
post_createhooks. - Sets up your configured tmux pane layout.
- Automatically switches your tmux client to the new window.
Examples:
# Open a window for an existing worktree
# Open and re-run dependency installation
# Open and restore configuration files
workmux claude prune
Removes stale entries from ~/.claude.json that point to deleted worktree
directories. When you run Claude Code in worktrees, it stores configuration in
~/.claude.json. Over time, as worktrees are merged or removed, this file can
accumulate entries for paths that no longer exist.
What happens:
- Scans
~/.claude.jsonfor entries pointing to non-existent directories - Creates a backup at
~/.claude.json.bakbefore making changes - Removes all stale entries
- Reports the number of entries cleaned up
Safety:
- Only removes entries for absolute paths that don't exist
- Creates a backup before modifying the file
- Preserves all valid entries and relative paths
Examples:
# Clean up stale Claude Code entries
Example output:
- Removing: /Users/user/project__worktrees/old-feature
✓ Created backup at ~/.claude.json.bak
✓ Removed 3 stale entries from ~/.claude.json
workmux completions <shell>
Generates shell completion script for the specified shell. Completions provide tab-completion for commands and dynamic branch name suggestions.
<shell>: Shell type:bash,zsh, orfish.
Examples:
# Generate completions for zsh
See the Shell Completions section for installation instructions.
Workflow example
Here's a complete workflow:
# Start a new feature
# Work on your feature...
# (tmux automatically sets up your configured panes and environment)
# When ready, merge and clean up
# Start another feature
# List all active worktrees
Why workmux?
workmux reduces manual setup to a pair of commands and makes it feasible to
run AI-driven development workflows in parallel.
Without workmux
# 1. Manually create the worktree and environment
# ... and other setup steps
# 2. Manually create and configure the tmux window
# ... repeat for every pane in your desired layout
# 3. When done, manually merge and clean everything up
&&
With workmux
# Create the environment
# ... work on the feature ...
# Merge and clean up
The parallel AI workflow (with workmux)
Delegate multiple complex tasks to AI agents and let them work at the same time. This workflow is cumbersome to manage manually.
# Task 1: Refactor the user model (for Agent 1)
# Task 2: Build a new API endpoint (for Agent 2, in parallel)
# ... Command agents work simultaneously in their isolated environments ...
# Merge each task as it's completed
Shell completions
To enable tab completions for commands and branch names, add the following to your shell's configuration file.
For bash, add to your .bashrc:
For zsh, add to your .zshrc:
For fish, add to your config.fish:
|
Requirements
- Rust (for building)
- Git 2.5+ (for worktree support)
- tmux
Inspiration and related tools
workmux is inspired by wtp, an excellent git worktree management tool. While wtp streamlines worktree creation and setup, workmux takes this further by tightly coupling worktrees with tmux window management.
For managing multiple AI agents in parallel, tools like claude-squad and vibe-kanban offer dedicated interfaces, like a TUI or kanban board. workmux takes a different approach: tmux is the interface. If you already live in tmux, you don't need a new app or abstraction layer. With workmux, managing parallel agents is managing tmux windows.