Superset: An Agentic IDE That Puts Every Coding Agent in Its Own Git Worktree

The problem Superset targets: serial waiting, not model quality

The README frames the pitch as "Spend your time shipping, not waiting" and "Wait less, ship more." That is a narrower claim than it first appears. Superset does not make any single agent smarter. It assumes you have already accepted CLI agents as useful and that the constraint has moved to throughput: one agent holds one terminal, one working tree, and your attention while it runs. The stated remedy is to run many at once, each isolated in its own git worktree with its own branch, terminal, and environment, then "Compare the results and merge the winner." The intended user is a developer on macOS who already has a subscription to a CLI agent and is willing to manage several concurrent branches of the same repository. The repository topics list ade, agent-orchestration, worktrees, and parallel-agents, which is consistent with that framing. It is not aimed at someone who wants a single chat window, and it is not aimed at someone who has not yet decided whether agent-written code is worth reviewing.

Worktrees are the isolation mechanism, and the branch is the unit of work

The architecture visible in the README is built on git worktrees rather than on containers or virtual machines. Each parallel workspace gets its own worktree, its own branch, its own terminal session, and, per the browser feature, its own detected ports, "so every worktree gets its own preview." That choice matters more than the interface around it. Because worktrees share one object database and one clone, spinning up a new workspace is cheap compared with cloning the repository again, and agents cannot overwrite each other's files because they are not editing the same directory. The cost is that anything outside the working tree is still shared: a global package cache, a database on a fixed port, or a lockfile-driven install that writes to a user-level directory will still collide. Port detection per workspace is the README's answer to the dev-server half of that problem, but it says nothing about shared state such as a single local database instance. The diff viewer, the terminal, and the editor handoff all operate on the worktree, which makes the branch the natural unit of review and the merge the natural unit of completion.

What you actually install and run

The primary distribution path in the README is a macOS download from the latest GitHub release, linked as "Download for macOS." There is no Linux or Windows download offered in the material. Alongside the desktop app there is a CLI, documented at docs.superset.sh/cli/getting-started, described as "a single binary" that can "create workspaces, launch agents, read their terminals, and manage automations." The README's own summary of the CLI's scope is the sentence "If an agent can run a command, it can drive Superset," which is the clearest statement of intent in the document: the CLI exists so that an agent or a shell script can orchestrate other agents. Releases are versioned separately per component, with desktop-v1.28.0 and cli-v1.28.0 published on 2026-09-09 and a desktop-canary build on 2026-09-10. That split means the desktop app and the CLI can drift, and a script written against the CLI is pinned to a different version stream than the app a teammate is running. The README does not give the exact command syntax for creating a workspace from the shell; that detail lives in the linked CLI documentation, which is not reproduced here.

Remote hosts, the SDK, and MCP widen the surface without documenting it

The feature list claims workspaces are reachable "from anywhere" via remote hosts, the CLI, the SDK, or MCP, and the remote access section describes connecting another machine so its workspaces can be reached from the desktop app, the CLI, or a phone, including waking offline hosts with a custom command. That is a substantial expansion of the trust boundary. A worktree-per-task model is easy to reason about on one laptop; the moment a host is reachable from a phone, the questions become who can create a workspace on that machine, what credentials the CLI or SDK presents, and what an agent running there can read. The README and the supplied material do not answer any of those. It also does not state whether the SDK is a separate package, what language it targets, or how it relates to the CLI binary. Treat the remote and SDK claims as directions the project has taken rather than as documented operating procedures, and read docs.superset.sh/remote-access before enabling a host.

Where Superset is the wrong tool

The clearest limitation is platform: the README offers a macOS download and nothing else, so a Linux workstation or a Windows machine is not a supported path based on this material. The second is that parallel worktrees are only an advantage when the tasks are genuinely independent. Ten agents editing the same module in ten branches produce ten diffs that must be reconciled by a human, and the README's advice to "merge the winner" quietly assumes a winner exists rather than a merge conflict. Third, the model assumes you bring your own subscription. The tagline "Run any agent with your own subscription" means Superset is not selling model access, so its cost is layered on top of whatever you already pay per agent. Fourth, the automation feature runs agent sessions on a schedule, with the README suggesting overnight issue triage and weekly changelogs; scheduled unattended agents that open branches are a different risk profile from interactive ones, and the material does not describe what guardrails, if any, apply. If your work is a single deep refactor that one agent should carry end to end, the orchestration layer adds branches to manage and nothing else.

How it compares to running tmux and git worktree yourself

The honest alternative is the one Superset is built on: a shell script that calls git worktree add, opens a tmux pane per worktree, and launches the agent in each. That approach has no licence, no desktop app, and no release channel to track, and it works on any platform git and tmux support. What it does not have is the parts of Superset that are not git: the sidebar that tracks which agent is working and which is done, the completion chimes and dock badges, the in-app diff viewer with commenting and editing, per-workspace port detection feeding an embedded browser, and the command palette. Those are the features you are adopting. The trade is that you take on a macOS-only application, a canary release channel, and a licence you have to read. A hosted cloud agent product is a different comparison again, since it removes the local machine from the loop entirely and in exchange takes custody of your repository; Superset keeps the repository local, which is the reason to prefer it if that custody is the thing you object to.

Licence and the cost of keeping up

The GitHub metadata reports the licence as NOASSERTION, and the README's own badge links to LICENSE.md and labels it Elastic License 2.0. Those two signals disagree in form, and the practical answer is in the file at LICENSE.md, not in the badge. Elastic License 2.0 is a source-available licence, not an OSI-approved open source licence, and it typically restricts offering the software as a managed service; the material here does not reproduce the terms, so anyone planning to embed Superset in a product or resell access to it should read LICENSE.md directly rather than rely on this description. This is not legal advice. On maintenance, the versioning scheme is the thing to plan around: desktop and CLI carry independent version numbers and there is a separate canary channel, with the canary build published one day after the stable 1.28.0 pair in the release list. Scripts that drive the CLI, and any MCP or SDK integration built on top, need to be tested against CLI releases rather than desktop releases, because nothing in the material suggests the two are versioned in lockstep.

Editorial conclusion

Adopt Superset if you already run Claude Code, Codex, or another CLI agent on macOS and your bottleneck is serial waiting rather than model quality, since the worktree-per-task model is the part that actually removes the interference. Skip it if you need a Linux or Windows build, a hosted control plane, or a permissive OSI licence, because the README offers only a macOS download and the licence badge points at Elastic License 2.0. Before committing a team, verify three things in the repository itself: the exact terms in LICENSE.md, whether the desktop-v1.28.0 and cli-v1.28.0 release artifacts match the canary channel you would actually run, and how the CLI authenticates to a remote host, since the README describes remote access without documenting the credential path.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. superset-sh/superset on GitHub