What Is a Habitat?

A habitat for your AI agents

A habitat is a desktop workspace that hosts AI coding agents. It's the one window where you run Claude Code, Codex, OpenCode, Antigravity, and the rest side by side, watch what they're doing, and decide what to keep. Daintree is the habitat. This page explains the mental model before you reach the detailed UI docs, so the rest of the documentation lands on something solid.

The single idea underneath everything: generation is cheap, review is the bottleneck. Agents can write more code than you can read in a day. So the habitat is built around the part that's actually hard. Daintree is review-first, which means human review is the control gate before any code merges. You delegate the work, monitor it as it runs, review the changes as diffs, and merge the result yourself. Nothing reaches your main branch on its own.

Daintree is not an editor. There's no VS Code fork inside it and no editing surface at all. It's built for one job: delegate work to agents in parallel, supervise them in one place, and review their changes before you merge. If you already run agents from a terminal, you're doing this today across a pile of tabs. The habitat is the same workflow with the isolation and the review gate built in.

That holds even though you can now read files inside Daintree. The File Viewer and the File Browser both render source, images, PDFs, and media, and both are read-only. Reading is part of reviewing; typing into a file is not. Read anything you like here, then edit it in your editor.

Real CLIs, not wrappers

Daintree launches the actual agent binary. Starting Claude Code in a worktree runs claude in a real PTY, reading the configuration it already reads and authenticated against the subscription you already pay for. The same goes for Codex, Antigravity, OpenCode and the rest. Nothing is reimplemented, and nothing is translated through an intermediate protocol on the way.

That decision is why the habitat can host seventeen agents without seventeen integrations quietly rotting in parallel. When an agent CLI ships something new, you get it the next time you update that CLI, not the next time Daintree ships a release. Your slash commands and agent configuration work as they do in a terminal, because it is a terminal. The one place Daintree does sit in front of the CLI is Unified Input, which intercepts a few keys deliberately.

There is no first-class tier and degraded generic tier either. State detection reads terminal output the same way for all seventeen built-in agents. A plugin agent joins the same machinery as soon as it declares a detection block in its manifest, and then gets the same status chips, the same notifications and the same place in Pilot that Claude Code gets. Without one it runs as a plain named terminal that Daintree does not track.

Review-first, not autonomous

Review-first means the human review step lives inside the delegation loop, not bolted on after the fact. An agent doesn't open a PR and walk away. It produces changes in an isolated branch, and those changes wait there until you've looked at them. You compare what each agent did, pick the strongest result, and merge it.

That's the opposite of full autonomy. Daintree doesn't try to make agents run unsupervised while you sleep. The whole point is that you stay in control of what ships, with a clean surface for reviewing it. Agents do the typing. You make the merge decisions.

The gate matters because an agent reporting "done" is a claim about its own work, not evidence about your repository. Often it is right. It can also mean the tests were never run, that files changed well outside what you asked for, or that the code compiles and does the wrong thing confidently. Review Hub is where that gets settled: the diff for every changed file, merge readiness, and CI status from your code forge sitting next to the branch it belongs to.

Parallel delegation

The habitat is designed for running several agents at once. Each task gets its own isolated Git worktree on its own branch, so agents work at the same time without colliding or contaminating each other's changes. One agent refactoring a module and another fixing a bug never touch the same files in the same place.

You launch agents into their worktrees and watch their live state in one window: which agent is working, which is waiting, which is blocked, and which one needs your direction. The work stays cleanly separated until you decide to merge it. No alt-tabbing between terminals, no guessing which window is doing what.

Worktree isolation also keeps each agent's working context intact. Restarting one agent doesn't disturb the others, and the branch each one is on preserves its state independently.

How much rope an agent gets

Isolation is not only about agents colliding with each other. It is also about what one agent can reach when it goes wrong, which is the thing that stops most people turning permission checks off and walking away from the machine.

