diri: a native macOS workspace for running coding agents in parallel
A native workspace for coding agents. Run in parallel, review in place.
At a glance
- What is it?
- diri is a Rust and GPUI desktop app that runs Claude Code, Codex, Cursor and Gemini side by side, gives each task its own Git worktree, and shows diffs beside the session. It is macOS-first, with Linux in beta, and it installs through a Homebrew cask.
- Who is it for?
- diri suits engineers who already run terminal coding agents and are tired of juggling terminal tabs and stashes: the worktree-per-task model and the live session status are the reasons to install it. Skip it if you are on Windows, or if you expect it to supply model access, since the README says you install your agent CLIs separately and Diri uses the accounts already on your machine.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 18, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What problem diri solves, and for whom
Running one coding agent in a terminal is easy. Running four of them on the same repository is not. They write to the same files, they block on the same branch, and you lose track of which one is waiting for your approval and which one is still working. diri is built around that specific mess. The README describes it as "a native workspace for coding agents" and lists the intended workflow: run Claude Code, Codex, Cursor, Gemini and other terminal agents side by side, see what needs you, give each task its own worktree, and review changes in place.
The audience is narrow and identifiable. You already use a terminal agent and you already use Git. diri does not provide a model, an API key or a hosted runtime. The README is explicit that you install your agent CLIs separately and that Diri uses the tools and accounts already on your machine. It adds a desktop layer over processes you were going to start anyway. If your work is a single agent on a single branch, the app has little to offer beyond a nicer terminal.
The mechanism: worktrees, sessions, and a status layer
Three mechanisms carry the product. The first is isolation through Git worktrees: the README says you can "give agents their own Git worktrees and branches", so two agents editing the same repository do not collide in the working tree. The second is a session model with live state. The README states that live status and notifications "distinguish working, waiting, and finished sessions", which is the part that replaces watching four terminals. The third is in-place review: inspect diffs, stage changes, commit, and follow pull request checks beside the session.
Persistence is handled outside the window. According to the README, local sessions keep running when you close the app or the Engine restarts, so closing the window is not a kill signal. The architecture is split between a native app built with Rust and GPUI and a component the README calls the Engine, plus a sidecar directory and an ios directory in the repository layout. Agents run under your user account in real terminals, and the README states that no Diri account or hosted relay is required. Remote execution goes over SSH to a host you control, with Diri handling remote Helper setup. The README notes that remote session persistence depends on the host and that Diri reports its persistence capabilities, which is an honest boundary rather than a guarantee.
Installing diri and starting a first session
The README gives one install path for macOS: a Homebrew cask. macOS 15 or newer is required, on Apple silicon or Intel, and the build is signed and notarized.
brew install --cask cristicretu/diri/diriIf you prefer not to use Homebrew, the README says you can download the DMG from the releases page and drag Diri to Applications. Either way, the agent CLIs are your responsibility: install Claude Code, Codex or whichever terminal agent you use before opening the app, because diri does not bundle them. The README adds that Claude Code and Codex have the deepest status and resume integration, so a first run with one of those two will show more of the product than a less integrated agent will.
Linux is a separate story. The README labels it beta and names x86_64 Ubuntu 22.04 and 24.04, X11 or Wayland, and Vulkan 1.3. It points to the Linux guide at diri/LINUX.md for packages, source builds and limitations, and warns that Linux packages are not included in every release. There is no Windows path in the README at all.
Where diri stops being the right tool
The clearest limitation is platform. macOS 15 or newer is the supported target, Linux is beta with a named distribution range and a Vulkan 1.3 requirement, and Windows does not appear in the README. If your team is on Windows, this is not a tool you evaluate further.
The second limitation is integration depth. The README says Claude Code and Codex have the deepest status and resume integration, which implies that other terminal agents get less of the status and resume behaviour that makes the session list useful. A workflow built entirely on an agent outside that pair will see a thinner product.
The third is remote persistence. The README states that remote session persistence depends on the host and that Diri reports its persistence capabilities. That means the promise that sessions keep running when the app closes is a local guarantee; over SSH it is contingent on the machine on the other end. If your workflow assumes a remote session survives a disconnect, verify the host's capabilities before you rely on it. And if you want a hosted service that runs agents for you, diri is the wrong shape entirely: it is a local app over your own accounts and your own machines.
How it differs from tmux plus Git worktrees
The obvious alternative is the manual stack: a terminal multiplexer for parallel sessions and git worktree add for isolation. That combination is free, scriptable and works on any platform, and it gives you exactly the same two primitives. The difference is what sits on top. With tmux you decide what a session's state is by reading its output; with diri the README states that live status and notifications distinguish working, waiting and finished sessions, and that Claude Code and Codex get resume integration. You also get diffs, staging, commits and pull request checks in the same window as the session, rather than switching to a separate Git client.
The trade is control. A tmux setup is transparent: you can read the configuration, version it, and reproduce it on a server. diri is a signed desktop application with its own Engine and Helper components, and its remote behaviour is defined by what the README calls the host's persistence capabilities. If you value being able to explain every part of your agent environment, the manual stack wins. If you value not having to build the status layer yourself, diri is the thing you would otherwise be writing.
Maintenance, licence, and what an upgrade costs
The repository is not archived, and the last push was on 2026-09-16. Releases have been frequent: v0.7.2 on 2026-09-13, v0.7.3 on 2026-09-14, and v0.7.4 on 2026-09-15. A version series still in the 0.7 range moves quickly, and the release cadence suggests you should expect to update rather than pin. The README's Linux note that packages are not included in every release is the concrete cost of that cadence: on Linux you may need to build from source, following diri/LINUX.md, for a release that ships no package.
The licence is Apache-2.0, with a NOTICE file for third-party components. Apache-2.0 is permissive and includes a patent grant, which matters if you embed or redistribute the app inside a company. It also carries obligations around preserving notices, which is why the NOTICE file exists. That is the shape of the licence, not advice about your situation; if you plan to redistribute a modified build, have someone qualified read LICENSE and NOTICE. The project also publishes PRIVACY.md and SECURITY.md, so there are stated positions on data handling and vulnerability reporting rather than silence. Upgrade cost is mostly operational: because the app wraps external CLIs, an agent CLI update can change behaviour that diri's status integration depends on, and the README does not document a compatibility matrix for those versions.
Editorial conclusion
diri suits engineers who already run terminal coding agents and are tired of juggling terminal tabs and stashes: the worktree-per-task model and the live session status are the reasons to install it. Skip it if you are on Windows, or if you expect it to supply model access, since the README says you install your agent CLIs separately and Diri uses the accounts already on your machine. Before adopting, check the Linux guide at diri/LINUX.md for current limitations and confirm whether the release you want ships a Linux package, since the README states Linux packages are not included in every release.
Frequently asked questions
Does diri include the coding agents, or do I install them separately?
You install your agent CLIs separately. The README states that Diri uses the tools and accounts already on your machine, and that Claude Code and Codex have the deepest status and resume integration.
Which platforms does diri support?
macOS 15 or newer on Apple silicon and Intel is the supported target, installed through the Homebrew cask or the DMG. Linux is beta for x86_64 Ubuntu 22.04 and 24.04 with X11 or Wayland and Vulkan 1.3, and the README does not list Windows.
Do my agent sessions keep running when I close diri?
The README states that local sessions keep running when you close the app or the Engine restarts. For sessions on an SSH host it says persistence depends on the host and that Diri reports its persistence capabilities.
Do I need a diri account or a hosted service to use it?
No. The README states that agents run under your user account in real terminals and that no Diri account or hosted relay is required. Remote work runs on an SSH host you control, with Diri handling remote Helper setup.
Community notes