workmux: Parallel Work Without Hiding Git

The branch is only half the workspace

A Git branch separates history, but it does not separate the rest of a developer's working state. A second task may need its own checked-out files, editor, test watcher, environment preparation, and coding-agent conversation. Git worktrees supply additional working directories, while terminal multiplexers preserve sessions. workmux joins those two primitives into one lifecycle: create a worktree, open a matching terminal workspace, arrange its panes, and later merge or remove the task. The upstream documentation describes tmux as the original target and also documents Zellij, Kitty, and WezTerm backends.

That scope is narrower than a new IDE, and that is the point. The tool does not attempt to replace Git or the terminal. Its configuration can copy selected files, link dependencies, run post-creation commands, choose pane layouts, and expose agent state in a dashboard or sidebar. For a developer who already thinks in terminal windows, switching tasks becomes switching workspaces rather than stashing changes and rebuilding context. For someone who does not use a multiplexer, the prerequisites may outweigh the convenience.

A young tool shaped by agent concurrency

workmux's upstream changelog marks v0.1.1 on 5 November 2025 as its initial release. Early entries focus on basic worktree creation, merging, cleanup, global configuration, and pane startup. Within weeks, releases added prompt handoff and multi-agent creation. Later history records dashboards, agent-status hooks, alternative multiplexer backends, sandbox support, pull-request checkout, session restoration, and dry-run previews. The release history makes the progression unusually legible: a small worktree helper expanded as concurrent agent sessions created new coordination problems.

The release cadence is also a warning. A fast-moving pre-1.0 tool can change configuration and behavior quickly. Users should read changes before updating and keep project configuration reviewable. A command that creates directories and windows is convenient; one that also copies secrets, links dependency trees, runs hooks, merges branches, and removes worktrees deserves the same scrutiny as any automation touching source control.

Evidence beyond the feature list

There is public evidence of real use, though it is anecdotal rather than a representative adoption survey. In November 2025, a Hacker News participant said they were already using workmux to combine tmux, worktrees, and command-line agents; another participant in the same thread reported setting it up. The discussion supports actual use but says nothing reliable about the size of the user base.

User-filed issues show more specific workflows. One request described creating temporary worktrees to review GitHub pull requests, then running automated and manual review inside them. Another issue came from a user calling workmux a daily driver and documenting a stale agent-status indicator after a permission prompt, including a locally tested hook change. Those reports are useful precisely because they include friction as well as enthusiasm. The pull-request workflow request and status-hook bug report show the tool being adapted to concrete review and agent-monitoring routines. They do not substitute for a controlled reliability assessment.

Isolation is a workflow property, not a security boundary

A separate worktree prevents two tasks from editing the same checkout, but it does not automatically isolate processes, credentials, network access, or shared services. Two agents can still target the same database, reuse the same environment file, or race on resources outside their directories. workmux documents container and virtual-machine sandbox options, yet safe boundaries still depend on how a project configures them.

Before adopting it broadly, test a deliberately small loop:

• create two disposable tasks and confirm their branches, directories, and terminal targets;
• inspect every file-copy rule and lifecycle hook;
• run the project's tests independently in both worktrees;
• exercise merge and removal with uncommitted changes present;
• verify that secrets and local services are not unintentionally shared.

This is where a companion such as bashka offers a useful contrast. bashka statically reviews fetched shell installers and follows additional script stages, but its own documentation states that Bash's dynamic behavior prevents a guarantee of safety. Static warnings can improve a decision; they cannot turn downloaded code into trusted code. Likewise, workmux can make concurrent state visible and repeatable without making every command inside a workspace safe.

The practical fit

workmux is most compelling for developers who already trust Git worktrees and multiplexers but find their connective tissue repetitive. It creates a consistent place for each task, keeps agent progress observable, and makes cleanup part of the routine. Manual git worktree and tmux commands remain a strong alternative when a team wants fewer abstractions or only occasional concurrency. Graphical agent workspaces may suit people who prefer an integrated review surface.

The honest evaluation is not how many agents fit on screen. It is whether each task remains understandable: which branch it owns, which commands ran, what changed, and what cleanup will do. workmux earns its layer when those answers become clearer without obscuring the underlying Git state.