Fundamentally one of my biggest gripes with tools like this is that often you are not working with a single repo in anything beyond simple apps.
When I am working with Claude I am often doing it from the root directory of a workspace of dozens of repos. I work with Claude to come up with a plan for implementing a feature and it investigates and plans.That plan often encompasses multiple repositories. Claude then turns large scale plans into smaller issues, or tickets as artifacts.
We’ve felt the same thing and tried to make ctx work well in multi-repo setups.
There are basically two ways to approach it:
- If one repo is primary and the others are mostly reference material, use workspace attachments. That lets the agent work in one repo while still being able to read the others. I do this a lot with dependency/source repos.
- If the work genuinely spans multiple repos, just initialize the workspace at the parent directory that contains all of them. The harness still sees the same filesystem layout it normally would, so Claude/Codex/etc. can plan and work across repos the same way.
The main caveat is that some features are naturally more repo-specific. Merge queue is the obvious example, since landing and replay are much cleaner when there is one target repo/branch model.
The multi-thread, worktree-based interface will probably look familiar. The parts HN may care more about are the containerized workspaces, remote-host model, and local merge queue for multi-agent work.
I'm honestly having trouble understanding all the benefits and drawbacks of the different agents, specifically around what I want to permit for permissions.
My solution has been to create a new VM which inherits a Claude cli and Gemini CLI pre installed.
That way I can configure at a host level all the permissions I want and it is less likely the agent will access full sets of files and even worse delete things. I know this limits what I can do, but I am exhausted my understanding and auditing the different options for each agent.
I can install a new agent on that VM and then try it, but it is hard to justify the effort to test each one.
What am I getting from your tool for example? Worktree support is somewhat common, right? Does this give me multi agent support that Gemini and Claude do not, does that mean collaboration across team members? Is your approach better, or safer, than what I'm doing? How do I verify those claims?
Can I use your tool with local models like gemma 4 and ollama/llama.cpp: I have 3 24gb Nvidia cards and would like to try a three agent approach, one to write the code, one to write tests, one to architect. I obviously can't use local models with Gemini and Claude cli.
I'm just riffing on my concerns, and thanks for listening.
It's not open source, but is it free? I'm assuming you have plans on making money off of it somehow, can you share anything about what that will look like?
Looks cool! Two things: I see you mentioned the merge queue, but how exactly do people avoid or resolve merge conflicts when merging work from two or more agents in the separate worktrees? I havent really seen a seamless way to approach this or do people just have the agents work on distinctly unrelated stuff? Secondly, are containers the primary sandboxing appraoch? or do you support vms?
Does this solve indexing of codebases like Cursor does, or do you still need tools / plugins like Lumen (https://github.com/ory/lumen) for that in order to work in larger codebases without wasting tens of thousands of tokens on tool calls and brute force guessing with grep?
Very nice. Does this support GitHub Copilot subscriptions (oauth/hmac) or do you have plans for it? That would make or break for me because of the API costs.
Similarly I built a self-host able replit-like server with RAG but it's more end-user focused than developer focused...
Interesting, one challenge with other ADEs (nice term btw) like Conductor is that code navigation is terrible and too much emphasis is on a GUI for Claude.
We really need the best of both worlds: IDE (powerful like Intellij) + ADE (multitasking code)
And how does it compare to other tools like Conductor?
The challenge every tool in this space faces is the same: how do you give the agent enough autonomy to be useful without losing the ability to course-correct when it drifts? Interested in how ctx handles the context window boundary.
conductor was a non-starter for due to requiring the github + PR workflow. do you just allow management of a local repo without pushing us into a specific git flow? worktrees for diff work is fine, just if you want to handle the merge yourself (for whatever reason) how would that work.
52 comments
When I am working with Claude I am often doing it from the root directory of a workspace of dozens of repos. I work with Claude to come up with a plan for implementing a feature and it investigates and plans.That plan often encompasses multiple repositories. Claude then turns large scale plans into smaller issues, or tickets as artifacts.
There are basically two ways to approach it:
- If one repo is primary and the others are mostly reference material, use workspace attachments. That lets the agent work in one repo while still being able to read the others. I do this a lot with dependency/source repos. - If the work genuinely spans multiple repos, just initialize the workspace at the parent directory that contains all of them. The harness still sees the same filesystem layout it normally would, so Claude/Codex/etc. can plan and work across repos the same way.
The main caveat is that some features are naturally more repo-specific. Merge queue is the obvious example, since landing and replay are much cleaner when there is one target repo/branch model.
[0] https://github.com/ctxrs/ctx
> Open-source Agentic Development Environment (ADE) for teams using multiple coding agents.
Is it open source?
We will add paid options for Team/Enterprise when we exit our beta which include features for policy enforcement, collaboration, etc.
The multi-thread, worktree-based interface will probably look familiar. The parts HN may care more about are the containerized workspaces, remote-host model, and local merge queue for multi-agent work.
My solution has been to create a new VM which inherits a Claude cli and Gemini CLI pre installed.
That way I can configure at a host level all the permissions I want and it is less likely the agent will access full sets of files and even worse delete things. I know this limits what I can do, but I am exhausted my understanding and auditing the different options for each agent.
I can install a new agent on that VM and then try it, but it is hard to justify the effort to test each one.
What am I getting from your tool for example? Worktree support is somewhat common, right? Does this give me multi agent support that Gemini and Claude do not, does that mean collaboration across team members? Is your approach better, or safer, than what I'm doing? How do I verify those claims?
Can I use your tool with local models like gemma 4 and ollama/llama.cpp: I have 3 24gb Nvidia cards and would like to try a three agent approach, one to write the code, one to write tests, one to architect. I obviously can't use local models with Gemini and Claude cli.
I'm just riffing on my concerns, and thanks for listening.
Similarly I built a self-host able replit-like server with RAG but it's more end-user focused than developer focused...
We really need the best of both worlds: IDE (powerful like Intellij) + ADE (multitasking code)
And how does it compare to other tools like Conductor?
https://github.com/ctxrs/ctx
- "I tried 47 agentic AI cli tools posted on HN in the last month. Here are the shocking results"
https://ctx.rs/ade-vs-ide
TLDR: use an ADE if you need multiple agents working concurrently on your code base. Otherwise IDE with an agent plugin is probably fine.