It is for issues reporting, similar to Claude Code.
65 karma · joined March 4, 2026
--- 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.
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.
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.
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.
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)
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.
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.
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.
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.
Thank you Simon and I'm sure you would quickly fall off from #1 blogger on HN if you did. I insist on this for myself as well.
Somehow we are all getting really good at detecting "written by AI" with primal intuition.