AI Agents

Built-in Agents

Daintree ships with fifteen AI coding agents. Each one runs as a CLI process in its own terminal panel with full PTY emulation.

Claude Code, Gemini CLI, and Codex CLI ship with default keyboard shortcuts. Every other agent is yours to bind in Keyboard Shortcuts. Most agents run on all three platforms. Three don't: Crush and Kiro CLI are macOS and Linux only, and Amp has no native Windows binary (npm or WSL).

Installing Agents

Each built-in agent is a separate CLI tool you install yourself. Daintree doesn't bundle the agent binaries; it launches and tracks them. Install and authenticate an agent and Daintree picks it up automatically, then pins it to the toolbar.

To see the install and authentication status of every agent on your system, open Settings > CLI Agents. The same panel links straight to each agent's install docs.

For an agent's install commands, authentication steps, and session resume details, see its own page, linked from the table above.

Launching an Agent

There are a few ways to launch an agent:

• Keyboard shortcut: press the agent's shortcut from the table above to launch it directly.
• Toolbar button: click the agent icon in the toolbar.
• Worktree card: use the agent launch buttons on any worktree card in the sidebar.
• Panel palette: open it with Cmd/Ctrl+N and select the agent type.

The agent launches in the active worktree's directory, so it has the right branch and working tree from the start. Every launch uses the agent's active preset for the current worktree, so flags, env vars, and provider settings are applied for you.

Agents that are installed but not pinned to the toolbar live in the Agent Tray, a dropdown next to the toolbar agent buttons. Agents that still need authentication show up there too, so there's always a path to finish setting one up.

Agent Tray

With fifteen built-in agents plus any custom ones you add, pinning every agent to the toolbar gets crowded fast. The Agent Tray keeps the toolbar clean. Daintree pins only the agents it has confirmed are installed and ready; the rest sit one click away in the tray.

The tray is the plug icon in the toolbar, next to the agent buttons. It shows up whenever there are installed agents that aren't pinned, or agents that need setup. Pin and authenticate every built-in agent and the tray button hides itself.

Launch Section

The Launch section lists installed agents that aren't pinned to the toolbar. Each row shows the agent icon, a running indicator if a session is already active, and a pin toggle. Click a row to launch the agent in the active worktree, or press P while a row is focused to pin it to the toolbar instead.

Rows are sorted by recent use in the Panel Palette, so the agent you reach for most sits at the top.

Agents in the Installed state (detected only inside WSL on Windows, not directly launchable) don't appear in the Launch section. They show up in Settings > CLI Agents with a "Not launchable" note instead, so the tray stays focused on agents you can actually run.

Needs Setup Section

The Needs Setup section collects agents in the Unauthenticated state: CLI installed and launchable, but with no credentials detected. Each row shows a greyed-out icon with an amber "Needs login" badge. Click a row to open Settings > CLI Agents scrolled to that agent so you can finish signing in. ("Needs Setup" is the tray section heading; "Needs login" is the row badge; "Needs setup" is the matching status pill in Settings. All three label the same Unauthenticated state.)

The Kiro false negative from the install section applies here too. Sign in to Kiro via AWS Builder ID or a social provider and it sits in Needs Setup permanently, even though it works fine.

Discovery Badge

When Daintree detects a newly installed agent it hasn't seen before, a small blue dot appears on the tray button. The dot clears the first time you open the tray, so you can tell at a glance when a freshly installed CLI has been picked up.

Pinning

Pinning and install state are tracked separately. Daintree pins an agent the first time it confirms the agent is installed and ready, so new installs land in the toolbar with no configuration. If an agent was installed before this detection pass (you installed it in another terminal after Daintree already checked, say) and it doesn't appear in the toolbar, open the tray and either launch it from the Launch section or pin it with the pin icon (or P). Unpinning works the same way. Unpinned agents stay in the tray, so you can still launch them on demand.

The tray footer has "Manage Agents…" (opens Settings > CLI Agents) and "Customize Toolbar…" (opens the toolbar customization panel) for anything the inline pin toggle doesn't cover.

Presets

