Global Settings

Global settings cover 20 tabs across five sidebar groups: General, Terminal, Assistant, Integrations, and Support. They apply to Daintree as a whole, regardless of which project is open. For the per-project layer that overrides them, see Project Settings.

This page is a map, not a field-by-field mirror of the dialog. Each tab gets a line on what you'd come here to change, and where a subsystem has its own page, the link goes there instead of repeating it.

The 20 tabs

View full size:

General group

General

Three subtabs: Overview, Hibernation, and Display.

Overview is the orientation page: the Daintree version, a System status panel listing each detected agent CLI with a Ready, Needs Setup, or Blocked badge, the update channel, and a collapsible Quick reference card of essential shortcuts. Agents you don't have installed stay off the list; a "Daintree supports N more agent(s)" link beneath it opens CLI agents so you can see the rest of the roster. Clicking an agent row jumps straight to that agent's subtab.

The Update channel selector is Stable or Nightly. It disappears entirely on builds whose updates are managed by an app store, because the choice isn't Daintree's to make there. See Updates for how releases are delivered.

Hibernation holds three background-memory controls:

• Auto-hibernation pauses a project you haven't touched after 12, 24 (default), 48, or 72 hours. Off by default.
• Auto-close idle projects reclaims memory from background projects that have no open terminals and have been idle past a threshold. They stay in the switcher and reopen where you left off.
• Idle terminal notifications raises a toast once every terminal in a background project has been idle past its threshold. On by default. Covered in Notifications & Sound.

Display has four toggles for visual indicators across the app:

• Project Pulse (on) shows a commit activity heatmap on the empty panel grid
• Developer Tools (off) adds a problems panel button to the toolbar
• Grid Panel Agent Highlights (off) shows colored borders on grid panels when agents are waiting or working
• Dock Item Agent Highlights (off) shows colored borders on dock items when agents are waiting

Failed-state borders are always drawn regardless of either highlight toggle. A failure is not decoration.

Appearance

Two subtabs. App holds the theme picker (14 built-in themes, seven dark and seven light), an accent color override that swaps the active theme's accent without editing the theme, a color vision selector (Default, Red-Green, Blue-Yellow), and Dock density (Compact, Normal, Comfortable). Terminal holds the terminal color scheme, font size (8–24px), and font family (bundled JetBrains Mono or system monospace).

See Theme System for the theme list, auto-switching, authoring, and sharing.

Keyboard

View, search, and rebind every shortcut. Click a binding to record a new one; conflict detection warns when the combination is already taken. Shortcut profiles import and export as JSON, and shortcuts reset one at a time or all at once.

See Keyboard Shortcuts for the full reference and the profile system.

Notifications

Which agent events raise a notification, which sounds they use, and the quiet-hours window. See Notifications & Sound for the whole system, including per-project overrides.

Privacy & Data

Two subtabs: Telemetry and Data & Storage.

Telemetry has three levels, each with a disclosure listing exactly what it transmits:

• Off: nothing is collected or sent, crash reports included
• Errors Only: crash reports and error details, no usage analytics
• Full Usage: crash reports plus anonymous usage analytics

Crash reporting is configured here rather than under Troubleshooting, because it is a privacy decision before it is a diagnostic one. At Errors Only, crash reports go to Sentry with home-directory paths redacted from stack frames and messages; the payload is the exception type and message, sanitized stack frames, app and Node versions, OS name and architecture, standard Electron SDK runtime metadata, and main-process breadcrumbs preceding the crash. Full Usage adds a fixed set of anonymous onboarding and activation events, each carrying a name, timestamp, and event-specific properties. File contents, prompts, and credentials are never included at any level.

For sampling rates and the pre-consent buffering rules (how events queued during first launch are handled once you pick a level), see Telemetry & Privacy.

Data & Storage holds the destructive and semi-destructive controls:

• Data folder shows the path to Daintree's data directory, with an Open Folder button
• Log retention: 7 days, 30 (default), 90, or keep forever. Pruning runs at startup.
• Session history sets how long resumable agent-session records are kept, on the same 7/30/90/forever scale, and offers a Clear session history button. Both apply to every project; shortening the window prunes older records immediately. Bookmarked sessions survive a clear. Deleting the bookmark is the only way to remove one.
• Hidden commands restores commands you've hidden from "Recently used" in the action palette
• Clear cache removes HTTP and code caches without touching settings
• Reset all app data permanently deletes settings, API keys, session data, and logs

Terminal group

Panel Grid

Five subtabs: Performance, Input, Layout, Scrollback, and Accessibility.

Performance:

• Performance mode cuts scrollback to a fixed low value and disables animations
• Resource monitoring shows per-terminal CPU and memory in panel headers
• Memory leak detection warns when a terminal's memory grows continuously, and can auto-restart it past a configurable threshold. Requires resource monitoring.
• Panel limits sets how many panels you can open at once. Defaults are auto-detected from RAM and CPU cores. Three levels: a warning banner, a confirmation past a batch spawn, and a hard limit that can't be bypassed. The first two can be turned off; the hard limit always applies.
• Cached project views (1–5) sets how many projects stay in memory for instant switching. The default is picked from system RAM on first launch, and the adaptive resource profile can clamp it lower under pressure, so the number you set is a ceiling, not a guarantee. See Cached Project Views and Performance.

Input controls the hybrid input bar above agent terminals, plus a Default focus target toggle that decides whether selecting an agent panel starts focus in the input bar or in the terminal. Clicking either one still wins, and Option-Command ⌥⌘ Control-Alt Ctrl+ Alt Control-Alt Ctrl+ Alt +arrow follows whichever you're using.

Layout holds the two-pane split (on by default, with a preview-focused 65/35 variant, a default-ratio slider, and a reset for every saved per-worktree ratio) and the grid layout strategy for three or more panels: Automatic (default), Fixed Columns, or Fixed Rows.

Scrollback sets the base history buffer: 500, 1,000 (default), 2,500, or 5,000 lines. Agent terminals scale to 10× that base, capped at a 10,000-line policy maximum (raised from 5,000 in v0.28) and lowered further under the Efficiency resource profile; shell and dev-server terminals scale to 0.3× the base instead, capped at 2,000. An expandable estimate shows memory per terminal type. See Terminals for the full multiplier table and how the ceiling behaves under memory pressure.

Accessibility holds Screen Reader Mode: Auto (default, follows the OS), On, or Off. Turning it on adds an accessible DOM overlay to terminals, which costs performance, hence following the OS rather than defaulting to always-on.

Worktree

Two sections. Worktree path pattern sets the directory template for new worktrees using variables like {base-folder}, {branch-slug}, {repo-name}, and {parent-dir}, with three presets (Sibling Folder, Subdirectory, Flat Sibling) and a live preview of the resolved path. Always-hidden files lists names that stay hidden in every file browser panel, so generated noise doesn't have to be re-hidden per project.

See Worktrees for the pattern variables and File Browser for the file browser.

Toolbar

The toolbar has a left side and a right side, and this tab is where you decide what lives on each. Drag to reorder within a side or move a button across. Agent, panel, and plugin buttons are listed separately, each with a visibility toggle. Every agent already lives in the launcher, so pinning one to the toolbar is an extra, not a requirement. The Launcher palette section sets the default panel type and whether the dev server option shows even when no command is configured. A reset restores the default layout.

See UI Layout.

Environment

Global environment variables injected into every new terminal Daintree spawns, in every project. A project's own Variables override a global of the same name; nothing else does.

The editor is a key/value list with explicit Save and Discard: changes don't apply until saved, and then only to terminals spawned afterward. An invalid key is flagged inline and raises the amber validation badge on the sidebar tab until it clears. If saved variables can't be read from disk, the tab disables editing rather than showing an empty form you could "save" over your real data, and says so.

For how this tab, the project Variables tab, and the per-agent env block divide the work, see Environment variables across scopes.

Assistant group

Daintree Assistant

The assistant runs a CLI agent inside a sandboxed help workspace and talks to Daintree through the local MCP server. This tab decides which CLI, how much it may do, and what gets recorded. Sections:

• Agent: which CLI runs the assistant, its model, custom launch flags, and a debug-logging toggle that writes a full per-session trace
• Behavior: Search documentation (let it search Daintree's docs and changelog while answering) and Daintree control (let it call Daintree actions through the MCP server)
• Custom commands and skills: your own commands and skills, added to every assistant session
• Hibernation: idle assistants release memory and capture a resume token, so reopening reconnects to the same conversation
• Security: the capability tier, a blast-radius preview, the live session card, and the Claude permission bypass
• Privacy: whether the audit log records dispatches, and how long records are kept
• Connection: the MCP connection the assistant uses, and controls for sharing that access with external clients

Capability tier and the live session card

The Capability tier selector is the assistant's ceiling, and it is three-valued:

Underneath it, a blast-radius preview expands to show how many tools that tier unlocks (both cumulative and the increment over the tier below), so a step up is a number you can look at rather than a vibe. Below that, a live session card reports what the running help session is actually doing: connected or not, the tier it is running at, and whether that tier sits above, below, or level with the configured default. A session can sit above the default because you approved an elevation, or below it because an elevation decayed; both read truthfully rather than collapsing to "matches". Any time-bounded per-tool grants are listed with a countdown to expiry.

See Daintree Assistant for what the assistant can do and how to open it, and MCP Server for the tier allowlists.

Integrations group

CLI agents

A General subtab plus one subtab per built-in agent. Daintree ships 18 built-in agent definitions, 17 of which you can launch directly. The eighteenth is the assistant-only agent that backs Daintree Assistant and is deliberately absent from every launch surface. See AI Agents for the roster and each agent's specifics.

General holds the default agent (used by the help dock button and automated workflows like "What's Next?" and onboarding, distinct from the Portal's default new-tab agent), a link to re-run the setup wizard, and the two global switches below.

Each per-agent subtab holds an enable toggle (a disabled agent is hidden everywhere and treated as uninstalled), expandable CLI help output, installation guidance with copyable commands and a re-check button when the CLI isn't detected, an agent-specific keyboard shortcut row, and the runtime settings card described under Presets and scopes.

Skip permissions

Permission bypass is layered, not a single checkbox, because "trust this agent everywhere" and "trust this one preset" are different decisions.

At the top sits a global switch, Skip permission prompts for agents, on the General subtab. It is off by default, and first-run setup asks about it explicitly: the wizard's Agent permissions step presents the same toggle, defaulted off, and only writes it when you press Continue. Silence is not consent. The switch applies only to agents whose CLI actually supports a bypass flag, and it is read live at launch: it never rewrites per-agent state, so turning it off stops injecting bypass flags on the next spawn, restart, or resume.

Below it, each agent and each preset carries a three-way choice rather than a boolean:

The veto direction is the point: a more specific Off always beats a broader On, so a single agent or preset can be pinned safe without unwinding the global setting. When bypass ends up effective for a scope, the editor shows the exact flag it will add to the launch command: --dangerously-skip-permissions, --yolo, --dangerously-bypass-approvals-and-sandbox, and so on, depending on the agent.

Alt-screen mode

Agent CLIs can render either inline (output lands in Daintree's scrollback like any other terminal output) or on the terminal's full-screen alternate buffer, which is what the CLI does natively. Inline is smoother: WebGL scrollback, clean resizing, searchable history. Alt screen matches what you'd see running the CLI in your own terminal.

A global switch, Use alt-screen mode by default, sets the baseline (off, meaning inline). Each agent and preset then carries the same three-way Default / Inline / Alt screen control, resolving per agent through preset, then agent, then a curated per-agent registry default, then the global switch. As with skip permissions, an explicit choice at a narrower scope wins.

Presets and scopes

Each agent's runtime configuration is layered. The top of the Runtime settings card is a preset selector. The default scope, Default (all worktrees), applies everywhere. Everything else in the picker overrides it: project-shared presets loaded from .daintree/presets/ in the active project, CCR routes if you have Claude Code Router installed, and custom presets you create with Add preset.

Below the selector, a scope banner names what you're editing. For the Default scope and any custom preset the editor exposes custom arguments, skip permissions, alt-screen mode (on agents that support it), a fallback chain for when a provider is unreachable, and an env block. The Default scope's env block is the agent's global vars; a custom preset's is Env overrides, with the Default scope's vars shown inline as inherited rows.

In a custom preset, every field you've overridden shows a small reset icon. Clicking it drops the override and the field returns to inheriting. Project-shared and CCR presets are read-only, but Duplicate forks one into an editable custom preset.

Code Forge

One tab for every forge, replacing the separate GitHub and Forge tabs. A provider dropdown at the top switches between a General subtab and one subtab per registered provider. Provider subtabs are generic: GitHub is one provider among the registered set rather than a special case, and each renders a credential form built from the fields its plugin declared. Saving validates the credentials against the provider before storing them.

General holds three things:

• Default forge provider: either "No global default (auto-detect from hostname)" or a specific provider to pin
• Active project routing: one card per git remote of the active project, each with a badge showing which path resolved: Override, Default, Hostname, or No match, and a tooltip explaining why
• Forge audit log: every provider call (list, get, assign, validate) with redacted argument summaries, for triaging slow providers and failure clusters

If the provider list fails to load, the tab raises the amber validation badge until it clears. Deep-linking to a provider whose plugin has since been disabled falls back to General rather than rendering a panel for a provider that isn't there.

See Code Forge for what a configured provider unlocks.

Integrations

Two sections: External editor and Image viewer. Both are saved per-project, so the panel needs a project open before you can configure it.

External editor

Daintree opens files at a specific line and column in your editor of choice. Eight editors are built in (VS Code, VS Code Insiders, Cursor, Windsurf, Zed, Neovim, WebStorm/IntelliJ, and Sublime Text), plus a Custom option that takes a command and an arguments template using {file}, {line}, and {col} placeholders (default {file}:{line}:{col}). Quote the file placeholder if your paths contain spaces.

Discovery runs when the panel opens, scanning PATH and editor-specific directories, and lists each editor's status and resolved path. On macOS it also probes /Applications and ~/Applications for .app bundles, because GUI apps there inherit a minimal system PATH rather than your shell configuration. An editor that works fine from your terminal can otherwise show as (not found). Rescan re-runs discovery without restarting Daintree, which is what you want after installing an editor mid-session.

Save persists the choice to the current project. Test opens your home directory in the configured editor and reports success or failure inline; it confirms the editor launches, not that your arguments template passes line and column correctly.

Three surfaces use it: Command ⌘ Control Ctrl Control Ctrl +click on a file path in terminal output (a plain click opens the in-app viewer instead), the Open in Editor button in the File Viewer header, and the same button from a diff opened out of the Review Hub. If the configured editor is unavailable, Daintree falls back through $VISUAL/$EDITOR, then any detected known editor, then the platform open command, then a last-resort shell open. Line and column targeting survives only when a supported editor handles the request.

Image viewer

Which application opens image files. Defaults to the OS viewer; select Custom to supply your own command with {file} as the path placeholder. Per-project, like the editor.

Voice Input

Two sections: Speech-to-text and AI text correction.

Speech-to-text starts with a Transcription provider picker, the backend that turns speech into text:

• OpenAI (default): Live Transcribe, with keyword biasing and spoken-command formatting
• Deepgram: Nova-3, with server-side turn detection

The picker changes which API key field is shown, and a note beneath it spells out the data flow for whichever provider is selected: audio streams over an encrypted connection to that provider using your key. For OpenAI the note adds that audio is not used for model training but may be retained in abuse-monitoring logs for up to 30 days; for Deepgram, that streaming audio and transcripts are not retained by default. The rest of the section:

• Microphone permission status with platform-specific instructions, and a microphone selector
• Advanced (collapsed) exposes an OpenAI organization ID and project ID, needed only for legacy user keys. The fields stay disabled for project-scoped sk-proj- keys
• Language, and Paragraph breaks (spoken commands or manual Enter; spoken commands require English and fall back automatically)
• Recording mode: Toggle (press the shortcut to start, press again to stop) or Push to talk (hold to record; releasing stops without submitting)
• Custom dictionary of up to 100 domain terms sent to the transcription service to bias recognition, plus Learn words from corrections: when you fix a mishearing before sending, the term is offered as a dictionary suggestion you can accept or dismiss

AI text correction is optional post-processing that fixes technical terms, punctuation, and filler words. The model is fixed rather than chosen: there is no correction-model dropdown. It uses your OpenAI key even when transcription is running on Deepgram. It offers Resolve file references (turning "link to the input component" into an @file reference), Custom instructions appended to the core prompt, and an expandable view of that core prompt so you can see what your instructions are being appended to.

See Voice Input for the dictation workflow.

Portal

The default new-tab agent, the system-provided default links, and your own custom links. See Portal Browser.

MCP Server

A local server that lets external MCP clients invoke Daintree actions. It binds to 127.0.0.1 only and is never reachable from outside the machine. Four sections:

• MCP server: the enable toggle, which starts or stops the server immediately
• Connection: the live status and URL, the per-client connect config, and who is currently connected
• Port: a fixed port, or automatic. The default is 45454; if it's taken, Daintree tries the next one up.
• Authentication: the bearer token external clients present

The connect config is generated per client rather than as one generic blob, because the three formats are genuinely different files:

The URL shown beside the picker and the snippet the button copies are generated from the same source, so they cannot drift apart. Only the Streamable HTTP endpoint (/mcp) is advertised. A second copy option produces a workspace-scoped config, which adds a header binding that client to the current workspace. That is useful when you run several Daintree windows and want a client to keep routing to one of them instead of following whichever window has focus.

Who's connected is listed live: each external client with its session and request counts and last-active time, plus a Disconnect action per client. Daintree's own help sessions appear separately under a collapsed Internal connections group, so an assistant session is never mistaken for an external tool holding a token.

Below the four sections sit the audit log (every dispatch in a ring buffer with latency rollups and anomaly detection) and turn outcome diagnostics, which classify each help-session turn and roll up per tool to show which tools produce the most errors, tier rejections, or stuck agents. Audit-log retention is set on the Daintree Assistant tab; turn outcomes are recorded separately and aren't affected by it.

Authorization tiers, payload budgets, rate limiting, and the full tool surface are documented at MCP Server.

Plugins

Plugin management does not live in settings. The plugin manager is a first-class view of its own (install from a file or URL, enable, disable, uninstall, check for updates), and this tab is a launcher into it, showing the installed count and an Open plugin manager button.

The one real setting here is Check for plugin updates in the background, off by default. Turning it on checks URL-installed plugins roughly once a day and adds an inbox notification when updates are available.

See Plugins for the manager, the capability consent model, and authoring.

Plugin actions

Plugins dispatch Daintree actions, and this tab is where you read what they dispatched. It holds a Record plugin actions toggle, a record cap, and an audit log viewer with copy, export, and clear. Because plugins run out of process and ask for capabilities up front, the log is how you confirm after the fact that a plugin only did what it said it would.

Run history

A durable log of recipe runs and fleet broadcasts. Each entry shows what ran, against which worktree, and how it went: count pills for terminals spawned, failed, and defined, with per-terminal error text on the failures. Clear history wipes it behind a confirmation.

See Recipes and Fleet for what produces these entries.

Support group

Troubleshooting

• Hardware acceleration: turn off GPU acceleration if you see blank panels or rendering artifacts
• System health check: verifies Git, Node.js, and npm are reachable
• Application logs: open the log file or clear accumulated entries
• Developer mode: verbose logging and diagnostic surfaces, alongside three related toggles: auto-open the diagnostics dock at startup, default to the Events tab when it opens, and verbose logging

See Troubleshooting and Diagnostics.

When a setting fails to save

Settings writes are optimistic: the control moves as soon as you click it, and the write to the main process happens behind it. When that write fails, Daintree rolls the control back to its previous value and raises an error toast naming the setting, with a Try again action. A toggle that silently snaps back is a bug report; a toggle that snaps back and tells you why is a state you can act on.

The same principle covers reads. A tab that can't load its stored values shows an inline error banner with a Retry button and disables editing, rather than presenting an empty form you could save over real data. Nine tabs report their error state to the sidebar, so the amber validation badge appears on the tab even when you're looking somewhere else: Appearance, Worktree, Environment, Code Forge, Voice Input, Portal, MCP Server, Daintree Assistant, and the project Worktree Setup tab.