[HN Gopher] Show HN: Emdash - Open-source agentic development en...
___________________________________________________________________
Show HN: Emdash - Open-source agentic development environment
Hey HN! We're Arne and Raban, the founders of Emdash
(https://github.com/generalaction/emdash). 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!
Author : onecommit
Score : 73 points
Date : 2026-02-24 18:00 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| das-bikash-dev wrote:
| How does Emdash handle state management when running multiple
| agents on the same codebase? Particularly interested in how you
| prevent conflicts when agents are making concurrent modifications
| to dependencies or config files. Also, does it support custom
| agent wrappers, or do you require the native CLI?
| esafak wrote:
| > Each agent runs as a task in its own git worktree
|
| If you're talking about shared services, that's another matter.
| onecommit wrote:
| Thanks for your questions! You can separate the agents in
| Emdash by running them on separate git worktrees so they can do
| concurrent modifications without interfering. We don't support
| custom agent wrappers currently, interesting. Have you written
| your own? What is your use case for them over native CLIs?
| FiloVenturini wrote:
| Have you considered adding any kind of agent coordination layer,
| e.g. letting one "orchestrator" agent spawn and direct sub-agents
| on specific subtasks, rather than having the developer manually
| assign each task? Or is the explicit human-in-the-loop assignment
| a deliberate design choice to keep control and avoid runaway
| costs?
| onecommit wrote:
| We've considered it! The way we're seeing it, this is something
| that the CLIs themselves are getting good at natively, such as
| Claude Code. We generally consider ourselves to be at a higher
| abstraction / task level, where the individual CLIs are
| responsible themselves for breaking down and distributing a
| larger task across subagents.
| selridge wrote:
| Looks cool! Thank you for sharing.
| thesiti92 wrote:
| i'll have to give it a shot, the market needs an open source
| cursor right now
| onecommit wrote:
| great! send all feedback our way :folded_hands:
| ahmadyan wrote:
| Congrats on the launch
| redrove wrote:
| Is this another VSCode fork? I can't tell from the readme.
| onecommit wrote:
| Not in its purest sense! We're using the monaco editor for file
| editor and diffs, but other than that no VScode included. The
| file editor is really a secondary view inside of Emdash. The
| focus is on the chat with the coding agent. We'll make this
| more clear in the readme. Thanks for the feedback!
| timsuchanek wrote:
| Let's go! Love that this is a solid OSS alternative to what's
| already out there!
| haimau wrote:
| Been driving my agents (CC, currently testing Pi) for a couple of
| weeks via Emdash. Finally, got a productive worktree setup
| working. There were still rough edges when I started, but the
| team has shipping fast [0] and is vaporizing concerns on the fly.
| Building on top of the native CLI seems to be the right strategy
| as well.
|
| [0] https://github.com/generalaction/emdash/releases/
| straydusk wrote:
| Pretty sick. How do you compare yourself with Conductor?
| onecommit wrote:
| Conductor is definitely in the same space. Main points of
| differentiation that I am aware of are that we allow you to
| connect to remote servers via SSH, natively embed many more
| coding agents (21) with their full functionality, and are open-
| source.
| leondri17 wrote:
| LFG!
| mccoyb wrote:
| Here's my question:
|
| 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.
| onecommit wrote:
| Interesting thoughts - thank you! And directionally agree -
| given that agents are becoming ever better, they'll take more
| and more of the orchestration on themselves. Still, we believe
| that developers need an interface to interact with these
| agents; see their status and review / test their work. Emdash
| is our approach for building this interface of the future - the
| ADE :)
| blumomo wrote:
| > Still, we believe that developers need an interface to
| interact with these agents;
|
| 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?
| snowhale wrote:
| the worktree pre-warming detail is interesting -- keeping a
| reserve pool and letting new tasks claim one instantly is the
| same pattern as connection pool pre-warming in databases. the
| underlying bottleneck is probably git having to traverse pack
| files and update the index when you run 'git worktree add'. one
| thing worth trying if you haven't: sparse checkout on the
| worktrees can cut that initialization time further, especially in
| large monorepos where most files are irrelevant to a given agent
| task.
| onecommit wrote:
| interesting! hadn't looked into sparse checkout before, but
| will do now. Initial thoughts are that sparse might be risky if
| we lose some arbitrary files that might be relevant context for
| the coding agents. Will look into this!
| bketelsen wrote:
| this looks great, but can't test, the .deb package is broken with
| an issue about NODE_MODULE_VERSION mismatches. There seems to be
| a PR waiting for approval. Will keep an eye on it.
| onecommit wrote:
| looking into this! Thanks for flagging
| arnestrickmann wrote:
| Hey! We pushed a fix for this. Let us know how it goes!
| ttoinou wrote:
| So, what's your business model ? Is this an YC product, or a tool
| you developed while working on a YC product ?
| onecommit wrote:
| We're figuring our business model out. There're two avenues
| that we principally think about (1) bundled coding agent
| subscription and (2)enterprise version with auth, team
| management, sharing of agent interactions. Admittedly, it's
| early and this can change. What won't change is that this UI
| layer for running multiple coding agents is and will be open-
| source. Emdash itself is funded by YC. Initially developed as a
| tool while working on another product, but we weren't funded
| then.
| ttoinou wrote:
| (2) sounds like a great idea if you can ensure private
| company data never reaches your servers, with features like
| remote controlling agents from a central place
| onecommit wrote:
| Thank you, and yes!
| martinald wrote:
| Please codesign your Windows installer exes :)
| onecommit wrote:
| On it! Released windows out of beta yesterday. signed version
| sometime this week
| martinald wrote:
| Thanks. Btw, doesn't work at all for me. I installed, tried
| to connect to my WSL2 instance on localhost via SSH, which
| worked. Selected a folder and got Claude Code is not
| installed (it is very much installed :)).
|
| 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/d
| ownload/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 :).
| ahmetd wrote:
| very cool!
___________________________________________________________________
(page generated 2026-02-24 23:00 UTC)