Helmor: a local-first workbench for running coding agents in parallel

The problem Helmor targets: parallel agents with no shared bookkeeping

Running one coding agent in a terminal is easy. Running five at once is an operations problem. Each agent wants a checkout, a branch, a set of terminals, and a way to show you what it changed. If you point several agents at the same working tree, they overwrite each other's edits and you cannot tell which diff belongs to which task. Helmor's answer is to make the workspace the unit of work: the README describes one git worktree and one branch per task, with the agent's conversation, diffs, editor and terminals attached to that workspace.

The intended user is a developer who already has agent CLI logins and API keys and does not want a hosted service in the middle. The README states that everything lives locally under `~/helmor/`, and that agent CLIs are bundled so there is nothing else to install beyond connecting GitHub or GitLab and signing in to an agent. That is a narrower audience than a general AI coding tool: it assumes you are comfortable with git worktrees and that you want to keep provider credentials on your own machine.

How the worktree-per-task model actually works

The README's flow diagram is short: add a repository, create a workspace, prompt an agent, review and ship, then repeat in parallel. The mechanism behind it is git. A workspace is created as a fresh git worktree and branch under `~/helmor/workspaces/`, so two agents working on the same repository never write to the same files. The repository itself can be a local clone you link or one Helmor clones from a URL.

Because each workspace is a separate directory with its own branch, the review step is a normal git diff rather than an agent-specific transcript. The README describes diffs, a Monaco editor and terminals sitting beside the conversation. Shipping is exposed as actions on the workspace: create a PR or MR, merge, fix CI, resolve conflicts, and stacked PRs, with GitHub and GitLab named as the supported forges. The repository layout is consistent with a desktop application rather than a server: there is a `src-tauri/` directory for the Rust side, a `sidecar/` directory, an `apps/` workspace, and a `vite.config.ts`, and the package manifest runs a Tauri dev command. The CLI works against the same local database as the app, which is why the README says it functions even while the app is running.

Installing Helmor and creating your first workspace

Helmor is distributed as a desktop build. The README points to the GitHub releases page for downloads and lists macOS (Apple Silicon and Intel) and Windows (x64). There is no Linux download in the README, and no package manager install line for the application itself. On first launch you connect GitHub or GitLab and sign in to your first agent; the agent CLIs are bundled.

The CLI is a separate step. The README says to install it from Settings, under Experimental, then Command Line Tool. Once installed, the documented commands operate on repositories and workspaces by name, with `repo-name/directory-name` shorthand:

helmor repo add /path/to/repo
helmor workspace new --repo myapp
helmor workspace list
helmor send --workspace myapp/feature-x "Add a test for the parser edge case."
helmor workspace status myapp/feature-x
helmor workspace run-action myapp/feature-x   # create PR, merge, fix CI, …
helmor mcp                                    # MCP server over stdio

After `helmor workspace new`, you should see a new entry in `helmor workspace list` and a new worktree directory under `~/helmor/workspaces/`. The README's worked example chains the same commands into a single task, from branch creation to the action that opens the PR:

helmor workspace new --repo myapp --name fix-auth
helmor send --workspace myapp/fix-auth "Add tests for the token refresh path."
helmor workspace status myapp/fix-auth
helmor workspace run-action myapp/fix-auth

Every command supports `--json`, which is the practical path to scripting Helmor from another tool. The README also documents `helmor mcp`, an MCP server over stdio, so another agent can drive Helmor rather than the other way around.

If you want to build from source instead, the contributing section gives one line, `bun install && bun run dev`, and points to AGENTS.md for architecture, commands and test layout. The package manifest pins `[email protected]` as the package manager, and the test scripts split into frontend (vitest), sidecar (bun test) and Rust (cargo test) suites.

Where Helmor gets in the way

The worktree model has a cost the README does not discuss: every workspace is a full checkout directory plus a branch. On a large repository with heavy dependencies, that means disk usage and install time multiply with the number of parallel tasks, and nothing in the README describes cleanup or garbage collection of stale workspaces. You are expected to manage that yourself with git.

The mobile companion is labelled experimental in the README and depends on a Cloudflare tunnel to your desktop, so it is not a substitute for a hosted service when your machine is off. The CLI itself is filed under Experimental in Settings, which is worth weighing before you build automation on top of it, even though the command surface looks stable and every command has a `--json` mode.

Platform coverage is the clearest limit. Only macOS and Windows builds are listed, so Linux users have the source route (`bun install && bun run dev`) and nothing else documented. The README also does not document rollback behaviour for workspace actions, so if a merge or a conflict resolution goes wrong, the recovery path is git, not Helmor. And the README's own feature list includes items still to come, such as Slack and GitHub context, plan mode, and agent-driven orchestration, which means some of the orchestration story is aspirational rather than shipped.

Helmor compared with running agents in plain terminals or tmux

The obvious alternative is what most people do already: open a few terminal tabs, or a tmux session, and run each agent in a directory you created by hand with `git worktree add`. The difference is not the isolation, which git already provides, but the review surface. In tmux you switch panes and read raw terminal scrollback; Helmor attaches the diff, a Monaco editor and the PR actions to the same workspace as the conversation, and exposes the same objects through a CLI and an MCP server.

The second alternative is a hosted orchestration service. Helmor's trade-off is the opposite one: state stays under `~/helmor/` on your machine, your agent logins and API keys stay where they are, and there is no server-side workspace to reconcile. The price is that remote access is a tunnel to a desktop that has to be running, and there is no documented team-shared workspace. The third alternative is simply using one agent well. If your work is mostly sequential, the worktree-per-task machinery adds directories and branches you will not use.

Maintenance, licence and what upgrading costs

The repository is not archived, and the last push was on 2026-07-24, which is roughly two months before this writing. Releases are frequent and versioned: v0.46.0 landed on 2026-07-24, v0.45.2 on 2026-07-17, and v0.45.1 on 2026-07-17. The presence of a `.changeset/` directory and a CHANGELOG.md in the repository root indicates a changeset-driven release process, so upgrade notes have a documented home.

Helmor is Apache-2.0, which permits commercial use and modification, and the repository carries a NOTICE file alongside the LICENSE. That is a permissive licence, but it says nothing about the agent CLIs bundled with the app or about the third-party services you connect (GitHub, GitLab, and whichever model providers your agents use). Those carry their own terms, and the README does not enumerate them. Nothing here is legal advice; if you redistribute a modified build, read LICENSE and NOTICE yourself.

Upgrade cost is mostly tied to the desktop app, which uses a Tauri updater: `.env.example` shows `HELMOR_UPDATER_ENDPOINTS` pointing at the releases' `latest.json` and a `HELMOR_UPDATER_PUBKEY` placeholder, and it also shows `HELMOR_GITHUB_CLIENT_ID`, which the file says you can override in `.env.local` to use your own OAuth App. If you build from source, the practical upgrade burden is keeping the Bun toolchain, the Rust side and the sidecar in step, since the test script runs three separate suites.

Editorial conclusion

Adopt Helmor if you already run several coding agents and the bottleneck is bookkeeping rather than model quality: the worktree-per-task model and the `helmor` CLI are the parts worth evaluating first. Skip it if you need Linux builds, a documented headless deployment, or a stable mobile workflow, since the README lists only macOS and Windows downloads and marks the mobile companion experimental. Before committing, install the CLI from Settings, run `helmor workspace new --repo <name>` against a throwaway repository, and confirm that the workspace directory under `~/helmor/workspaces/` and the branch it creates match your existing git conventions.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes