Aizen: a macOS workspace for running branches and AI agents in parallel
Bring order to your projects, environments, and day-to-day work.
At a glance
- What is it?
- Aizen is a Swift and SwiftUI workspace for macOS 13.5+ that gives each project or branch its own terminal, files, browser and agent sessions. It is early access, Apple Silicon only, and version 1.0.83 is the last release before a breaking 2.0.0.
- Who is it for?
- Adopt Aizen if you work on an Apple Silicon Mac running macOS 13.5 or later, juggle several branches at once, and want agent sessions, diffs and CI runs attached to the worktree they belong to. Do not adopt it if you are on an Intel Mac, if you need Linux or Windows, or if you cannot tolerate the breaking 2.0.0 release the roadmap promises.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 45 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 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Aizen solves for people who keep several branches open at once
The problem Aizen targets is the manual bookkeeping that piles up when you work on more than one branch of the same repository. A worktree, a folder or a copy each needs its own terminal, its own editor buffer, its own browser tab for a local preview, and now its own agent conversation. Aizen's answer is to make that bundle the unit of work. The README describes it as a macOS workspace for parallel development and says each environment keeps its own terminal, files, browser, agent sessions, Git context and review state in one place. The audience is narrow and specific: developers on Apple Silicon Macs who already run coding agents from a terminal and want the surrounding context to follow the branch. If you only ever have one branch checked out, the product has little to offer you. The README also notes that Aizen can use Git worktrees, folders or copies under the hood, so the environment abstraction is not tied to one Git strategy.
How Aizen is put together: SwiftUI, actors, Core Data and libghostty
The repository layout in the README is the clearest description of the architecture. App/ is the entry point. Models/ holds data models for ACP, Git, MCP, tabs and terminals. Services/ is split by concern: Agent/ contains the ACP client, registry, installers and session management; Git/ covers worktrees, branches, staging, diffs, review and hosting; Audio/ handles voice recording and transcription; MCP/ manages MCP servers; Workflow/ integrates GitHub Actions and GitLab CI; Xcode/ handles builds and devices. Views/ mirrors that split with Chat, Worktree, Terminal, Files, Browser, Search, CommandPalette and Settings. GhosttyTerminal/ is a wrapper around libghostty, the terminal emulator from the Ghostty project, and the README calls the terminal GPU-accelerated. The stated patterns are MVVM with observable models, actor-based services for concurrency-sensitive work, Core Data for persistence, and SwiftUI with async/await and AsyncStream. Other declared dependencies are libgit2 for native Git operations, VVDevKit for editing, markdown, timeline, diff and Tree-sitter highlighting, and Sparkle for auto-updates. Two design choices stand out. Agent integration is ACP registry-first, with Claude Code, Codex and OpenCode seeded as defaults, and a custom agent can be added by command or executable path. Terminal persistence is optional and tmux-backed, which means session restore depends on tmux being available rather than on Aizen reimplementing it.
Installing Aizen and opening your first project
The README points at aizen.win for the download and states the build is signed and notarized with an Apple Developer certificate. Requirements are macOS 13.5 or later and an Apple Silicon Mac; Intel Macs are intentionally unsupported starting with 1.0.71. If you would rather build it yourself, the README lists Xcode 16.0+, Swift 5.0+ and Zig, installed with Homebrew, because GhosttyKit has to be compiled first.
git clone https://github.com/vivy-company/aizen.git
cd aizen
# Build GhosttyKit.xcframework (pinned to Vendor/libghostty/VERSION by default)
./scripts/build-libghostty.sh
# Open in Xcode and build
open aizen.xcodeprojBy default the build script pins GhosttyKit to the version recorded in Vendor/libghostty/VERSION. To build against a different commit, the README shows passing a SHA as the first argument:
./scripts/build-libghostty.sh <commit-sha>Once the app is running, the CLI is the fastest way to get a project in. Install the bundled CLI from Settings > General, then use the commands the README lists.
aizen open .
aizen workspace list
aizen terminal . --attach
aizen attachThe README says the CLI can add or open projects, inspect tracked workspaces, create persistent terminals, and attach to tmux-backed sessions created in the app. Settings > General is also where you pick a default external editor (VS Code, Cursor or Sublime Text) and enable the optional Xcode build button. Settings > Terminal covers font family and size, color themes and presets, the voice input button, and tmux session persistence. The README documents these keyboard shortcuts for terminal work: Command-D splits right, Command-Shift-D splits down, Command-W closes a pane, Command-T opens a new tab, Shift-Tab cycles chat mode, and Escape interrupts the agent.
Agent sessions, MCP servers and where the agent model is thin
The agentic side is the part the README leads with. Aizen uses ACP registry agents as the default path, seeds Claude Code, Codex and OpenCode, and lets you add more from Settings > Agents or supply your own command or binary. Sessions are per environment, so chat, tool calls and context stay attached to the project you are in. There is a built-in MCP marketplace for adding servers per agent, and the chat input accepts file attachments and on-device voice input with waveform visualization. What the README does not document is the shape of the ACP protocol itself, how a custom agent is expected to behave, or what happens to a session when the underlying worktree is deleted or rebased. Those are the questions to answer before you standardize a team on it. The registry-first approach is a reasonable bet, but it means your agent choice is bounded by what is registered or by how much work you are willing to do to wire up a custom command.
Where Aizen is the wrong tool
Three limits are stated plainly, and one is a consequence of the roadmap. The hard platform limit is Apple Silicon only, with Intel Macs intentionally unsupported from 1.0.71 onward for what the README calls a better user experience. There is no Linux or Windows build in the repository layout; the top-level entries are an Xcode project, Swift sources, a cli/ directory, scripts/ and a web/ directory. The second limit is the release cadence. The README carries an Early Access notice saying Aizen is under active development with near-daily updates and that breaking changes and new features should be expected frequently. The third is the roadmap line: 1.0.83 is the final release in the 1.0.x series, the next release will be 2.0.0, and it will not be backward-compatible with 1.0.x. For anyone who needs a stable toolchain, that is a real cost, not a footnote. Aizen is also a poor fit if your workflow is already organized around a single editor with a terminal panel and you do not run agents. The per-environment model only pays for itself when the number of concurrent contexts is greater than one.
How Aizen differs from a terminal multiplexer plus an editor
The obvious alternative is the combination most people already use: tmux or a terminal with split panes, plus an editor such as VS Code or Cursor, plus the agent running in one of those panes. The difference is where the state lives. In that setup, the branch, the pane layout, the browser tab and the agent conversation are four independent things you reassemble by hand each time you switch context. Aizen makes them one object: the environment. It also brings Git operations (stage, commit, push, pull, merge, branch), syntax-highlighted diffs with review comments, PR and MR detail views, and GitHub Actions and GitLab CI run status into the same window, and it adds Xcode build integration for .xcodeproj and .xcworkspace projects. The trade-off is control. A tmux and editor setup is scriptable, portable to Linux and replaceable piece by piece. Aizen is a single native macOS application, GPL-3.0 licensed, that you adopt or do not. Note that the README's tmux persistence option means Aizen does not fully replace a multiplexer; it can lean on one.
Licence and the cost of keeping up with 1.0.x
Aizen is released under the GNU General Public License v3.0, with the README listing copyright 2026 Vivy. If you only install the signed build from aizen.win, the licence governs the software you run; if you fork it or ship a modified version inside a product, GPL-3.0's source and copyleft terms apply, and that is a question for your own legal review rather than something this article can settle. The top-level repository also contains a CLA.md and a .clabot file, which indicates contributions are made under a contributor licence agreement; the README does not explain what that agreement permits. On upgrade cost, the release history shows v1.0.81 on 2026-04-16, v1.0.82 on 2026-05-22 and v1.0.83 on 2026-07-25, roughly monthly, while the README describes near-daily development. The last push to the default branch was on 2026-08-01. The roadmap says 2.0.0 will not be backward-compatible with 1.0.x, so anything you build on 1.0.x configuration or CLI behaviour should be treated as having a known expiry. The README does not document a migration path from 1.0.x to 2.0.0.
Editorial conclusion
Adopt Aizen if you work on an Apple Silicon Mac running macOS 13.5 or later, juggle several branches at once, and want agent sessions, diffs and CI runs attached to the worktree they belong to. Do not adopt it if you are on an Intel Mac, if you need Linux or Windows, or if you cannot tolerate the breaking 2.0.0 release the roadmap promises. Before committing, verify that the libghostty build script completes on your machine, that the agents you rely on are present in the ACP registry or can be added as a custom command, and whether 1.0.83 or 2.0.0 is the version you are actually installing.
Frequently asked questions
How do I use Aizen's CLI to open a project?
Install the bundled CLI from Settings > General, then run aizen open . in the project directory. The README also lists aizen workspace list, aizen terminal . --attach and aizen attach, and says the CLI can add or open projects, inspect tracked workspaces, create persistent terminals, and attach to tmux-backed sessions created in the app.
Does Aizen run on Intel Macs?
No. The README lists an Apple Silicon Mac as a requirement and states that Intel Macs are intentionally unsupported starting with 1.0.71 for a better user experience. The minimum OS is macOS 13.5.
What agents does Aizen support out of the box?
Aizen uses ACP registry agents as the default path, and the seeded defaults are Claude Code, Codex and OpenCode. More agents can be added from Settings > Agents, and a custom agent can be supplied as a command or executable path.
Will Aizen 2.0.0 break my 1.0.x setup?
The README's roadmap states that 1.0.83 is the final release in the 1.0.x series and that the next release will be 2.0.0 and will not be backward-compatible with 1.0.x. The README does not document a migration path.
Community notes