411 files turn Git worktrees into agent workspaces
Workmux wraps a clear unit of work: one branch, one Git worktree, and one terminal-multiplexer window. Its 411-file checkout contains about 108,438 source lines because it also manages pane layouts, agent prompts, status hooks, a dashboard, a sidebar, merge cleanup, and sandboxes. workmux add feature-name creates the branch and worktree, copies or links configured files, runs setup hooks, opens the window, and starts the chosen commands. The default stays understandable because Git and tmux remain visible.
The 17.6 MB repository supports tmux first, with experimental WezTerm, Kitty, and Zellij backends. Project config defines panes, while global settings supply personal defaults. A nearer .workmux.yaml can override them in a monorepo. Prompts can enter known agent commands, be written for an editor plugin, or create several worktrees for competing implementations. Workmux coordinates the processes and leaves code judgment to the user.
The 100-second source build is optional for ordinary use
Homebrew, release binaries, Nix, mise, and Cargo are documented installation paths. Building from source took 100 seconds in our sandbox, so a packaged binary is the practical first route. Runtime requires Git 2.5 or newer and a supported multiplexer. Tmux is the only backend with session mode, where each worktree receives its own session and may contain several windows. Agent commands bring their own logins and subscriptions. Automatic branch naming can use an installed agent or an external llm command.
Our install resolved 258 packages in 25 seconds. The source tree includes backend-specific container recipes and a workflow for sandbox images, although the lab's conventional-file scan reported no plain Dockerfile. Normal setup can stay small, but useful projects often need file operations and hooks. A clean worktree lacks .env, node_modules, caches, and editor state because Git ignores them. Workmux can copy or symlink those paths and run post_create, pre_merge, or pre_remove commands in the worktree.
What happened when we ran it
Our sandbox installed workmux in 25 seconds, pulled 258 packages, and built commit 1731c66 in 100 seconds. Cargo then completed in 40 seconds with 3,144 tests passed and 0 failed out of 3,144. The run used 3 CPUs, 12 GB of RAM, a fresh unprivileged Debian container, and no secrets. Nothing failed, timed out, or left an uncertain result in the supplied log. That makes source installation credible even though compiling it is slower than fetching a binary.
The checkout held 411 files, roughly 108,438 source lines, and 17.6 MB before dependencies. It had 6 CI workflows, a tests directory, and no conventional root Dockerfile. The 3,144-test result covers the measured Rust commit. User tmux settings, shell startup, Git hooks, agent CLIs, container engines, and project hooks remain outside that result. The README addresses those boundaries with dry runs, explicit parent sessions, path rules, and backend notes.
Merge removes 3 resources unless you choose to keep them
workmux merge can merge the branch, close its multiplexer window, remove the worktree, and delete the local branch. Three resources disappear after the Git merge: the window, worktree, and branch. The command refuses uncommitted changes by default, runs a configured pre-merge hook, and supports merge, rebase, or squash strategies. A keep flag and merge_keep setting preserve the environment. This convenience deserves the same pause as any cleanup command: inspect the branch and target before running it.
The 3,144 passing tests give that lifecycle code useful credibility, and workmux add --dry-run previews the path, base, multiplexer target, file operations, and hooks before creation. Worktrees still share Git history. Two agents editing the same area can produce ordinary merge conflicts, while branches with different dependency versions should not share node_modules. Rust worktrees should use sccache instead of a shared target directory because Cargo locking would serialize the builds. The tool reduces setup repetition; it cannot remove dependency and merge semantics.
Parallel services still compete for ports and credentials
The README's monorepo example assigns each worktree distinct ports because copied .env files otherwise make several servers bind the same addresses. That detail matters more than the 108,438 lines of tool code: parallel agents are only useful when their applications can run side by side. Hooks receive the worktree path and handle, so a project can generate a per-worktree environment file. File copies may include secrets, and symlinked permission files can share agent approvals across worktrees, so configuration review belongs in onboarding.
Sandbox mode can place agents in Docker, Podman, Apple Container, or a Lima VM. Containers are ephemeral and can restrict outbound domains; Lima is persistent and has unrestricted networking. Both can proxy selected host commands, mount extra paths, and share agent credentials. Those escape hatches are intentional capabilities, so the sandbox boundary is only as narrow as its configuration. The repository had 6 CI workflows and 3,144 passing tests, but a team should still test mounts, network policy, and host-command rules with disposable credentials.
Version 0.1.250 is active, with restore and capture gaps
Version 0.1.250 was released on August 30, 2026, and the repository was pushed the next day. Its changelog fixes pane-less status updates sent to the wrong tmux pane. Some alarming open tickets, including active-pane deletion, were fixed in later versions, so issue state alone misleads. Two gaps lack a later changelog fix: issue 238 covers lost identity after tmux-resurrect restores a window, and issue 246 asks for agent output that survives pane exit.
GitHub listed 2,340 stars and 43 combined open issues and pull requests, split into 29 issues and 14 pull requests. Open issue 261 also reports that workmux send can leave text unsubmitted in an active Codex pane on version 0.1.248; the latest release notes do not mention that path. Workmux is a good fit for an experienced tmux user who wants parallel agents without moving to a separate GUI. Multi-repository tasks, Jujutsu, durable result collection, and restored-window adoption remain reasons to choose a narrower alternative.