Custom AI tools like these have an uphill battle to fight. Automaker[0] from webdevcody is an example of that. He, together with some other folks created an open source Agentic Coding tool (for the lack of a better term), which gained popularity on github. He was advertising/showcasing it on streams etc. A few weeks in, he posted a video[1] where he speaks about why he's not using it himself anymore and went back to Claude Code, which over time receives tools/skills/mcps/whatnot and is in the terminal which we're all familiar with.
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.
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.
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 :)
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.
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
I just made an app that read GitHub issues. If they have a specific tag, the agent in the background creates a plan.
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.
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.
The worktree isolation is clever, but I'm curious about the security model when you're running multiple agents in parallel with shell access.
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.
We are experimenting with this kind of development style and from my experience so far this shift a lot of the complexity of building into the story writing and manual testing phases.
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?
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.
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?
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.
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.
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 :)
Will you add remote / a mobile control plane? I love your approach of using CLI. https://yepanywhere.com/ has a similar approach but it's mainly about access via mobile. [I'm frequently away from my desk]
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.
the worktree isolation per agent is clever. i've been running claude code as my sole dev partner on a production platform (10 repos) and the biggest unlock was treating context as infrastructure — curated reference docs the agent reads on-demand rather than dumping everything into context. re: the longevity question in the thread — i think the orchestration layer stays relevant as long as you're coordinating across repos/services, not just within a single codebase.
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?
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.
I've tried to load tasks that were refined locally, but that turned into a bunch of shell scripts to access the local DB. Will you support that until you provide a way to do the planning phase in the UI?
---
Also I've loaded 78 tasks and the UI is crawling to a halt
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?
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?
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.
This is essentially just setting up an MCP connection to your kanban provider and instructing the agent to plan out an epic. I did this this morning for some data modeling our team needed to do. For the most part it generated a good set of tickets, but there were some hallucinations due to ambiguity. Reviewing the already written out tickets was much better than writing them out myself.
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.
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.
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 :)).
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!
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!
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!
Custom AI tools like these have an uphill battle to fight. Automaker[0] from webdevcody is an example of that. He, together with some other folks created an open source Agentic Coding tool (for the lack of a better term), which gained popularity on github. He was advertising/showcasing it on streams etc. A few weeks in, he posted a video[1] where he speaks about why he's not using it himself anymore and went back to Claude Code, which over time receives tools/skills/mcps/whatnot and is in the terminal which we're all familiar with.
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
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.
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.
[flagged]
So, what's your business model ? Is this an YC product, or a tool you developed while working on a YC product ?
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!
I just made an app that read GitHub issues. If they have a specific tag, the agent in the background creates a plan.
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.
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/
The worktree isolation is clever, but I'm curious about the security model when you're running multiple agents in parallel with shell access.
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.
We are experimenting with this kind of development style and from my experience so far this shift a lot of the complexity of building into the story writing and manual testing phases.
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?
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.
Why mit license?
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?
Hi! Congratulations on building something new!
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.
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!
Could you compare it to other similar software? E.g. Codex App, Conductor, and others? Why your app?
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 :)
Will you add remote / a mobile control plane? I love your approach of using CLI. https://yepanywhere.com/ has a similar approach but it's mainly about access via mobile. [I'm frequently away from my desk]
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.
Congrats on the launch!
How does it compare to [0]Superset?
[0]: https://superset.sh
the worktree isolation per agent is clever. i've been running claude code as my sole dev partner on a production platform (10 repos) and the biggest unlock was treating context as infrastructure — curated reference docs the agent reads on-demand rather than dumping everything into context. re: the longevity question in the thread — i think the orchestration layer stays relevant as long as you're coordinating across repos/services, not just within a single codebase.
Wild how quickly developer workflows change. I went from cursor -> claude code CLI -> emdash (mix of claude code and codex now)
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?
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.
I've tried to load tasks that were refined locally, but that turned into a bunch of shell scripts to access the local DB. Will you support that until you provide a way to do the planning phase in the UI?
---
Also I've loaded 78 tasks and the UI is crawling to a halt
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?
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?
> Each agent runs as a task in its own git worktree
If you're talking about shared services, that's another matter.
What would be really great is a ability to run emdash simply served on localhost instead of the electron bundling ("emdash server" in the terminal).
That way I can access it from my browser.
Will you support Gitlab Issues ?
We could! Do you use them?
Yes !
Does emdash also help making the setup secure by isolating the agent from my local environment? This is more than just git worktrees.
Or do you consider this orthogonal to what emdash attempts to do?
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.
Hey! We pushed a fix for this. Let us know how it goes!
super quick turn around. Left a GH issue, need to bump internal package version to match deb version: https://github.com/generalaction/emdash/issues/1091
looking into this! Thanks for flagging
Love the fact that I can seamlessly switch between Codex for heavy backend stuff and Claude code for everything else.
Soon Gemini for Frontend.
How do you prevent the agents 'going rogue' through compactification or similar?
What security context do they run in?
I've been using this. Super useful, much better to avoid flipping between agents
Great to hear!
Let's go! Love that this is a solid OSS alternative to what's already out there!
Isn’t there vibe kanban?
This is essentially just setting up an MCP connection to your kanban provider and instructing the agent to plan out an epic. I did this this morning for some data modeling our team needed to do. For the most part it generated a good set of tickets, but there were some hallucinations due to ambiguity. Reviewing the already written out tickets was much better than writing them out myself.
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.
Pretty sick. How do you compare yourself with Conductor?
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.
Please codesign your Windows installer exes :)
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!
Love the tool! where do i send feedback?
Thank you! We have a Discord server https://discord.com/invite/f2fv7YxuR2 - but also there is a feedback modal in app that you can use!
Looks cool! Thank you for sharing.
one step closer to talking to an army of agents while doomscrolling x
Gorgeous UI! Will try it out.
Came to say killer name.
Congrats on the launch
Great name
LFG!
Is this another VSCode fork? I can’t tell from the readme.
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!
Judging from the installer sizes it's electron, not tauri?
Yawn. "Agentic bla bla" seems to be the current new "Here's my *-lang.org" thing...
i'll have to give it a shot, the market needs an open source cursor right now
great! send all feedback our way :folded_hands:
Can I use emdash to build another emdash?
very cool!
[dead]
[dead]
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!
[dead]
[dead]
[dead]