Alternative IDEs and Agent Shells

It is 3pm. You have six terminal tabs open. Two agents are mid-refactor, one finished nine minutes ago and you have not noticed, one has been sitting on a permission prompt since 2:20, and you genuinely cannot remember what you asked the fifth one to do. Your agent is not the bottleneck — your shell is. The thing you run agents inside was designed for one human typing, not for six processes reporting back.

An entire tool category grew up around this problem in the last eighteen months. The yetanotherorchestrator.app directory catalogues 48 of them: 29 desktop apps, 9 web dashboards, 9 terminal UIs, 1 cloud. Most will not exist in two years. This guide covers the ones worth your evaluation time, and — more usefully — the selection rule that keeps you from betting on the next one to get archived.

What You’ll Walk Away With

• The four shapes an agent shell can take, and which one matches how you actually work
• Honest assessments of eight tools, including where each one hurts
• A decision table that maps your constraint (Linux, SSH, GUI, real isolation) to a specific tool
• A copy-paste audit that tells you whether your repo can even survive parallel agents — most cannot, out of the box
• The 2026 churn record, and the one question that predicts which tools survive it

The Rule: Does It Run Your Agent?

Everything below passes one test: you can run Claude Code, Codex, or Cursor Agent inside it. The tool is a shell around the agent you already pay for. Swap the agent, keep the shell.

That rule excludes a whole popular category, on purpose.

Note

Not covered here: agent-first IDEs with their own agent. Google Antigravity, AWS Kiro, and Devin Desktop are all real products with real followings, but their agent is the product — you cannot drop your Claude Code session into them and keep your CLAUDE.md, your hooks, your skills, and your subscription. They are a replacement decision, not a shell decision, and they belong in a different comparison. Devin Desktop (the former Windsurf) is covered in vs Windsurf.

The practical consequence of the rule: everything below is portable. If the tool dies, your agent, your config, and your muscle memory all survive.

Four Shapes of Shell

Shape	Isolation model	Where it runs	Pick it if
Editor + external agent (ACP)	Your one working copy	Local editor	You want one agent at a time, in the editor you already love
Terminal multiplexer	Whatever you configure	Local + SSH + remote box	You live in the terminal and want sessions that outlive your laptop lid
Desktop orchestrator	One git worktree per agent	Local, cloud on paid tiers	You want to see six agents at once and review their diffs in a GUI
Container / board	Docker container per agent, or a task queue	Local	Your repo genuinely cannot run twice at the same time

The shapes are not competing philosophies so much as different answers to “how many agents at once, and how isolated do they need to be.” Most developers end up with two: an editor for the one task they are thinking hard about, and a multiplexer or orchestrator for the fan-out.

Editor + Swappable Agent: Zed and JetBrains via ACP

The most under-discussed answer to “what IDE runs Claude Code” is: the one you already use, via ACP.

The Agent Client Protocol is an open JSON-RPC 2.0 standard — deliberately modelled on the Language Server Protocol, but for agents. Zed Industries created it in August 2025 and JetBrains joined shortly after. An agent implements ACP once; every ACP-capable editor can then drive it. No per-editor integration, no waiting for a vendor to ship a plugin.

In practice this means Claude Code runs as a first-class citizen in Zed’s agent panel, not as a terminal in a pane: Zed wraps Claude Code’s SDK and translates the calls into ACP, so you watch it edit across files with real syntax highlighting and language-server diagnostics attached. Codex, Gemini CLI, OpenCode, Goose, and Cline connect the same way.

In January 2026, Zed and JetBrains co-launched the ACP Agent Registry — a browsable directory of compatible agents, built directly into both editors. Native support is Zed and JetBrains; Neovim, Emacs, and VS Code have community plugins.

Why this matters more than any individual app on this page: ACP decouples the editor decision from the agent decision. You are no longer choosing “Cursor or Claude Code” — you can keep JetBrains for the Java monolith, use Zed for the Rust service, and run the same agent in both.

Where it hurts: ACP is a one agent, one editor window story. It gives you a beautiful single-agent experience and nothing at all for fan-out. If your problem is six agents, ACP is not the answer — read on.

Terminal-Native: herdr

herdr is the tool most directly aimed at the 3pm scenario in the opening. It calls itself an agent multiplexer — “one terminal for the whole herd” — and it is a single Rust binary, roughly 10MB, Apache-2.0 licensed, with over 22,000 GitHub stars. No Electron, no account, no telemetry.

The mental model is tmux that knows what an agent is. Each agent gets a real PTY pane, running the actual CLI you would have run by hand. A background server keeps every pane alive when you close the laptop, and you can reattach over SSH — including from a phone, since the layout is mouse- and touch-responsive.

