Yes! By default, every new task runs in its own worktree. In the .emdash.json config (or in the UI on your project page), you can specify setup, run, and teardown scripts -- pnpm install, pnpm run dev, etc.

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?

THANK YOU!!

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!

Sounds amazing! Let us know if there are any issues or what we can do better!

Thanks! What tools have you been experimenting with?

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.

We could! Do you use them?

Yes !

We connect to remote servers via SSH, are provider-agnostic, and open-source. e.g. in Codex you can only run OpenAI models and not Gemini, Amp, you name it. Give it a spin :)

On it! Released windows out of beta yesterday. signed version sometime this week

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/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 :).

Thank you for flagging! We had a CI bug in v0.4.16 that caused the compilation error that we patched in the latest release (v0.4.17). I created a ticket for the provider detection on remote servers. On it!

looking into this! Thanks for flagging

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.

(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

Thank you, and yes!

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!

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 :)

> 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?

People use UIs for git despite it working so well in the terminal... Many people I knew at uni doing computer science wouldn’t even know what tmux is. I would bet that the demand for these types of UIs is going to be a lot bigger than the demand for CLI tools like Claude Code. People already rave about cowork and the new codex UI. This falls into the same category.

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.