Supacode: a macOS command center for parallel coding agents in git worktrees
worktree coding agents command center.
At a glance
- What is it?
- Supacode is a native macOS app that gives each coding agent task its own git worktree and its own real terminal, with sessions that survive quitting the app. It is macOS 26.0+ only, built from source with mise and Xcode, and its remote SSH support is labelled Beta.
- Who is it for?
- Adopt Supacode if you are on macOS 26.0+ and already run several coding agents at once, because the worktree-per-task model and zmx-backed session persistence match that workflow directly. Skip it if you are on Linux or Windows, or if you want a packaged download rather than a source build with mise, Xcode and git submodules.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 25 days ago.
- What is it written in?
- Mainly Swift, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 28, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The collision problem Supacode is built around
Running one coding agent in a repository is manageable. Running four is not, because they all want the same working tree. Two agents editing the same checkout will overwrite each other's files, and a build or test run triggered by one agent will see the half-finished edits of another. The usual workaround is manual: stash, copy the directory, or juggle branches in one terminal window and lose track of which agent is doing what.
Supacode's answer is to make the git worktree the unit of work. The README describes it plainly: each task gets its own git worktree and its own terminal, so agents run in parallel without colliding. The sidebar is the map of that state. It refreshes branch, file, and pull request state live, nests rows by branch, and hoists worktrees that need attention (an agent awaiting input, a running script) to the top. Pin, archive, auto-delete after N days, and jump to any with Control-1 through Control-9.
The intended user is a developer on macOS who already delegates work to command-line agents and now wants several in flight at once. It is not a hosted service and not a web UI. It is a native app that wraps a real terminal, and the repository's primary language is Swift.
Worktrees, zmx sessions and how the pieces connect
The architecture has three parts worth separating.
The first is the terminal. Every session is rendered by libghostty, the same engine behind Ghostty, with tabs, horizontal and vertical splits, per-surface backgrounds, and theme sync with the app's appearance. This matters because the agents Supacode targets are interactive terminal programs, not libraries. The app is a window manager for those programs, not a replacement for them.
The second is session persistence. Sessions do not run as children of the app. They run inside zmx, described in the README as a lightweight session daemon. Quit and relaunch the app, and every session reattaches exactly where you left it, scrollback included. This is on by default, and there is a quit option that tears everything down when you want a clean start. That distinction is the whole reason the design works: an agent that has been running a long task for twenty minutes is not killed because you closed a window.
The third is agent detection. Supacode detects the agent in each pane and shows a live badge: busy, awaiting input, or idle. The README says it supports the common agents (Claude, Codex, Copilot) through hooks it installs. Those hooks are the mechanism by which a terminal program that knows nothing about Supacode can still signal its state to the sidebar. If an agent is not covered by the hook installation, the badge is the feature you lose first.
Remote SSH repositories are a fourth piece, marked Beta. Point Supacode at a repository on a remote host over SSH and it manages that repo's worktrees like a local one. Every git probe and the terminal share one multiplexed SSH connection, so you authenticate once. When the host has zmx installed, remote sessions survive dropped connections and laptop sleep: the connection retries and reattaches instead of restarting. The README is explicit that some local-only features are reduced in this mode.
Installing Supacode from source and opening a first worktree
There is no Homebrew formula or installer in the README. The documented path is a source build, and the requirements are specific: macOS 26.0+, mise for the pinned toolchain with ~/.local/bin on your PATH, git submodules, and Xcode 26.3 if you are on macOS 26.4 or later.
The README's quick start clones recursively, installs the pinned toolchain, runs a preflight check, and launches the Debug app:
git clone --recursive [email protected]:supabitapp/supacode.git
cd supacode
mise install
make doctor # check every build prerequisite and print fixes for anything missing
make run-app # build and launch the Debug appmake doctor is the step to take seriously. According to the README it verifies mise, submodules, a Zig-linkable Xcode, the Metal Toolchain, and the pinned tools, and prints the exact command to fix anything missing. The build targets run it automatically as a quiet preflight, so a failure there is cheaper to read than a failure deep in a compiler log.
If you are on macOS 26.4 or later, the README documents a hard blocker before any of that works. GhosttyKit is built with a pinned Zig 0.15.2 whose linker cannot link the macOS 26.4+ SDK, because that SDK dropped the arm64-macos slice from libSystem.tbd (ziglang/zig issue 31658). The build fails with a wall of undefined symbol errors. The fix is to install Xcode 26.3, which ships the macOS 26.2 SDK that still has arm64-macos. You do not switch it globally; the build auto-detects a Zig-linkable Xcode and pins it for that build only. The README gives three commands to accept the licence, run first launch, and download the Metal Toolchain, all prefixed with DEVELOPER_DIR pointing at /Applications/Xcode_26.3.app/Contents/Developer.
Once the app is running, the first real use is creating a worktree. The README lists the entry points: the sidebar, a hotkey, the command palette, the CLI, or a deeplink. Pick one, name the task, and the app creates a git worktree with its own terminal. From there the terminal behaves as a normal terminal, and you start your agent inside it. The sidebar row then carries that worktree's branch and file state, and once an agent hook is installed, its presence badge.
The CLI is the second thing to learn, because it is what makes the app scriptable. The README states that the supacode CLI manages worktrees, tabs, splits, and repos, and that every session exports its repo, worktree, tab, and surface IDs, so commands default to the session you run them in. Deeplinks under the supacode:// scheme mirror the CLI, which is how you bind an action to a hotkey or fire it from another application.
Where Supacode is the wrong tool
The platform constraint is the first and largest. Supacode is a native macOS app requiring macOS 26.0 or later. There is no Linux build and no Windows build in the repository. If your team standardises on Linux workstations or on WSL, this project does not apply to you, and no amount of CLI surface changes that.
The second constraint is the build. This is not a download-and-run application. You need mise, git submodules, a Zig-linkable Xcode, the Metal Toolchain, and on macOS 26.4+ a second Xcode version installed alongside your main one. The README points at Xcode 26.3 specifically because of the SDK slice issue. Anyone who cannot install an older Xcode next to a newer one, or who is on a managed machine where that is not permitted, is stuck before the first launch.
The third is the Beta label on remote SSH. The README says local-only features are reduced in that mode. If your entire workflow is remote development, you are adopting the least finished part of the product, and the failure mode is not a crash but a feature you expected that simply is not there.
The fourth is agent coverage. The presence badges, which are a large part of why the sidebar is useful, depend on hooks Supacode installs for specific agents. The README names Claude, Codex and Copilot as the common ones it supports. An agent outside that set still runs fine in the terminal, since the terminal is just libghostty, but the sidebar will not tell you when it is waiting for input. You would be paying the setup cost of a worktree manager and getting a plain terminal multiplexer's worth of awareness.
Supacode compared with a terminal multiplexer and with cmux
The obvious alternative is not another app but tmux or a terminal emulator with split panes. The difference is where the abstraction sits. A multiplexer organises processes into panes and windows; it knows nothing about git. You can run four agents in four tmux windows today, and you can attach and detach from them, which covers the persistence story that zmx provides here. What you do not get is the worktree. Creating one, naming it after the task, tracking its branch, watching its pull request checks, and hoisting it when an agent needs input are all things you would script yourself against the git and GitHub CLIs. Supacode's claim is that this bookkeeping is the actual work, and it is a reasonable claim if you run more than two agents at a time.
Among purpose-built tools, cmux appears in the related searches for this project, so people are comparing them. The README documents Supacode's approach and does not document cmux's, so the honest statement is that both are aimed at the same problem of running coding agents in parallel, and the difference to check yourself is whether the other tool models a git worktree per task, whether it persists sessions in a daemon independent of the app, and whether it is macOS-only. Those three questions decide the choice far more than any feature list. The same applies to Superset and Herdr, which also appear in the searches: without documentation of their internals, a comparison would be guesswork.
Maintenance, build cost and the licence question
The repository is not archived. The last push was on 2026-09-05, which is recent. The release history shows v0.10.8 on 2026-08-03 and v0.10.7 on 2026-07-31, plus a nightly channel labelled Tip. Auto-updates run through Sparkle with a selectable update channel, so an installed build can follow stable or nightly without a manual rebuild.
The upgrade cost is concentrated in the toolchain rather than in the app. Because GhosttyKit is built from Zig source, the README notes that step is slow and cached. The Makefile confirms the caching intent: it defines a stamp directory under .build/.tuist-generated-stamps and treats Project.swift, Workspace.swift, Tuist.swift, mise.toml, scripts/build-ghostty.sh, scripts/build-zmx.sh and the test sources as generation inputs, so a change to any of them triggers a Tuist regeneration. The comment in the Makefile explains why the test files are in that list: test targets use explicit source globs expanded at generation time, so a new test file must trigger a regen or it would silently run in no bundle. That is a build system detail worth knowing before you add a test and wonder why it never runs.
The licence needs a direct look. The repository metadata reports NOASSERTION, and the README says only to see LICENSE. There is no SPDX identifier stated in the repository's description. If you plan to redistribute a build or ship it inside a company image, read LICENSE and ThirdParty/ yourself; the presence of a ThirdParty directory suggests bundled dependencies with their own terms. Nothing here should be read as legal advice, and the absence of a stated identifier is exactly the kind of thing to resolve before a legal review rather than during one.
Editorial conclusion
Adopt Supacode if you are on macOS 26.0+ and already run several coding agents at once, because the worktree-per-task model and zmx-backed session persistence match that workflow directly. Skip it if you are on Linux or Windows, or if you want a packaged download rather than a source build with mise, Xcode and git submodules. Before committing, run make doctor on your machine and confirm it reports a Zig-linkable Xcode, then verify the LICENSE file, since the repository does not state an SPDX identifier.
Frequently asked questions
How do I use Supacode?
Build and launch the app with the README's quick start, then create a worktree from the sidebar, a hotkey, the command palette, the CLI, or a deeplink. Each worktree gets its own terminal, and you start your coding agent inside it.
Is Supacode good?
The README presents it as a native macOS command center for running coding agents in parallel, with session persistence through zmx and live agent presence badges. Whether that fits you depends on being on macOS 26.0+ and running several agents at once; the remote SSH feature is still labelled Beta.
Does Supacode run on Linux or Windows?
No. Supacode is a native macOS app and the README lists macOS 26.0+ as a requirement, with no Linux or Windows build documented.
Do sessions survive quitting Supacode?
Yes, by default. Sessions run inside zmx rather than as children of the app, so quitting and relaunching reattaches every session where you left it, scrollback included. There is also a quit option that tears everything down for a clean start.
Why does the Supacode build fail with undefined symbol errors on macOS 26.4+?
The README explains that GhosttyKit's pinned Zig 0.15.2 cannot link the macOS 26.4+ SDK, which dropped the arm64-macos slice from libSystem.tbd. Installing Xcode 26.3, which ships the macOS 26.2 SDK, resolves it; the build auto-detects and pins that Xcode for the build only.
What licence is Supacode under?
The repository reports NOASSERTION and the README only says to see LICENSE, so no SPDX identifier is stated. Read LICENSE and the ThirdParty directory directly before redistributing a build.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/supabitapp-supacode)