The habitat gives you three places to draw that line, and each one is a separate decision.

• The work. An agent works on one branch in one checkout, so concurrent agents never overwrite each other and nothing lands in the tree you are working in. Be precise about what this is, though: a worktree isolates the changes, not the process. The agent still runs as your user account and can reach the rest of your filesystem like any other program you start.
• The machine. A worktree can carry its own resource environment, so the work happens in a Docker stack, a cloud VM or a remote sandbox instead of on your laptop. You describe how to provision, pause and tear it down, and Daintree runs those commands as part of the worktree lifecycle. This is the level that gives you real process isolation, and the one to reach for before you turn permission checks off.
• Daintree itself. The MCP server ships disabled. Turned on, it binds to localhost only, behind four authorization tiers with host-side confirmation, time-bounded grants and an audit log. Plugins declare their capabilities in a manifest, run out of process, and prompt on first use of the high-risk host APIs. That page also states plainly what the model does not guarantee, including that plugin code itself is not sandboxed.

How the pieces fit together

There are five pieces, and each has a clear role. Together they form one workflow.

• Project: a folder you open in Daintree. It's the top-level container for everything else. Whether it's a Git repository is a property of the folder, not a condition of opening it.
• Worktrees: isolated branches where the work happens, once the project is a repository. Each one is a separate checkout, so tasks run in parallel without stepping on each other.
• Agents: the CLI coding tools that do the work. Each runs as a process in its own panel, with live state detection so you can see what it's up to.
• Review Hub: where you inspect the diffs. Compare what each agent changed, decide which worktree to merge, and merge it.
• Pilot: the layer above all of it. The project switcher picks one project; Pilot shows every agent run across every project at once.

So the flow is:

1. Open a folder. Point Daintree at any local directory.
2. Create worktrees. Each task gets its own isolated branch.
3. Launch agents. Run one or more agents in parallel across your worktrees.
4. Review the diffs. Inspect every change in Review Hub before anything moves.
5. Merge the best result. You decide what ships.

What a project needs

A project used to have to be a Git repository. It doesn't any more. Open a folder with no repository in it and Daintree asks a two-option question rather than blocking you: Initialize repository, or Open without git. Nothing in the folder is changed either way.

That split is now part of the mental model, because it decides which of the pieces above you get:

• Any folder gets terminals, agents, recipes, and the file browser. That is enough to delegate work and watch it run.
• A Git repository adds worktrees, review, and diffs: the isolation and the review gate. Without a repository there are no branches to isolate onto and no diff to gate on, so those surfaces stay unavailable rather than pretending.

git init is therefore an upgrade you choose, offered up front and available later from the sidebar. There is also a shape with no project at all: a scratch workspace, a throwaway directory for a one-off task that you name, use, and delete. See Projects for both.

When you're delegating across projects

Everything above describes one project. Parallel delegation doesn't stay inside one for long. Once you have agents running in four repositories, the question stops being "what is this agent doing" and becomes "which of the twenty things I started needs me now". No amount of switching between projects answers it, because the answer is never in the project you're looking at.

Pilot (Option-Command-O ⌥⌘O Control-Alt-O Ctrl+ Alt+ O Control-Alt-O Ctrl+ Alt+ O ) is the read across all of them: every agent run you have open, grouped by project, with how long each has been waiting. It's a monitoring surface, not a control surface. You use it to find the one that needs a decision and jump straight to it.

Where to go next

That's the model: a review-first habitat where agents run in parallel and you stay the gate. The rest of the documentation fills in the mechanics.

• Installation & Setup: install Daintree, set up your agents, and open your first folder.
• Projects: opening folders, the git-optional tier, cloning, and scratch workspaces.
• Worktrees: creating and managing the isolated branches agents work in.
• AI Agents: launching, monitoring, and configuring the agents themselves.
• Review Hub: inspecting diffs and merging agent changes.
• Pilot: every agent run across every project, in one list.