The feature that earns its keep is state detection. herdr classifies every pane as idle, working, or blocked, and shows them grouped in a sidebar. That is the fix for “one agent has been waiting on a permission prompt for 40 minutes.” The docs are unusually honest about the mechanism: herdr only marks a pane blocked when the live bottom-buffer snapshot matches a known approval, question, or permission UI. Where an agent supports lifecycle hooks, herdr installs them and the signal is exact; otherwise it is reading your screen.

Agent coverage is the broadest of anything here. Claude Code, Codex, and Cursor Agent CLI all get partial lifecycle support; Copilot CLI, Devin CLI, Droid, OpenCode, and Kilo Code CLI sit in the same tier; Amp, Grok CLI, Kiro CLI, Gemini CLI, and Cline are detected via screen manifests. Any terminal agent works as a plain pane even without a plugin.

There is also a socket API — CLI and JSON — which means agents can drive herdr: spawn a pane, read another pane’s output, wait on a sibling. That is the primitive for “an orchestrator agent that fans out to workers,” and almost nothing else in this category exposes it.

Where it hurts: herdr is a multiplexer, not a reviewer. There is no diff UI, no PR creation, and no worktree management — if you want one worktree per agent (you do; see below), you set that up yourself. It is also Linux/macOS-first; Windows is a preview beta.

For the hands-on version — installing it, why the lifecycle hooks matter, and building an orchestrator agent on the socket API — see herdr: an agent multiplexer with a socket API.

Desktop Orchestrators

Conductor

Conductor is the canonical GUI answer: “run parallel coding agents on your Mac.” It drives Claude Code, Codex, and Cursor, gives each one an isolated git worktree created with a single click, and puts them all on one board so you can see what every agent is doing and review its changes without switching windows.

Pricing is Free for local parallel workspaces on your Mac, and $50/mo for Pro, which adds long-running cloud workspaces, API access, a mobile app, and collaboration with other Pro users. Teams (multiplayer, admin portal, SSO) is announced as coming; Enterprise is custom.

Where it hurts: macOS only. That is a hard stop for Linux teams, and no roadmap promise changes it today.

Nimbalyst

Nimbalyst is the open-source cross-platform equivalent, and it is worth knowing its lineage: it is the official successor to Crystal, from the same maker. Crystal was an MIT-licensed Electron app for parallel Claude Code and Codex sessions in git worktrees; it was deprecated in February 2026 and its repo now points at Nimbalyst.

Nimbalyst keeps the parallel-session and worktree model — any session can opt into its own worktree with one click — and adds a session kanban, WYSIWYG editors, task tracking, an extension system, and a native iOS app. macOS, Windows, and Linux.

Where it hurts: it is the youngest thing here carrying the most surface area. Treat the newer features (extensions, iOS) as newer than the core.

Emdash

Emdash bills itself as the open-source Agentic Development Environment: run multiple coding agents in parallel, use any provider. Apache-2.0, a YC W26 company, over 5,000 stars, macOS/Windows/Linux, and commits landing daily.

It is the most straightforward pick if you want Conductor’s shape without the macOS constraint and without a $50 tier — at the cost of a smaller ecosystem and less polish.

Sculptor: containers instead of worktrees

Sculptor from Imbue is the one architecturally different desktop tool, and the difference matters. Instead of a git worktree per agent, it gives each agent its own Docker container, then syncs the work back into your local repo when you want to test it.

That is a genuinely stronger isolation boundary, and it solves the failure mode that bites everyone else in this category: a worktree isolates files, not ports, not node_modules, not your dev database, not Docker container names. Six agents in six worktrees running npm run dev fight over port 3000. Six agents in six containers do not.

Where it hurts: it is a small project — MIT, around 200 stars. The architecture is the right one; the maintenance risk is real. Evaluate it knowing you might end up maintaining your own fork.

Boards, and a Cautionary Tale

Vibe Kanban is the best-known board-shaped orchestrator: tasks as cards, assign each to an agent, move work from to-do through review, agent-agnostic across 10+ agents including Claude Code, Codex, Gemini CLI, Copilot, Amp, Cursor, and OpenCode. Apache-2.0, nearly 28,000 stars, one command to try: npx vibe-kanban.

Caution

Vibe Kanban’s README now opens with “Vibe Kanban is sunsetting.” The last commit landed in April 2026. It is included here on purpose: 28,000 stars and a one-line install is exactly the profile of tool people adopt without checking, and the license means you can fork it — but you should decide that deliberately rather than discover it in six months. If your team is on it today, the migration targets with the same shape are Nimbalyst and Emdash.

Terminal Baseline: Do This Before You Buy Anything

Before evaluating a single app, spend twenty minutes with the free version of the idea: git worktree plus tmux. One worktree per task, one branch per worktree, one agent per pane. The worktree primitive is covered end to end in Claude Code advanced techniques — including the common mistake of reaching for --add-dir, which adds context to one session rather than isolating several.

If you want that with a session manager on top, Claude Squad is the Go TUI for exactly this: multiple Claude Code, Codex, OpenCode, or Amp instances, each in its own tmux pane rooted in its own worktree. AGPL-3.0, around 8,000 stars.

Warp is the heavyweight terminal option. It now bills itself as an agentic development environment “born out of the terminal,” its source is published under AGPL-3.0, and the pitch is explicitly any harness — Claude Code and Codex run alongside Warp’s own agent, in split panes, with a built-in editor and WARP.md project rules. Oz is its cloud side: launch any agent into the cloud via SDK, CLI, or from the terminal, with centralized governance, usage visibility, and credit caps. macOS, Linux, and Windows.

The baseline matters because it is the control in your experiment. If tmux plus worktrees already handles your fan-out, the only thing a $50/mo app buys you is a nicer view of it — which may well be worth it, but you should know that is what you are buying.

The baseline is also more capable than most people realise, because send-keys, capture-pane, and wait-for make tmux a message bus between agents. tmux for agent fleets covers that, plus why your agent — not your script — should be creating the worktrees now.

Also Worth Knowing

• Herd (joinherd.ai) — a different product from herdr, despite the name. A cross-platform desktop app for launching many agents in parallel with a real-time dashboard, handling merges and cleanup for you. Claude Code, Codex, and Kimi. Worth knowing the two exist so you search for the right one.
• Mux (coder/mux, formerly cmux) — desktop app for isolated parallel agentic development, from the Coder team. AGPL-3.0.
• Omnara — open-source agent control plane, but the repo has been quiet since January 2026.
• The full directory if you want to see all 48 and judge for yourself.

Which One: A Decision Table

Your constraint	The answer
I want to stay in my editor and swap agents freely	Zed or JetBrains via ACP
I live in the terminal and want sessions that survive SSH and a closed lid	herdr
I want a GUI board of six agents and I am on a Mac	Conductor
Same, but I am on Linux or Windows	Nimbalyst or Emdash
My repo cannot run two copies at once (ports, dev DB, Docker)	Sculptor (containers), or fix the repo first with the audit below
I want to know if I need any of this	git worktree + tmux for a week, then decide
I need an orchestrator agent that spawns and coordinates workers	herdr’s socket API
My legal team reviews every dependency license	Apache-2.0/MIT: herdr, Emdash, Sculptor, Nimbalyst. AGPL-3.0: Claude Squad, Mux, Warp

Make Your Repo Survive Parallel Agents

Almost every “the orchestrator is broken” report is actually a repo that cannot be checked out twice. Run this before you evaluate anything — the results usually change which shape of tool you need.

Tip

Copy-paste prompt — audit this repo for parallel-worktree readiness:

Audit this repo for whether 4-6 agents can work in parallel git worktrees
without interfering with each other. Check specifically:

1. Hardcoded ports in dev/test scripts, docker-compose, and config
2. .env handling -- is it gitignored, and would a fresh worktree have none?
3. Install cost -- does each worktree need its own node_modules / venv /
   target dir, and how long does that take?
4. Shared mutable state: a single dev database, a local Redis, a fixed
   S3/R2 bucket prefix, fixed Docker container or network names
5. Git hooks and tooling that assume a single checkout path
6. Any absolute paths baked into config or scripts

Then produce two things:
- bin/wt, a shell script with `new <slug>`, `list`, and `cleanup <slug>`
  subcommands that creates a worktree at ../<repo>-<slug> on branch
  <slug>, copies the env files a fresh worktree needs, runs the install
  step, and assigns a non-colliding port via an offset
- a "Parallel agents" section for CLAUDE.md and AGENTS.md stating the
  worktree convention, the port assignment rule, and what an agent must
  NOT touch because it is shared

Report the findings as a ranked list of blockers before writing anything.

Run a Real Bake-Off

Do not pick from feature tables, including the one above. The differences that matter are ergonomic and show up in the first hour.

1. Pick one real task you would fan out anyway — four independent, small, orthogonal changes. Four bug fixes in four directories is ideal; one feature split four ways is not, because you will be measuring your decomposition rather than the tool.

2. Run the baseline first. git worktree plus tmux, four panes, four agents. Time it. This is your control, and sometimes it wins.

3. Run the same four tasks in two candidate shells. Same agent, same models, same prompts. Change only the shell.

4. Score the things you actually felt: how long until you noticed an agent was blocked; how many times you lost track of which pane was which; minutes from “agent finished” to “diff reviewed”; whether anything collided.