Presets bundle flags, env vars, and behavior tweaks per agent so each launch is pre-configured. The three preset sources, per-worktree overrides, fallback chains, shared project presets, and provider templates are documented at Agent Presets.

Launch Hint vs Runtime Identity

Daintree separates what you asked to launch from what's actually running. The launch hint drives commands and flags. The live runtime identity drives the chrome you see. The distinction matters whenever a session pivots in place: an agent exits to a shell prompt, you type claude, and a new one starts in the same panel.

launchAgentId: The Request

This is the persisted agent ID for the panel. It's set when you launch, whether from the toolbar, the palette, or a shortcut. It drives:

• Command generation and restart
• Session-resume flags (a Claude resume always uses claude --resume)
• Preset, model, and settings lookup

It never drives chrome. The icon, color, badge, dock fade, and fleet eligibility all respond to the live process, not this field.

detectedAgentId: What's Actually Running

This one isn't persisted. It updates live from process-tree inspection and shell-keystroke detection inside the PTY host. It drives:

• Chrome rendering (icon, color, panel border)
• Focus navigation and refresh tier
• Dock fade and fleet-arming eligibility
• Activity monitor entries and orchestrator routing

Promotion and Demotion

A plain terminal becomes an agent panel the moment you type claude, or any registered agent command. It uses the same code path a toolbar launch uses. When the agent exits back to the shell, the panel demotes to a generic terminal. A demotion doesn't change the persisted launchAgentId, so resume still works the next time you relaunch from the toolbar.

Hold States

Two states don't mutate the committed identity:

• unknown: the detector cache returned an error.
• ambiguous: multiple detectors disagree about what's running.

In either case, Daintree holds the last committed identity until one detector wins. That keeps the chrome from flickering during normal launch and exit transitions.

Session Resume

When you close an agent panel, let its trash window expire, or quit Daintree, the app captures the agent's session ID from its terminal output. You pick up exactly where you left off instead of starting a fresh conversation.

To resume a session, open the Panel Palette (Cmd/Ctrl+N) and scroll to the Resume Sessions section at the bottom. Each entry shows the agent name, the model, and how long ago the session ran (e.g. "Sonnet · 2h ago"). Select one to re-launch the agent with the correct resume flag.

Daintree handles the resume syntax for you. It passes the session ID using each agent's own CLI flag:

Daintree stores up to 50 sessions per worktree and prunes anything older than 30 days. Sessions are scoped to the directory they were started in. Any launch flags from the original session (--dangerously-skip-permissions for Claude, say) carry over on resume, as does the active preset for the launching worktree.

For the full mechanics (the 20-second trash window, what gets saved, and what happens when a worktree is deleted), see Agent Session History.

Pre-Agent Snapshots

Every time an agent starts working, Daintree captures a snapshot of your working tree. If you had uncommitted changes or untracked files before the agent ran, that snapshot is a one-click restore point back to the exact state. There's nothing to set up. It happens in the background.

Daintree runs git stash push --include-untracked to capture all uncommitted changes and untracked files, then re-applies the stash right away so the agent has the full working tree to operate on. The stash entry stays in place as your restore point while the agent works.

One snapshot is stored per worktree. If an agent finishes and you start a second one on the same worktree without reverting, the original snapshot stays. Later agent starts won't overwrite an existing restore point.

Reverting Agent Changes

To roll back to the pre-agent state, open the worktree card context menu (the ... button) and select Revert Agent Changes. This discards every uncommitted change in the working tree, including edits you made after the agent ran, and restores the exact state captured at snapshot time. One click.

The menu item appears only on worktrees with an active snapshot and uncommitted changes. Once a revert succeeds, the menu item disappears and the snapshot is consumed. If the working tree was clean when the agent started, there's nothing to restore, so the revert option doesn't appear.

To review what an agent changed in detail before deciding whether to revert, use the Review Hub. It lets you inspect individual file diffs and stage changes selectively instead of reverting everything.

Edge Cases

• Conflicted files at agent start: if the working tree has unresolved merge conflicts when the agent launches, the snapshot is skipped and no menu item appears.
• Conflicts after revert: if applying the snapshot produces merge conflicts, Daintree completes the revert but warns that conflicts need manual resolution.
• Stash deleted manually: if the underlying git stash entry was removed before the revert (via git stash drop or similar), the revert fails and Daintree shows an error notification.
• Snapshot expiry: snapshots are pruned after 48 hours. The stash entry is dropped at the same point.

Daintree Assistant

The Help Agent is now the Daintree Assistant: a help pane that runs Claude or Codex inside the app, pointed at Daintree itself rather than your code. Open it with Cmd+L (macOS) or Ctrl+L (Windows/Linux), or with the Daintree icon in the toolbar.

It still answers questions and searches the docs, but it's no longer read-only. With your permission it can drive the app for you, launching agents, creating worktrees, and running recipes, all gated by a capability tier you set. For the full guide, see Daintree Assistant.

Agent Availability

Each agent resolves to one of five availability states. Daintree probes in layers: PATH first (which -a on macOS and Linux, where.exe on Windows), then known installer paths, then an npm-global bin probe for npm-distributed CLIs, then WSL on Windows for agents that ship a Linux binary. A separate authentication probe runs alongside, so Daintree can tell installed-but-not-signed-in apart from installed-and-ready.

Three helper predicates summarize how Daintree reads these states elsewhere in the app:

• isAgentLaunchable is ready or unauthenticated. Both can launch; unauthenticated agents prompt you to sign in on first use.
• isAgentInstalled is anything except missing. The binary is on disk, whether or not it can actually run.
• isAgentBlocked is blocked only. Used to surface the diagnostic banner.

For a full per-agent breakdown, open Settings > CLI Agents. The panel reports which detection step succeeded, the path Daintree is launching from, and what the auth probe looked for.

Agent State Tracking

Daintree reads each agent's terminal output in real time and tracks its state. States show up as badges on the worktree card and the terminal panel:

State detection works by pattern-matching terminal output. Each agent has its own set of patterns for prompts, streaming indicators, tool execution, and approval requests. The patterns are tuned per agent, so detection holds up across different CLI output formats.

CPU-Based Idle Detection

Sometimes an agent kicks off a long-running process like a compiler or test suite that produces no terminal output for a while. Rather than dropping to "idle" early, Daintree watches the process tree's CPU usage. If any child process is still active, the agent holds its current state until the work actually finishes. You don't see any of this: builds and test runs show the correct state without a false idle transition.

Activity Headlines

Beyond the state badge, each agent panel shows an activity headline, a short description of what the agent is doing right now (e.g. "Editing src/index.ts" or "Running tests"). These are generated from terminal output in real time.

State Chip Tooltip

Each agent panel header carries a small circular state chip, separate from the state badge on worktree cards in the sidebar. The chip's icon and color track the agent's current state:

The chip is hidden while the agent is idle. It also hides in the completed state when there's no session cost data.

If Daintree captured errors from the agent's terminal output, a small red dot appears at the top-right corner of the chip. The dot clears once the errors are dismissed from the panel.

When a session completes and cost data is available, the chip shows the session cost and token count as inline text next to the icon (e.g. $1.23 · 45k). That's the only case where session data appears outside the tooltip.

Tooltip Fields

Hover the state chip to open a tooltip with live session metadata. Every field is conditional and appears only when its data is available:

The duration text inside the State details field appears only for the working, waiting, and directing states, and only after the agent has been in that state for at least 10 seconds. That keeps a brief 0s from flashing the moment a state starts.

The change trigger tells you what caused the last state transition. The possible values are Input, Output, Heuristic, AI classification, Timeout, Exit, Activity, and Title. High-confidence triggers like Input and Output always sit at 100% confidence, so no percentage is shown. Lower-confidence triggers like Heuristic or AI classification show their confidence score.

Both the session elapsed time and the state duration refresh every 30 seconds, not in real time. A freshly opened tooltip can show a slightly stale value that catches up on the next refresh.

Notifications

When an agent enters the waiting state, Daintree notifies you through title bar and dock badges. For the full notification and sound system, see Notifications & Sound.

There are two main notification channels:

• Title bar badge: shows the count of agents needing attention, e.g. "(2) Daintree"
• macOS dock badge: the same count on the dock icon

Notifications clear when you focus the Daintree window.

Quit Confirmation

If you quit Daintree while any agent panel is in the Working or Running state, Daintree intercepts the quit and shows a confirmation dialog. The check runs on every quit attempt: Cmd+Q on macOS, Alt+F4 on Windows, or File > Quit on any platform.

The dialog is titled "Agents are working" and reports how many agents are currently active. It gives you two choices. Cancel (the default, keyboard-highlighted) dismisses the dialog and leaves everything running. Quit Anyway proceeds with a graceful shutdown.

Panels you've already closed don't count. If no agents are in the Working or Running state, no dialog appears and Daintree quits silently. OS-level signals like SIGTERM or a force-quit skip the dialog entirely.

Preventing System Sleep

While any agent is in the Working or Running state, Daintree keeps the system from sleeping. That stops macOS, Windows, or Linux power management from interrupting a long-running agent task. The block stays on until every agent has left those states. There's nothing to configure and no indicator shown.

Providing Codebase Context

Use CopyTree to give agents context about your codebase. Press Cmd+Shift+C to copy a structured snapshot to your clipboard, then paste it into any agent's terminal input. You can also right-click a worktree card and choose Copy Context to pick between full context and modified files only.

Send Selection to Agent

Select text in any terminal or agent panel and route it straight into another panel's input buffer, skipping the system clipboard. It's the fastest way to hand a snippet of agent output, an error message, or a shell result to another agent running in parallel.

There are three ways to trigger it:

• Right-click context menu: select text, then right-click and choose Send to Agent. The menu item appears only when text is selected in a PTY-backed panel.
• Keyboard shortcut: see the platform-specific shortcut below.
• Action palette: open it with Cmd/Ctrl+Shift+P and search for "Send to Agent" (the action is listed as "Send terminal selection to another agent or terminal panel").

The palette shows a searchable list of every other PTY-backed panel (agent and terminal panels). Each item shows the panel title; agent panels also show the agent name and icon. The list caps at 20 results, so use the search field to find a target if you have many panels open. Panels in the trash or running in the background are left out.

Panels with locked input (while an agent is actively working, say) still appear in the list, but greyed out with a lock icon. You can't select them as a target.

Daintree caches your selection as you highlight text, so the text doesn't have to stay highlighted when the palette opens. It uses the last selection you made in that panel. After sending, the cached selection sticks around, so you can route the same text to a second target without reselecting.

The selected text lands in the target panel's input buffer as if you'd typed it. It isn't submitted for you. Press Enter in the target panel to run it. Multi-line selections go through bracketed paste mode, so the content won't execute line by line on arrival.

To send the same input to multiple panels at once, see Bulk Operations.

Agent Updates

Daintree can check and update agent CLI versions. Updates run through:

• npm: npm install -g <package>
• Homebrew: brew upgrade <package>
• Custom command: a per-agent update command

Check current agent versions and manage updates in the agent settings.

Custom Agents

Beyond the fifteen built-in agents, Daintree supports custom agents through the user registry. Custom agents merge with the built-in registry and appear alongside them in every launch surface.

For each custom agent, you can set:

• Name: display name in the UI
• Command: the CLI command to execute
• Color: brand color for panel borders and badges
• Keyboard shortcut: quick-launch binding
• Context injection: whether CopyTree injection is supported

MCP Server

The sections above cover agents that run inside Daintree terminals. The MCP server flips that around: Daintree becomes the server, and external clients like Claude Code, Cursor, and Cline connect to it from outside. In-app help agents talk to the same server through internal sessions, gated by a per-project authorization tier.

Setup, the JSON config snippet, the four authorization tiers, time-bounded grants, rate limits, the audit log, and turn-outcome diagnostics are all documented at MCP Server.

Bulk Operations

Bulk Operations is the one-shot palette that sends a single keystroke, text command, or recipe to every selected agent terminal at once. Opening the palette, selecting worktrees, the keystroke/text/recipe modes, and per-worktree template variables are documented at Bulk Operations.