• umairnadeem123 9 minutes ago

    the worktree-per-agent approach is the right call. we run a similar setup with claude code subagents and the biggest lesson was that filesystem isolation is non-negotiable for parallel agents - even with git branches, agents stepping on each others lockfiles and node_modules was a constant source of weird failures.

    the 500ms task startup from pre-warmed worktrees is a nice touch. we found that cold worktree creation was one of those things that felt fast enough in demos but became a real friction point when you are spinning up 5-10 agents per session.

    • haimau 17 minutes ago

      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/

      • timsuchanek 27 minutes ago

        Let's go! Love that this is a solid OSS alternative to what's already out there!

        • das-bikash-dev an hour ago

          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?

          • onecommit an hour ago

            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?

            • esafak an hour ago

              > Each agent runs as a task in its own git worktree

              If you're talking about shared services, that's another matter.

            • FiloVenturini an hour ago

              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 an hour ago

                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.

              • thesiti92 44 minutes ago

                i'll have to give it a shot, the market needs an open source cursor right now

                • onecommit 41 minutes ago

                  great! send all feedback our way :folded_hands:

                • ahmadyan 36 minutes ago

                  Congrats on the launch

                  • selridge an hour ago

                    Looks cool! Thank you for sharing.

                    • redrove 31 minutes ago

                      Is this another VSCode fork? I can’t tell from the readme.

                      • onecommit 23 minutes ago

                        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!