Emdash: running parallel coding agents in isolated Git worktrees

What Emdash actually solves for parallel agent work

Running one coding agent is easy. Running three at once on the same repository is not, because two agents editing the same working tree will overwrite each other and you lose the ability to tell which change came from which task. Emdash's answer is Git worktrees. The README states that each task runs in its own worktree and branch, so parallel fixes or features stay separate until you review the diffs and merge what works. That is the whole product thesis, and it is a good one: the isolation is a Git primitive, not a container, so it costs nothing to set up per task. The target user is a developer who already uses CLI agents and wants to fan out. If you run one agent at a time and review its output before starting the next, the worktree machinery buys you little. Emdash is also a desktop app, not a service, so the workflow is tied to a machine you sit at, with remote repositories reachable over SSH.

Worktrees, provider CLIs and lifecycle hooks

Three mechanisms do the work. First, worktrees: each task gets a branch and a directory, and the README describes reviewing diffs, creating pull requests, inspecting CI checks and merging from the app. Second, provider detection: the README says Emdash detects installed provider CLIs automatically and names Claude Code, Codex, Cursor, OpenCode, Amp, Devin, Qwen Code, Droid and GitHub Copilot among supported agents. You bring the CLI and its credentials; Emdash orchestrates. Third, lifecycle hooks. For agents that support hooks, Emdash installs marker-tagged entries in the agent's user-level config. Those entries let Emdash track status, notifications and resumable sessions, and per the README they silently do nothing when the agent runs outside an Emdash session. That last detail matters more than it looks: it means the hooks are designed to be inert outside Emdash, so installing them does not change how you use the CLI directly. The repository is a pnpm and Nx monorepo with apps/ and packages/ directories, and the desktop app lives under apps/emdash-desktop. Local state is a SQLite database, which is consistent with the local-first claim.

Installing Emdash and sending a ticket to an agent

Emdash ships as a desktop build per platform. On macOS the README gives a Homebrew cask; Windows and Linux get installers from the latest release page. The Homebrew path is the shortest:

brew install --cask emdash

On Linux, download the AppImage, DEB or RPM for your architecture from the latest release, for example the x86_64 AppImage, then mark it executable and run it:

chmod +x emdash-x86_64.AppImage
./emdash-x86_64.AppImage

After launch, Emdash scans for provider CLIs you already have installed. The README says detection is automatic, so the first check is whether your agent appears in the provider list; if it does not, the CLI is not on the PATH the app sees. From there the flow is: open or clone a project, create a task, and point the agent at it. Emdash can pull work items from Linear, GitHub, Jira, GitLab, Asana, Featurebase, Monday.com, Forgejo or Plain, so a task can start from a ticket rather than a blank prompt. Each task lands in its own worktree and branch, and you review the diff in the app before merging. If you do not want telemetry, the README gives one environment variable for launch:

TELEMETRY_ENABLED=false

It can also be turned off in Settings. That is the entire documented first-run path; the README does not document a rollback or cleanup command for worktrees.

Worktrees are not a security boundary

The isolation Emdash provides is Git-level, and that is a narrower claim than it sounds. Two agents in separate worktrees still run as your user, on your machine, with access to your filesystem, your SSH keys and any credentials your provider CLI can reach. A worktree stops one agent from clobbering another's branch; it does not stop an agent from running a destructive command outside the repository. If your threat model includes untrusted or unpredictable agent behaviour, Emdash is the wrong layer, and you want a container or VM boundary instead. There is a second, quieter limitation: the README does not document rollback, so undoing a task means Git operations you perform yourself. Third, the parallel model scales in branches, and branches cost review time. Five agents producing five diffs means five reviews, and the app's diff view does not remove that work. Emdash is also not a hosted service, so there is no shared team workspace; app state is local SQLite, and remote work happens over SSH/SFTP with credentials stored in the OS keychain.

Emdash versus plain Git worktrees and a terminal

The honest alternative is doing this yourself. Git worktrees are a built-in command, and a developer can script the same pattern: create a worktree per task, run the agent CLI in each, review with git diff, merge. That approach has no install cost, no desktop app, and no hook entries written into agent configs. What it lacks is the shared surface: Emdash adds a task list, provider detection across nine or more agent CLIs, ticket intake from nine trackers, CI check inspection, and PR creation in one window. Whether that is worth a desktop dependency depends on how many agents you run. For two tasks a week, plain worktrees plus a terminal multiplexer is probably enough. For a dozen concurrent tasks across several providers, the coordination cost of doing it by hand grows, and that is the gap Emdash is selling into. Note that the choice is not exclusive: because Emdash uses ordinary worktrees and ordinary provider CLIs, you can keep using the terminal for tasks that do not need the app.

Licence, maintenance and the upgrade bill

Emdash is licensed under Apache-2.0, which permits commercial and internal use and modification, and requires that you preserve the licence and notices when redistributing. If you fork the app and ship it, you carry the attribution obligations; if you only run it internally, the practical constraint is small. This is not legal advice, and teams with redistribution plans should read LICENSE.md in the repository. On maintenance, the repository is not archived and the last push was on 2026-09-09. The release history shows v1.2.4 on 2026-09-07 alongside canary builds tagged v1.2.4-canary.91 and v1.2.4-canary.92 from the same day, which indicates a release cadence with pre-release channels rather than a single stable track. Building from source is not a casual operation: the root package.json requires Node >=24.0.0 and pnpm >=10.28.0, with pnpm pinned to 10.28.2, and native modules including better-sqlite3, node-pty and sqlite3 are in onlyBuiltDependencies, so installs compile native code. For most users the desktop installer is the upgrade path, and the cost is whatever the provider CLIs charge plus the time to review each branch.

Editorial conclusion

Adopt Emdash if you already run CLI coding agents such as Claude Code or Codex and you want several branches in flight without opening a terminal per task. Skip it if you need OS-level sandboxing, if you want a hosted service, or if your work is a single linear change. Before committing, verify three things: that Emdash detects your agent CLI (the docs list supported providers), that the marker-tagged hook entries it writes into the agent's user-level config are acceptable to you, and that your Git worktree setup handles the number of parallel branches you plan to run.

Frequently asked questions

Official sources

1. generalaction/emdash on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases