Skip to main content

Settings

How Daintree's 20 global and 9 project settings tabs fit together: the scope switcher, the override-vs-inherit model, cross-scope search, sidebar indicators, and exporting or importing portable configuration.

Updated
Reviewed

Open Settings with Command-, Control-, Control-, , or click the gear icon in the toolbar. The dialog is a left sidebar of grouped tabs and a content panel on the right. When a project is open, a scope switcher in the sidebar header toggles between Global and Project settings.

Settings split into two scopes:

  • Global Settings apply to Daintree as a whole, regardless of which project is open. They cover 20 tabs across the General, Terminal, Assistant, Integrations, and Support groups.
  • Project Settings cover 9 tabs and layer on top of the global values for one project only. They only exist while a project is open.

Opening Settings from the toolbar or the menu always lands on global scope, whichever tab you were last on there. Switching scope takes you to the tab you were last using in that scope, because the two scopes hold different tabs and dumping you on a mismatched one would just cost a click. A search result, or any action that deep-links a specific tab, opens directly on it in the right scope.

Global scope, with the scope switcher above the nav groups

Override and inherit

Project settings do not replace global ones: they sit in front of them. Most project fields have a global default behind them, and the field tells you which one is in play. An overriding field carries a small marker next to its label, and reveals a Reset to global button on hover. An inheriting field shows the inherited value in italics below the input. Clearing an overridden field reverts it to inherited, so most of the time you don't need the reset button at all.

That is the model for scalar fields. Environment variables use a related but distinct shape: a read-only inherited block above the editable project rows, with pills marking which inherited keys the project has taken over. Both are documented on the Project Settings page.

With the Settings dialog focused, press Command-F Control-F Control-F or / to jump to the search field. Matching is fuzzy across every setting name, description, and keyword, so partial matches and minor typos still find the right result.

As you type, match count badges appear next to each sidebar tab showing how many results that tab holds. The content panel is replaced with a scrollable list of result cards. Each card leads with a scope chip (Global or Project) so you can see which scope the result lives in, then a breadcrumb path (Tab › Subtab › Section), the setting title with matches highlighted, and a description. A setting that depends on a disabled feature carries a Requires <feature> pill, so you know the click will land on a page gated behind an enable toggle.

Arrow keys move through results, Enter navigates. Esc clears the query; a second Esc blurs the search field.

Search results carry a scope chip on every card
Tip
The scope chip is what tells you when a search has surfaced a hit from a scope you're not currently viewing. A query typed in Global scope can still return Project results, and the Project chip tells you exactly where the click will take you.

The @modified filter

Type @modified (or the short alias @mod) in the search box to show only settings that differ from their defaults. It combines with keywords: scrollback @modified narrows to modified scrollback-related settings.

If nothing has been changed, the results area shows an empty state confirming everything is at its default.

Note
The @modified filter respects the active scope. In Global scope it shows changed global settings; in Project scope it shows changed project settings. The scope chip on each result card makes the difference clear.

Three kinds of marks can appear on a tab's icon in the sidebar. They're independent of which tab you have open, and they update live as you change settings.

  • Modified dot: at least one setting on that tab differs from its default. This is the modified indicator.
  • Amber dot: the tab has reported a validation error. This is the validation badge, separate from the modified indicator.
  • Match count badge: only visible while you're searching. Shows how many results the active query matches in that tab.

When a tab has both a modified setting and a validation error, the amber dot wins. The amber dot clears itself as soon as the underlying error resolves. Leaving the tab does not clear it — a visited panel stays mounted, so the error travels with you until you fix it or close Settings.

Modified: the blue dot on the General tab
Invalid: the amber dot on the Environment tab

Three tabs currently track modified state:

TabTriggers the modified dot when
GeneralAny Display subtab toggle differs from its default (Project Pulse off, Developer Tools on, or either Agent Highlights toggle on)
Panel GridAny Performance, Input, Layout, or Scrollback setting differs from its default
AppearanceDock Density is set to Compact or Comfortable (the default is Normal)

Nine tabs currently report a validation state: Appearance, Worktree, Environment, Code Forge, Voice Input, Portal, MCP Server, Daintree Assistant, and the project Worktree Setup tab. They raise it when their stored values or provider list fail to load, or when a field on them is invalid: an unparseable env key, a broken worktree path pattern. More tabs can opt in over time, so treat the amber dot as the general signal that something on that tab needs attention, not as a fixed list.

Tip
Validation badges aren't sticky. There's nothing to dismiss. As soon as the error condition clears, the dot disappears.

Move configuration to another machine

Choose Help > Export Configuration… to save a versioned JSON bundle, then Help > Import Configuration… on the destination machine. Both actions are also searchable in the command palette. This transfers selected global configuration:

  • Custom agent definitions and per-agent settings, including presets
  • Keyboard shortcut overrides
  • App theme preferences and custom app themes
  • Notification preferences
  • The global worktree path pattern
  • Global recipes

The bundle does not transfer projects, open panels, terminal history, installed plugins, repository-owned configuration, or credential stores. Global environment variables are not a bundle section. The app-wide Skip permissions and Use alternate screen overrides also stay on the destination machine; per-agent settings are portable.

Before import, a preview names the file and counts additions and replacements in each affected section. Confirming merges those entries into existing configuration: matching IDs or setting keys can be replaced, while entries absent from the bundle stay as they are. The dialog confirms the bundle as a whole; it does not offer section checkboxes. Export the destination's current configuration first if you want a bundle you can import to restore overwritten values. Daintree keeps no persistent pre-import backup.

The result reports applied, already-matching and skipped entries. Unsupported actions, invalid agent definitions or sound files unavailable on the destination can be skipped while other entries apply. An import failure triggers an attempt to restore the in-memory pre-import snapshots and keeps the dialog available to retry; inspect the error if restoration also fails. Unknown sections are ignored, but a newer bundle format is rejected with a request to update Daintree.

Warning
The export omits values matching Daintree's known secret patterns, including nested preset environment values. This is pattern detection, not a guarantee that every custom credential is recognized. Review the JSON before sharing it, and configure excluded credentials separately on the destination. If a secret occurs in a positional array, the whole array is omitted to avoid changing a command's meaning.

For the exact portable fields and validation rules, see the configuration bundle service, bundle parser and secret omission, and import preview.