diri: a native workspace that runs coding agents side by side

Every agent can get its own worktree

Parallel agents on one checkout collide, and the isolation is the first thing diri addresses. Each agent can be given its own Git worktree and its own branch, so two agents editing the same function land in two trees instead of one index. That is a plain Git mechanism rather than a clever one, but pairing it with a process per agent is what makes it hold up under load.

The review loop is built around the same idea: inspect diffs, stage, commit and follow pull request checks beside the session that wrote the code. The emphasis is on in place review rather than on leaving the terminal to go look at a browser, and the description line of the project says as much, run in parallel and review in place.

There is no requirement to build a graph or adopt a session format. You bring the agents you already use, the worktrees are ordinary directories, and the commits are ordinary commits, so nothing here locks a repository into a tool specific history.

Closing the window does not kill the agents

The design claim about session lifetime is the one that separates this from a terminal multiplexer with a sidebar. Each terminal is owned by its own process, so closing the application, or restarting what the documentation calls the Engine, leaves every agent still running. The work does not stop because you closed a window, and it does not stop because the supervisor restarted.

The companion claim is about deployment. Run locally, or on any SSH host you control. The list of things you do not need is explicit: no tmux, no sudo, no Diri account, and no hosted relay. That last one is the load-bearing exclusion, since a hosted relay is what would otherwise let an operator see your terminal traffic.

The status model is the part you read all day. Live status and notifications separate working, waiting and finished sessions, so the question the sidebar answers is not what is happening but which sessions need a human. Waiting is separated from working precisely because a blocked agent asking a question is the case where dropping context costs you the most.

Agents spawn other agents over MCP

The built-in MCP server is what turns a set of parallel sessions into something that can decompose a task. With it, an agent can spawn other agents, hand them tasks, read their output and answer questions directed at them. The phrasing in the documentation is deliberately agent to agent: the questions an agent asks can be answered by another agent rather than escalating to you.

That changes what the worktree isolation is for. If you are running five independent tasks, separate worktrees prevent collisions. If one agent is splitting a specification into subtasks, the worktrees keep the subtasks from writing over each other while the parent waits. The dependency here is not enforced by the tool, but the two features were clearly designed to be used together.

It is also the feature to be careful with, because an agent that can spawn agents can spawn a lot of them. The stated ambition is dozens of agents in parallel today with a goal of hundreds, so any budget or rate limit you impose belongs outside diri.

Twenty two CLIs, two deep integrations

There is no bundled agent. diri runs the command line tools and the accounts you already have configured on the machine, and twenty two of them are recognised out of the box, with Claude Code, Codex, Cursor and Gemini named as examples. Nothing has to be re-authenticated inside the app because there is nothing to authenticate against.

Integration depth is not uniform, though, and the documentation is straight about which two get the most: Claude Code and Codex receive the deepest status and resume integration. Resume is the capability to watch. For the other twenty, the session still runs in your terminal, but the sidebar has less to say about it, so expect the status model to be less precise there.

Agent manifests are part of the contributor story rather than the user story, documented at docs/AGENT-MANIFESTS.md and listed among the changes the project welcomes. If your agent of choice is one of the unrecognised CLIs, a manifest is the sanctioned way to describe it.

Linux beta needs Vulkan 1.3 and a listed distro

The supported platforms are described precisely enough that you can tell in advance whether you are in scope. macOS 15 or newer is the primary target, on both Apple silicon and Intel, and the build is signed and notarized, which is what lets it install without a gatekeeper override. Linux is a beta with a hardware floor: x86_64, Ubuntu 22.04 or 24.04, X11 or Wayland, and Vulkan 1.3.

Two caveats sit with that beta. Linux packages are not included in every release, so a version that exists on the download page may not have a Linux artifact. And the limitations are collected in a separate guide at diri/LINUX.md rather than in the main documentation, which is where you should look before filing a bug that is really an unsupported configuration.

Installation on macOS is a single Homebrew cask:

brew install --cask cristicretu/diri/diri

The alternative is the disk image from the releases page, dragged into Applications, which is the path to take if you would rather not grant a package manager the install.

Notes are the next feature, not today's

The forward looking section describes notes as the next thing to build, and it is worth separating that from what the application does now. The plan is to write a product requirements document in a note, break it into to-dos, and send any to-do to an agent, with agents writing notes back. The stated intention is to let you stay at the level of the plan while the agents execute.

Nothing in the current documentation describes notes as a shipped feature, so treat the workflow as design intent rather than something to plan around today. The same section frames the problem honestly: agents are good enough now that the bottleneck is the human, specifically how many sessions one person can track and how much context they can hold.

There is a roadmap file at the repository root alongside the contributing, governance, support, security and privacy documents, which is where the sequencing lives if you want to see what is planned rather than what is described.

telemetry/ and ios/ exist with no front page explanation

The repository root is broader than the README. Alongside the expected files there are an ios/ directory, a telemetry/ directory, a sidecar/ directory, a plans/ directory, a website/ directory and a scripts/ directory. A native macOS application with a companion directory of that name, plus a web front end, is unremarkable.

Telemetry is the entry that deserves a question rather than a shrug. The repository contains a telemetry directory and a PRIVACY.md document, while the README itself does not say what is collected, whether it is on by default, or how to turn it off. Read PRIVACY.md before you point diri at proprietary repositories. This is a gap in the front page, not evidence of anything, and the answer is one file away.

The presence of AGENTS.md and a .claude/ directory at the root says the project dogfoods agent workflows in its own development, which is consistent with an agent manifest contribution path.

Three releases in three days around 0.9.0

The release cadence is the most recent signal in the repository and it is fast. v0.8.10 shipped on 2026-09-29, v0.8.11 the next day on 2026-09-30, and v0.9.0 on 2026-10-01, with the last push to the default branch later the same day. A minor version bump the day after a patch bump is the sort of pattern that comes from a project shipping to a small group of users on macOS, where a broken build is noticed immediately.

The practical consequence is that pinning a version matters. Read the release notes for the version you install rather than assuming the front page describes it, and expect the Linux package to lag, since it is not part of every release.

Licensing is Apache 2.0, with a NOTICE file for third party attribution and separate documents for privacy, security and support. Bug reports go through an issue template, ideas go to discussions, and the project asks for small, well tested changes with a reproducible bug or focused fix rather than large rewrites.

Editorial conclusion

diri fits someone already running several terminal agents who has lost track of which one is blocked, and it earns its keep on that problem alone: the per agent worktree and the session owned process are the two features that remove real collisions. It does not fit a single agent workflow, where the sidebar and worktree machinery are overhead, and the Linux path needs Vulkan 1.3 hardware and a distro from the supported list. Before you run real work through it, read PRIVACY.md and the telemetry directory rather than assuming, since the front page says nothing about what is collected, and pin the version, because three releases landed in the three days before this writing.

Frequently asked questions

Official sources

1. cristicretu/diri on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases