AI Agents

Built-in Agents

Daintree ships with seventeen launchable built-in agents. Each one is a third-party CLI that Daintree runs as a process in its own terminal panel with full PTY emulation. Daintree does not bundle the binaries and does not wrap the models — it launches the CLI you already installed, watches its output, and gives it a place in the habitat.

Antigravity (agy) and Grok are the newest additions. Antigravity is Google's successor to the retired Gemini CLI and reads the same ~/.gemini/ credentials; Grok is xAI's CLI.

There is an eighteenth entry in the registry, daintree-assistant. It is assistant-only: Daintree detects it and the Daintree Assistant uses it, but every launch surface filters it out, so it is never offered as a coding agent. That is why the roster is seventeen and not eighteen.

Three agents ship default keyboard shortcuts: Claude Code (Option-Command-C ⌥⌘C Control-Alt-C Ctrl+ Alt+ C Control-Alt-C Ctrl+ Alt+ C ), Gemini (Option-Command-G ⌥⌘G Control-Alt-G Ctrl+ Alt+ G Control-Alt-G Ctrl+ Alt+ G ), and Codex (Option-Command-X ⌥⌘X Control-Alt-X Ctrl+ Alt+ X Control-Alt-X Ctrl+ Alt+ X ). Every other agent has a launch action with no combo bound to it, ready for you to claim in Keyboard Shortcuts or from the launcher itself. Most agents run on all three platforms. Crush and Kiro CLI ship install paths for macOS and Linux only, and Amp has no native Windows binary (npm or WSL).

View full size:

Installing and Launching

Daintree does not bundle any agent. It detects the CLIs you have installed, gates the launch when one is missing, and starts the agent in the selected worktree. Installing each CLI, the searchable launcher, alt-screen versus inline rendering and permission bypass are all covered at Installing and Launching Agents.

Presets

Presets are per-agent launch configurations: flags, environment variables, a model, a display title, a color, and overrides for the bypass and screen-mode decisions above. Sources, per-worktree defaults, fallback chains, shared project presets, and provider templates are documented at Agent Presets.

Agent States

Daintree reads each agent's PTY output and tracks what it is doing — idle, working, waiting, directing, completed, or exited — along with why a waiting agent is waiting. Those states drive worktree card badges, the sidebar filters, Fleet, Pilot, and notifications. The full reference is at Agent States.

Launch Hint vs Runtime Identity

Daintree separates what you asked to launch from what is actually running. The distinction earns its keep whenever a session pivots in place: an agent exits to a shell prompt, you type claude, and a different agent starts in the same panel.

The launch hint (launchAgentId) is persisted with the panel. It drives command generation, restart, resume flags, and preset and model lookup. It never drives what you see.

The runtime identity (detectedAgentId) is not persisted. It is resolved live from the process tree — by the executable's image path rather than its window title or argv, because CLIs rewrite both — and it drives the chrome: icon, color, panel border, dock fade, focus navigation, and fleet-arming eligibility.

A plain terminal is promoted to an agent panel the moment you type a registered agent command, through the same code path a launcher launch uses. When the agent exits back to the shell, the panel demotes to a generic terminal. Demotion does not touch the persisted launch hint, so resume still works the next time you relaunch.

Session Resume

Closing an agent panel, letting its trash window expire, or quitting Daintree does not end the conversation. Daintree records a resumable session and offers it back in the launcher's Resume Sessions list, with the correct resume flag for that agent's CLI filled in for you.

Session ids are assigned at launch rather than scraped at teardown, which is why they survive a crash, a force quit, or a SIGKILL. Not every CLI supports resume: Cursor and Crush have none, Kiro resumes per directory, and Aider, Open Interpreter, and Kimi Code roll a history file forward instead of keying on an id. The per-agent syntax is on each agent's page; the journal, retention, bookmarks, and the trash window are documented at Resuming a Closed Agent Conversation.

Moving a project

A project folder can be moved or renamed from inside Daintree, and whether an agent's conversation survives that is a property of how its CLI stores history. Daintree classifies each agent before the move and shows the verdict in the relocation preview, so you find out beforehand rather than on the next resume:

• Preserved — the session id is globally addressable, so it resumes at the new path (Codex, GitHub Copilot).
• Travels with the project — the history file lives inside the folder and moves with it (Aider).
• Needs a manual step — the conversation still exists on disk, but the provider cannot resume it at a new path. Claude Code's store is keyed by a path slug; Kiro's by an absolute path. Daintree will not reach into a provider's private store to fix that.
• Unavailable — no usable resume path across a move (Gemini CLI, Crush).

An agent Daintree has not classified is reported as unverified rather than assumed safe.

Models and Context Windows

Each agent's model list and context window come from its registry entry, and for the providers covered by the public models.dev catalog — Anthropic, OpenAI, Google, Alibaba, and Mistral — the list is refreshed at runtime, so a newly released model appears without a Daintree update. Agents that broker several providers at once, GitHub Copilot and Aider, stay on their bundled snapshot because there is no single provider to look up.

Plugin-Contributed and Custom Agents

The built-in roster is not the whole list. A plugin can register agents of its own through contributes.agents, gated by the agent:register capability. A plugin-contributed agent is a first-class agent: it appears in the launcher, launches into a worktree, takes presets, and drives the working/waiting/completed state UI. A plugin may also declare output-detection patterns for its agent, which sharpen prompt and completion detection beyond what output volume alone can tell.

Plugin agents merge into the effective registry at the lowest priority. They are purely additive for new ids and can never shadow a built-in, so installing a plugin cannot quietly change what claude means.

Daintree also carries a user registry for custom agents — an id, a display name, a command and args, a color, an icon, a shortcut, and whether the agent accepts injected context. Custom agents sit above plugin agents and below built-ins in the same merge, and appear alongside them in every launch surface.

Completions

Daintree's unified input can complete an agent's own commands as you type. What it offers is declared per agent in the registry rather than guessed, so each CLI gets its real vocabulary: Claude Code, Codex, and Gemini declare completion sources today.

Codex is the richest of the three. Its / trigger lists built-in slash commands; its $ trigger surfaces Codex Skills and Plugins together, each row badged with its category and scope, discovered from your CODEX_HOME (system, user, and the project's .agents/skills) and from the enabled entries in your Codex plugin registry. A skill you wrote wins a name collision against a plugin of the same name. Codex Apps are modeled in the same item shape but resolve server-side, so they do not appear in local discovery yet.

Quitting While Agents Work

If any agent is in the working state when you quit Daintree, the quit is intercepted and a dialog titled "Agents are working" reports how many. Cancel is the default; Quit Anyway proceeds with a graceful shutdown. Agents that are waiting, directing, idle, or finished do not trigger it — nothing is in flight, so stopping costs nothing. OS-level signals such as SIGTERM and a force quit skip the dialog entirely.

While at least one agent is working, Daintree also asks the OS not to suspend the app, so power management does not interrupt a long-running task. The block lifts as soon as the last agent stops working, and releases itself after four hours regardless, so a wedged run cannot hold your machine awake indefinitely. There is nothing to configure.

Broadcasting to Many Agents

To drive several agents at once — arming terminals, previewing what a broadcast will send to each worktree, and running the destructive fan-out actions across an armed set — see Fleet. There is no separate bulk-operations palette; those actions live in Fleet.

Sending Context to an Agent

Use CopyTree to hand an agent a structured snapshot of the codebase: Shift-Command-C ⇧⌘C Control-Shift-C Ctrl+ Shift+ C Control-Shift-C Ctrl+ Shift+ C copies one to the clipboard, and the Copy Context control on a worktree card offers full context or modified files only, backed by per-project history.

Send selection to another panel

To move text between panels without the clipboard, select it in any terminal or agent panel and press Shift-Command-E ⇧⌘E Control-Shift-E Ctrl+ Shift+ E Control-Shift-E Ctrl+ Shift+ E (or right-click and choose Send to Agent). A searchable list of the other PTY-backed panels appears; the text lands in the target's input buffer as if typed, unsubmitted, so you press Enter yourself. Panels whose input is locked are listed but not selectable.

Daintree Assistant

The Daintree Assistant is a help pane that runs an agent CLI inside the app, pointed at Daintree itself rather than at your code. Open it with Command-L ⌘L Control-L Ctrl+ L Control-L Ctrl+ L or from the toolbar. It answers questions, searches the docs, and — with your permission, gated by a capability tier you set — drives the app for you. It runs on its own agent selection and its own permission settings, separate from everything above. See Daintree Assistant.

MCP Server

Everything above is about agents running inside Daintree. The MCP server inverts that: Daintree becomes the server, and external clients connect to it from outside to read and act on your habitat. Setup, the tool tiers, authorization, and the audit log are documented at MCP Server.