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.

Daintree is built around delegation and review: give agents separate tasks, monitor their work, inspect the resulting diffs, and decide what to merge. Review-first describes the workflow, not an enforced Git approval boundary. Agents are ordinary processes and can run Git themselves; repository permissions and branch protection still matter.

Daintree is a workspace rather than a full IDE or a VS Code fork. Its File Viewer provides read-only source, document, image, PDF and media previews. The File Browser finds and opens those files. Use Open in editor when you want to change a file yourself.

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 while preserving their native interfaces. 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 adds an interaction layer is Unified Input, which intercepts a few keys deliberately.

There is no first-class tier and degraded generic tier either. State detection uses shared machinery with provider-specific signals and capabilities. 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 belongs in the workflow

An agent reporting “done” is a claim to check. Use Review Hub to inspect changed files and staging, compare branches, and follow merge readiness and forge status. Run the relevant checks before accepting work.

Automation can go further: the Assistant can supervise agents, and plugins and recipes can operate repeatable workflows. Their permissions determine what they can do. Choose those permissions deliberately; the presence of a review surface does not force every agent, plugin, or external tool to use it.

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 ordinary working-copy edits stay separate. Shared services, databases, Git metadata and files outside those directories still need coordination.

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, which separates ordinary working-copy edits from your other checkouts. 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. Isolation depends on the environment and commands you provide; merely attaching a resource does not move a locally launched agent into it.
• Daintree itself. The MCP server ships disabled. Turned on, it binds to localhost only, behind three authorization tiers with host-side confirmation, time-bounded grants and an audit log. Plugins declare their capabilities in a manifest and prompt on first use of high-risk host APIs. Their main entry runs in a utility worker; optional React views run in the app renderer. 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.

A project can have its own tools

Project-level plugins travel with the repository under .daintree/plugins/. They can add a project home, panels, commands and integrations for a team’s own workflow: a release console, customer support workspace, data-quality dashboard or internal operations app. This is the mini SaaS idea: a focused platform inside a project. Hosting, accounts, billing and remote infrastructure must still come from your implementation. Cloning code does not automatically authorize it to run.

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. Opening without Git leaves repository setup untouched; choosing initialization proceeds to a dialog that can create Git metadata, a gitignore and an initial commit.

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 — or Option-Command-I ⌥⌘I Control-Alt-I Ctrl+ Alt+ I Control-Alt-I Ctrl+ Alt+ I for the same read scoped to one project and grouped by worktree, which is the view for a morning spent inside a single repository with six branches in flight. 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.

• Run your first parallel task: the whole model, once, in about fifteen minutes. Two worktrees, two agents, one review.
• 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.