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.
If you run a coding agent with full yolo permissions on your machine, there are two major problems:
1. unrestricted internet access is a vector for prompt injection and code/data exfiltration
2. other stuff on your machine that you don't want your agent to access or modify
Most coding agent harnesses went for the "low friction" sandboxing approach and used Seatbelt on Mac. This doesn't really work well in practice because you can't allowlist certain safe domains (so its either all internet or no internet) and it's really tricky to allowlist certain locations on disk (agents ideally need to be able to install system packages, work with mobile simulators, etc and a lot of that stuff is on disk outside of your workspace).
So our solution to this looks a lot like yours: give your agents a container and a network policy and then let them yolo. Per your container policy, they won't be able to access anything unsafe on your disk or internet, except what you narrowly allow.
This is not only a cleaner sandbox model, but it allows you to give them more autonomy instead of letting them pause on each command to run.
Your VM solution is definitely doing the right idea as well. The difference with ctx is that we automatically manage a lot of the VM complexity including elastic memory.
--- RE: Worktrees, Multi-Agent, Collaboration ---
Yes, worktree support is common now. The thing you mention about multi-agent support and collaboration across team members is spot on. All of your agent transcripts are stored in a unified format locally, so your conversations with Claude Code look exactly like your conversations with Gemini. So if your teammate uses one and you use another, the idea is that they can see your work equivalently.
Another interesting concept is that multi-agent support is agent harness agnostic. So you can have a Claude Code primary agent invoke a Gemini subagent.
--- RE: Local Models ---
We don't set anything up specifically for this, but any agent harness that already works with local models will work the same in ctx. I think Codex or OpenCode are both fairly easy to use with local models, whereas Gemini and Claude Code are harder to set up this way. But if you try it, I'd be interested to hear how it goes for you.
I agree. I don’t think most of these products should be forking and maintaining a whole IDE.
That’s also not how I think about ctx. The UI is a workbench around agents, not a replacement for IntelliJ/VS Code. If you need deep code navigation, refactors, debugger-heavy work, etc., the right answer is usually to open the same worktree in your IDE.
ctx includes surfaces for diff review and an integrated terminal, but not code editing or a full-fledged IDE. It's not a fork of VSCode.
because you probably need both if you are doing guided agentic work. IDE gives you the familiar benefits, especially code nav. If you are using background agents or launching agents without reviewing their work, then I guess you dont need an IDE.
The merge queue is the part that matters most and gets the least attention. Running agents in parallel is easy. Landing their changes cleanly when two agents touch overlapping files is the unsolved part. Most tools just hope it doesn't happen.
Conflicts are not a problem at all in my experience.
My setup is that I run `/merge`[1] , which will first have the agent rebase changes on base, and on conflicts, it's instructed to understand both sides before resolving, which helps it merge them cleanly. I haven't resolved conflicts manually in months and also haven't had any issues with agents resolving them incorrectly. A solved problem as far as I'm concerned.
> it's instructed to understand both sides before resolving.
This is the crux of the issue. You are delegating the resolution of conflicts to an agent, which is fine, but doesnt solve the core issue that there's no scalable way to actually do this. It is far from a solved problem lol, just because your agents havent had issues resolving them.
One thing we found works really well is having the agent read the other agent’s plan document when it hits a merge conflict, not just the diff. A lot of conflicts are hard to resolve correctly without the intent behind the change.
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?
You can't avoid merge conflicts from happening, but you can definitely empower the agents to self-resolve them.
The workflow is like this:
1. an agent works in its own worktree
2. its changes are green in isolation
3. it submits that work to the local merge queue
4. the queue replays the change on top of the latest target branch and runs verification
5. if it conflicts or fails after replay, the merge is rejected
6. the agent can then pull in the new upstream state, resolve the conflict or test failure, and resubmit
We've found that agent-driven conflict resolution via a merge queue works really well in practice. It's almost necessary because of the increase in velocity of changes.
Regarding sandboxing approach, containers are primary right now. We do this natively on Linux and with Apple Virtualization Framework (AVF) on Mac. So yes, there is a VM involved on Mac, but it’s not exposed as a separate top-level mode.
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...
Yes. The important distinction is that ctx sits above the agent harness, not above the raw model APIs.
With something like Cursor, you can use models from OpenAI, Anthropic, etc, but they still run through Cursor’s own agent harness.
With ctx, you bring the existing harness itself — Copilot, Claude Code, Codex, and so on — and it keeps its own auth/billing/session model. ctx is the layer around that: worktrees, review, runtime boundaries, merge queue, etc.
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?
Yes, it’s free for individual local use, and you don’t need an account.
The upcoming paid plans will be for team/enterprise and managed services: org policy/security controls, shared history/collaboration, and optional hosted infrastructure like a gateway or managed remote access. These will be available when we exit beta.
That's a bummer, especially since folks normally use the ".rs" TLD for Rust projects, so the (perhaps accidental) implication from the domain is that this is a Rust project with the source available somewhere.
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?
ctx sits around the agent harness, not in place of it.
So Claude Code, Codex, OpenCode, etc keep their normal tools/capabilities rather than being reimplemented inside a new proprietary agent. If a harness has its own indexing/code-search story, you still get that; if it doesn’t, ctx doesn’t provide additional tools like codebase indexing.
The only additional tools we do provide are orchestration-related:
- local merge queue for agents (submit your diff and make sure it lands cleanly on others)
- agnostic subagents (for example, a Claude Code primary agent can invoke a Codex subagent)
Serena is more about text editing and better code search tooling while lumen is (a) chunking code with tree sitter and (b) storing embeddings (vectors) generated by an embedding model (ideally ones which are for code) which you then can search against. Effectively it‘s RAG for code made available as an MCP server.
This reduces tool calls (and thus saves times and tokens) because instead of „trying“ / „guessing“ names repeatedly, tools like claude code typically get useful search results on the first try.
Claude for example may search for „dbal“ via regex, but the function name is „sql“ - semantic search will find that while for regex, claude would try 3 additional guesses before it actually finds what its looking for. Hope this helps!
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.
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?
Yes, our view is that the ADE shouldn’t be where you do most code navigation.
The ADE is best for steering multiple agents and reviewing their changes, especially once you care about isolated worktrees, diffs, artifacts, and landing changes cleanly.
When you need deep code navigation, the best answer is usually to open the worktree in your IDE. IDEs are already world-class at navigation and refactoring, so there’s no reason to rebuild that badly inside an agent UI.
Compared with Conductor, a few differences:
- Conductor relies mostly on the safety model of the underlying harnesses; ctx can run work in VM/container-isolated environments with explicit network policy.
- ctx has a local merge queue for landing changes from multiple agent worktrees onto each other.
- Conductor is a local Mac app; ctx also works with Linux and is designed for the “local app + remote Linux runtime” model for devapp/VPS.
- Conductor is focused mainly on Claude Code and Codex; ctx is meant to be a broader environment around multiple harnesses.
There are also substantial UX differences, but those are easier to judge by trying them.
Agree with this. I find myself switching panes between conductor or codex and zed because of code navigation. Maybe that's what cursor is trying to do in their new version, but I havent tried it yet
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.
What’s preventing you from putting all of those in a single parent directory and boot into it?
Have you never heard of a monorepo?
What is the point of hosting a GitHub repo[0] with nothing in it but some links to your domain? There's no code, no license, no nothing.
[0] https://github.com/ctxrs/ctx
It is for issues reporting, similar to Claude Code.
> Open-source Agentic Development Environment (ADE) for teams using multiple coding agents.
Is it open source?
Ah I missed that, my mistake. It is fixed now. To confirm, it is not open source.
Any particular reason why not to open source it other than you plan on selling it as a PaaS?
OP here. Happy to answer questions.
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.
I think your concerns are valid and echo a lot of what I've heard from others experiencing the same uncertainties.
--- RE: Sandboxing and Permissions ---
First, make sure you know the Lethal Trifecta: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
If you run a coding agent with full yolo permissions on your machine, there are two major problems: 1. unrestricted internet access is a vector for prompt injection and code/data exfiltration 2. other stuff on your machine that you don't want your agent to access or modify
Most coding agent harnesses went for the "low friction" sandboxing approach and used Seatbelt on Mac. This doesn't really work well in practice because you can't allowlist certain safe domains (so its either all internet or no internet) and it's really tricky to allowlist certain locations on disk (agents ideally need to be able to install system packages, work with mobile simulators, etc and a lot of that stuff is on disk outside of your workspace).
So our solution to this looks a lot like yours: give your agents a container and a network policy and then let them yolo. Per your container policy, they won't be able to access anything unsafe on your disk or internet, except what you narrowly allow.
This is not only a cleaner sandbox model, but it allows you to give them more autonomy instead of letting them pause on each command to run.
Your VM solution is definitely doing the right idea as well. The difference with ctx is that we automatically manage a lot of the VM complexity including elastic memory.
--- RE: Worktrees, Multi-Agent, Collaboration ---
Yes, worktree support is common now. The thing you mention about multi-agent support and collaboration across team members is spot on. All of your agent transcripts are stored in a unified format locally, so your conversations with Claude Code look exactly like your conversations with Gemini. So if your teammate uses one and you use another, the idea is that they can see your work equivalently.
Another interesting concept is that multi-agent support is agent harness agnostic. So you can have a Claude Code primary agent invoke a Gemini subagent.
--- RE: Local Models ---
We don't set anything up specifically for this, but any agent harness that already works with local models will work the same in ctx. I think Codex or OpenCode are both fairly easy to use with local models, whereas Gemini and Claude Code are harder to set up this way. But if you try it, I'd be interested to hear how it goes for you.
Thanks so much for the thorough reply. I appreciate it. I'll report back on my experiences.
I don't understand why so many people building agents feel the need to fork and maintain a whole IDE as well
I agree. I don’t think most of these products should be forking and maintaining a whole IDE.
That’s also not how I think about ctx. The UI is a workbench around agents, not a replacement for IntelliJ/VS Code. If you need deep code navigation, refactors, debugger-heavy work, etc., the right answer is usually to open the same worktree in your IDE.
ctx includes surfaces for diff review and an integrated terminal, but not code editing or a full-fledged IDE. It's not a fork of VSCode.
Ok that makes more sense
because you probably need both if you are doing guided agentic work. IDE gives you the familiar benefits, especially code nav. If you are using background agents or launching agents without reviewing their work, then I guess you dont need an IDE.
The merge queue is the part that matters most and gets the least attention. Running agents in parallel is easy. Landing their changes cleanly when two agents touch overlapping files is the unsolved part. Most tools just hope it doesn't happen.
Conflicts are not a problem at all in my experience.
My setup is that I run `/merge`[1] , which will first have the agent rebase changes on base, and on conflicts, it's instructed to understand both sides before resolving, which helps it merge them cleanly. I haven't resolved conflicts manually in months and also haven't had any issues with agents resolving them incorrectly. A solved problem as far as I'm concerned.
[1]: https://workmux.raine.dev/guide/workflows#direct-merge
> it's instructed to understand both sides before resolving. This is the crux of the issue. You are delegating the resolution of conflicts to an agent, which is fine, but doesnt solve the core issue that there's no scalable way to actually do this. It is far from a solved problem lol, just because your agents havent had issues resolving them.
Definitely agreed.
One thing we found works really well is having the agent read the other agent’s plan document when it hits a merge conflict, not just the diff. A lot of conflicts are hard to resolve correctly without the intent behind the change.
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?
You can't avoid merge conflicts from happening, but you can definitely empower the agents to self-resolve them.
The workflow is like this:
1. an agent works in its own worktree
2. its changes are green in isolation
3. it submits that work to the local merge queue
4. the queue replays the change on top of the latest target branch and runs verification
5. if it conflicts or fails after replay, the merge is rejected
6. the agent can then pull in the new upstream state, resolve the conflict or test failure, and resubmit
We've found that agent-driven conflict resolution via a merge queue works really well in practice. It's almost necessary because of the increase in velocity of changes.
Regarding sandboxing approach, containers are primary right now. We do this natively on Linux and with Apple Virtualization Framework (AVF) on Mac. So yes, there is a VM involved on Mac, but it’s not exposed as a separate top-level mode.
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...
Yes. The important distinction is that ctx sits above the agent harness, not above the raw model APIs.
With something like Cursor, you can use models from OpenAI, Anthropic, etc, but they still run through Cursor’s own agent harness.
With ctx, you bring the existing harness itself — Copilot, Claude Code, Codex, and so on — and it keeps its own auth/billing/session model. ctx is the layer around that: worktrees, review, runtime boundaries, merge queue, etc.
Thanks for the response. I'll definitely give ctx a try.
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?
Yes, it’s free for individual local use, and you don’t need an account.
The upcoming paid plans will be for team/enterprise and managed services: org policy/security controls, shared history/collaboration, and optional hosted infrastructure like a gateway or managed remote access. These will be available when we exit beta.
Your repo says it's open source, but it's missing the source.
https://github.com/ctxrs/ctx
That is our issues-only repo, similar to Claude Code. It is not open source.
That's a bummer, especially since folks normally use the ".rs" TLD for Rust projects, so the (perhaps accidental) implication from the domain is that this is a Rust project with the source available somewhere.
It is a rust project, just not source available.
- someone really needs to start breaking these down along the lines of
- "I tried 47 agentic AI cli tools posted on HN in the last month. Here are the shocking results"
Appears to not work on Linux. Just launches, doesn't install an application file, window is blank on launch, and menu bar is all greyed out.
Thank you for flagging, I am fixing now and will update this thread when it's ready.
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?
ctx sits around the agent harness, not in place of it.
So Claude Code, Codex, OpenCode, etc keep their normal tools/capabilities rather than being reimplemented inside a new proprietary agent. If a harness has its own indexing/code-search story, you still get that; if it doesn’t, ctx doesn’t provide additional tools like codebase indexing.
The only additional tools we do provide are orchestration-related: - local merge queue for agents (submit your diff and make sure it lands cleanly on others) - agnostic subagents (for example, a Claude Code primary agent can invoke a Codex subagent)
how does lumen differ from serena? https://github.com/oraios/serena curious about it seems promising
Serena is more about text editing and better code search tooling while lumen is (a) chunking code with tree sitter and (b) storing embeddings (vectors) generated by an embedding model (ideally ones which are for code) which you then can search against. Effectively it‘s RAG for code made available as an MCP server.
This reduces tool calls (and thus saves times and tokens) because instead of „trying“ / „guessing“ names repeatedly, tools like claude code typically get useful search results on the first try.
Claude for example may search for „dbal“ via regex, but the function name is „sql“ - semantic search will find that while for regex, claude would try 3 additional guesses before it actually finds what its looking for. Hope this helps!
Oh thank you for the detailed response, that makes perfect sense, appreciate it and will certainly give it a try now!
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.
Yes, we allow fully local without github/PR involved.
For worktree creation, we support both git and jj.
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?
Yes, our view is that the ADE shouldn’t be where you do most code navigation.
The ADE is best for steering multiple agents and reviewing their changes, especially once you care about isolated worktrees, diffs, artifacts, and landing changes cleanly.
When you need deep code navigation, the best answer is usually to open the worktree in your IDE. IDEs are already world-class at navigation and refactoring, so there’s no reason to rebuild that badly inside an agent UI.
Compared with Conductor, a few differences:
- Conductor relies mostly on the safety model of the underlying harnesses; ctx can run work in VM/container-isolated environments with explicit network policy.
- ctx has a local merge queue for landing changes from multiple agent worktrees onto each other.
- Conductor is a local Mac app; ctx also works with Linux and is designed for the “local app + remote Linux runtime” model for devapp/VPS.
- Conductor is focused mainly on Claude Code and Codex; ctx is meant to be a broader environment around multiple harnesses.
There are also substantial UX differences, but those are easier to judge by trying them.
Agree with this. I find myself switching panes between conductor or codex and zed because of code navigation. Maybe that's what cursor is trying to do in their new version, but I havent tried it yet
I really appreciated this overview of when to use an IDE vs an ADE:
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.
Glad it helped!
Great tool so far- it feels deeply considered.
No thanks. We have a strict no-ai policy.