5. Decide on a two-week trial, not forever. Given the churn record below, a two-year bet on any of these is not a bet you can win.

Tip

Copy-paste prompt — review the branches four parallel agents just produced:

Four agents just finished on branches: <b1>, <b2>, <b3>, <b4>. Review them
as a set, not individually. I care about the cross-branch failures that
per-PR review cannot see:

1. Duplicate implementations -- two branches adding the same helper under
   different names, or fixing the same root cause two different ways
2. Refactor collisions -- one branch moving or renaming something another
   branch imports
3. Contradictory changes to the same config, schema, or migration
4. Test overlap: two branches asserting the same behaviour differently

For each finding, name the branches, the files, and which version should
win with a one-line reason. Then give me a merge order that minimizes
conflicts, and flag which merges need a human decision rather than a
mechanical resolution.

Do not merge anything. Report only.

Feeding Your Agent to Any Shell

Every shell here works by spawning your agent’s CLI. Knowing the headless entry point makes any of them scriptable — and makes you portable when a tool dies.

Cursor

Cursor exposes cursor-agent as its CLI, and that is what shells like herdr and Conductor detect and drive. Inside a worktree, the agent picks up that directory’s .cursor/rules — so per-worktree rules are a real mechanism for keeping four parallel agents in their lanes.

Cursor’s own Agents Window already does local, worktree, cloud, and SSH parallelism natively. Before adding an external shell on top, check whether it already does what you want — see the feature matrix.

Claude Code

claude for interactive panes; claude -p "task" for non-interactive; --output-format json when a script needs to parse the result; claude --resume to pick a session back up. That is the whole contract a shell needs.

Claude Code’s lifecycle hooks are what let herdr report exact state instead of guessing from the screen — if you use herdr, installing its hooks is the difference between reliable blocked detection and a heuristic.

Codex

codex for interactive panes, codex exec for non-interactive runs, codex resume to continue a thread. Codex also has its own worktree threads and Cloud tasks, so the same question applies as with Cursor: check what you already have before wrapping it.

Each worktree gets its own AGENTS.md, which is the cleanest way to scope a parallel agent to one slice of the repo.

When This Breaks

A worktree is not isolation. It isolates files and nothing else. Ports collide, .env is missing in a fresh worktree, node_modules gets installed four times, the shared dev database gets migrated by two agents at once, Docker container names clash. This is the single biggest source of “parallel agents don’t work” — run the audit prompt above, or use container isolation.

Blocked-state detection is a heuristic unless you wire hooks. Screen-pattern detection misses novel prompts. An agent can sit on an approval for an hour while the dashboard shows it working. Install the lifecycle hooks your agent supports, and get in the habit of scanning states rather than trusting the badge.

Six agents means six times the tokens and six times the review. The output multiplies; your review bandwidth does not. Accepted throughput — not agent count — is the number to watch, and it usually stops improving well before you run out of laptop. The merge-queue playbook, conflict-resolver pattern, and how to calibrate a per-developer ceiling are covered in team parallelism; costs in cost optimization.

Rate limits are shared. Every shell spawns your CLI on your plan. Six parallel agents hit your account’s limits six times faster, and most shells surface that as an agent that mysteriously stopped rather than as a quota error.

This category churns harder than anything else in your toolchain. As of July 2026: Roo Code archived on 15 May; Void archived; Crystal superseded by Nimbalyst in February; Vibe Kanban sunsetting; opencode and goose both moved GitHub organizations; Windsurf became Devin Desktop. That is one significant change per quarter, in a single category.

The question that predicts survival is not stars or funding. It is: does this tool wrap my agent’s CLI, or reimplement the agent? A wrapper is a view over claude and codex — when it dies, you lose a UI and keep everything else. A reimplementation owns your prompt history, your task state, and your workflow — when it dies, you migrate. The corollary: prefer tools that keep state in git (branches, worktrees, commits) over tools that keep it in their own database.

License matters more than usual here, because these tools sit in the middle of your development loop. AGPL-3.0 (Claude Squad, Mux, Warp) is a different conversation with a corporate legal team than Apache-2.0 or MIT (herdr, Emdash, Sculptor, Nimbalyst). Find out which conversation you are having before you standardize a team on one.

What’s Next

Feature Matrix What Cursor, Claude Code, and Codex already do natively -- check before adding a shell

Claude Code Advanced Techniques The git worktree primitive, done properly, with prompts

Team Parallelism Merge queues, conflict-resolver agents, and calibrating the per-developer ceiling

Cursor vs Claude Code IDE-first vs CLI-first, which decides what shape of shell you need

Cost Optimization What parallel fan-out does to your token and credit burn

vs Windsurf Devin Desktop, the agent-first IDE deliberately out of scope above