Emdash is an open-source and provider-agnostic desktop app that lets you run multiple coding agents in parallel, each isolated in its own git worktree, either locally or over SSH on a remote machine. We call it an Agentic Development Environment (ADE).
You can see a 1 minute demo here: https://youtu.be/X31nK-zlzKo
We are building Emdash for ourselves. While working on a cap-table management application (think Stripe Atlas + Pulley), we found our development workflow to be messy: lots of terminals, lots of branches, and too much time spent waiting on Codex.
Emdash puts the terminal at the center and makes it easy to run multiple agents at once. Each agent runs as a task in its own git worktree. You can start one or a few agents on the same problem, test, and review.
Emdash works over SSH so you can run agents where your code lives and keep the parallel workflow. You can assign tickets to agents, edit files manually, and review changes.
We also spent time making task startup fast. Each task can be created in a worktree, and creating worktrees on demand was taking 5s+ in some cases. We now keep a small reserve of worktrees in the background and let a new task claim one instantly. That brought task start time down to ~500–1000ms depending on the provider. We also spawn the shell directly and avoid loading the shell environments on startup.
We believe using the providers’ native CLIs is the right approach. It gives you the full capabilities of each agent, always. If a provider starts supporting plan mode, we don't have to add that first.
We support 21 coding agent CLIs today, including Claude Code, Codex, Gemini, Droid, Amp, Codebuff, and more. We auto-detect what you have installed and we’re provider-agnostic by design. If there’s a provider you want that we don’t support yet, we can add it. We believe that in the future, some agents will be better suited for task X and others for task Y. Codex, Claude Code, and Gemini all have fans. We want to be agnostic and enable individuals and teams to freely switch between them.
Beyond orchestration, we try to pull most of the development loop into Emdash. You can review diffs, commit, open PRs, see CI/CD checks, and merge directly from Emdash once checks pass. When starting a task, you can pass issues from Linear, GitHub, and Jira to an agent. We also support convenience variables and lifecycle scripts so it’s easy to allocate ports and test changes.
Emdash is fully open-source and MIT-licensed.
Download for macOS, Linux or Windows (as of yesterday !), or install via Homebrew: brew install --cask emdash.
We’d love your feedback. How does your coding agent development setup look like, especially when working with multiple agents? We would want to learn more about it. Check out our repository here: https://github.com/generalaction/emdash
We’ll be around in the comments — thanks!
if agents continue to get better with RL, what is future proof about this environment or UI?
I think we all know that managing 5-10 agents ... is not pretty. Are we really landing good PRs with 100% cognitive focus from 5-10 agents? Chances are, I'm making mistakes (and I assume other humans are too)? Why not 1 agent managing 5-10 agents for you? And so on?
Most of the development loop is in bash ... so as long as agents get better at using bash (amongst other things), what happens to this in 6 months?
I don't think this is operating at a higher-level of abstraction if agents themselves can coordinate agents across worktrees, etc.
CLIs like claude code equally improve over time. tmux helps running remote sessions like there were local.
Why should we invest long time into your „ADE“, really?
> see their status and review / test their work
Won’t that be addressed eventually by the CLIs themselves?
Maybe you’re betting on being purchased by one of the agentic coding providers given your tool has long term value on its own?
That way I can access it from my browser.
If they have another tag, the agent in the server creates a PR considering the whole issue conversation as context (with the idea that you used the plan above - but technically you don't have to.)
If you comment in the PR the agent start again loading your comment as context and trying to address it.
Everything is already in git and GitHub, so it automatically pick up your CI.
It seems simpler, but I am sure I missed something.
In my experience running CLI-based agents, the biggest risk isn't the agent "going rogue" in the sci-fi sense — it's context window drift during long sessions. Agent compacts its history, loses track of which worktree it's in, and starts editing files in the wrong branch. Or worse, running tests against the wrong database.
Git worktrees help with file isolation, but they share the same .git directory and can still interfere with each other during concurrent operations (rebases, reflog contention). Have you run into this with 5+ parallel agents?
The native CLI approach is smart for staying current with provider features, but it does mean you're trusting each provider's sandboxing. Some are better than others. Claude Code's allowlists are reasonably paranoid; others less so.
Nice to see someone building tooling for this workflow rather than trying to replace the terminal entirely.
If gpl is a blocker for users then offer them a paid license with the exceptions they want. But MIT allows a commercial entity to ingest your code, close source it, and commercialize it .
GPL-3 (with the option of custom commercial licenses) seems strictly superior to MIT in this respect. Can you help me understand why this choice is so popular?
How does it compare to [0]Superset?
[0]: https://superset.sh
As I will need to fully handover the task and let the agent(s) essentially one-shot the implementation I need to be way for specific and clear in giving it context and goals, otherwise I’m afraid it will start build code purely by accumulation creating a pile of unmanageable garbage.
Also changes which requires new UI components tend to require more manual adjustments and detailed testing on the UX and general level of polishing of the experience our users expect at this stage.
I’m starting to develop a feeling of tasks that can be done this way and I think those more or less represent 20 to 30% of the tasks in a normal sprint. The other 70% will have diminishing returns if not actually a negative return as I will need to familiarise with the code before being able to instruct AI to improve/fix it.
From your experience building this, what’s your take on:
1. How do your product helps in reducing the project management/requirements gathering for each individual tasks to be completed with a sufficient level of accuracy?
2. Your strong point seems to be in parallelisation, but considering my previous analysis I don’t see how this is a real pain for a small teams. Is this intended to be more of a tool for scale up with a stable product mostly in maintenance/enhancement mode?
3. Are you imagining a way for this tool to implement some kind of automated way of actually e2e test the code of each task?
Agreed. That this evolution pushes much of the work into describing desired outcomes and giving sufficient context.
To your questions:
Emdash helps reduce the setup cost of each environment by allowing you to open an isolated git worktree, copying over env variables and other desired context. And then preserving your conversation per task. That said, you still need to write clear goals and point it in the right direction.
I think it's less about team scale and more about individual throughput. My working mode is that I'm actively working on one or two tasks, switching between them as one runs. Then I have a long list of open tasks in the sidebar that are more explorative, quick reviews, issue creation etc. So for me it's not about one-shotting tasks, but instead about navigating between them easily as they're progressing
Automated e2e testing is tricky, particularly for rendering. I think roborev (https://github.com/roborev-dev/roborev) is moving in the right direction. Generating bug reports synchronously per commit and not just once you create a PR. I also think what https://cursor.com shipped today with computer-use agents testing interfaces is very interesting.
Soon Gemini for Frontend.
---
Also I've loaded 78 tasks and the UI is crawling to a halt
I'm going to look into it soon, but since you might be hanging around here, I'll ask: do I have a quick way of telling the system how to actually creating a worktree efficiently?
Here's my problem: I want to do manual testing for several things, especially frontend related ones. However, every worktree needs its own ports, and specific particularities (e.g. so docker volumes don't collide). `git config --worktree` is supposed to help with this (and I'll be looking at it pretty soon), but it seems very primitive.
Is there a way for me to tell Emdash: "Hey, when you create a new worktree, you need to run this script"?
Thanks in advance and, once again, congrats on building something new, clearly in the direction we are going.
We also inject convenience env vars into every task. For example, $EMDASH_PORT gives each task a unique port, so you can do PORT=$EMDASH_PORT pnpm run dev and never collide on dev servers.
More here https://docs.emdash.sh/project-config -- does that help?
This seems like just what I was looking for — amazing!!
I hope I have the time to test-run it over the coming days.
If this really ups my ante, I'll get the whole team using it at our studio. Looks promising!
Ah, actually after looking at your approach, I see you don't use any agent SDK or --json outputs. You just embed a terminal window. That makes mobile interfaces a non-starter. I can see why you are only focusing on desktop, it makes integrating with more providers easier.
Or do you consider this orthogonal to what emdash attempts to do?
But the standard that will hopefully take over in most mature shops is spec driven development where instead of a team reviewing code, they review a spec which is used to generate tasks and subsequently code to satisfy the spec. Then 2 kanban boards exist. One for writing and submitting specs and another for the agents themselves to implement the approved specs.
Then tried running the Linux version on WSL2 (not ideal because the wayland server on WSL2 is slow) - doesn't work. This 404s: https://github.com/generalaction/emdash/releases/download/v0...
Grabbed the version before and got "PTY unavailable: ... was compiled against a different Node.js version using NODE_MODULE_VERSION 127, this version requires NODE_MODULE_VERSION 123".
Hope you can fix the bugs. I love Conductor on my Mac, but I need something for my WSL2 machine. Ideally Windows which can SSH into WSL2 (for UI speed) or runs on Linux itself. This is very close to what I need if you fix the bugs :).
What security context do they run in?
I made similar experience. Downloaded all sorts of tools, IDE's for the new era of development. Other than claude code in cli and occasional uses of codex (because have free tokens), nothing else stuck. I can just split my terminal effortlessly how many times I want, write/speak to the terminal with any custom request etc. And once someone comes up with a clever idea on top of what claude has today, I reckon they'll add it one way or another within the next weeks.
bayesian curve meme fits here rather well:
- claude code for everything, custom IDE's/tools, claude code for everything.
[0] https://github.com/AutoMaker-Org/automaker [1] https://www.youtube.com/watch?v=3H_t78QcueA&t=382s