At a glance
| Question | Answer |
|---|---|
| Does my code or my prompts leave my machine? | The local workspace, no. Agent CLIs talk to their own configured providers on their own terms, and the Assistant is one of them. Its runbook search sends Daintree a one-sentence summary of each task. Data paths |
| What can an agent reach on my machine? | Everything your user account can. A worktree isolates changes, not the process. Where the limits are |
| Do I need an account, and what does it cost? | The desktop app is free, Apache 2.0, and needs no Daintree account. The Assistant runs on your own Claude Code or Codex subscription. The Assistant's searches |
| Is telemetry on? | Off by default. Opt-in, three levels. Telemetry |
| Where are my API keys stored? | Daintree's own tokens, locally and in plaintext. Agent CLIs keep their own. Credentials |
| Is the source public? | Yes, Apache 2.0. daintreehq/daintree |
| Are releases signed? | It depends on the artifact and the platform. Verify the build you downloaded rather than trusting the build configuration. Per platform |
| Has there been a third-party security audit? | No. None has been commissioned, and nothing on this page is a substitute for one. Where the limits are |
| Can I check any of this myself? | Yes. Clone the reviewed commit and point your own agent at it. Review it yourself |
| How do I report a vulnerability? | Privately, by email or a GitHub advisory. Acknowledged within three working days. Process |
What this does not guarantee
Every mechanism below prevents something specific. None of them makes arbitrary code harmless, and it is worth being exact about where each one stops.
- A worktree is Git isolation, not process isolation. Each task gets its own branch and checkout, so agents do not overwrite each other's work. The agent process still runs as your user and can read and write anything your user can.
- An agent CLI keeps its own capabilities. Daintree launches the real binary you already have. Whatever that tool can do, and whatever it sends to its provider, is governed by that tool, not by Daintree.
- Plugins execute code. A manifest declares intent; it does not confine behavior. Install plugins from sources you would trust with a shell script.
- Electron Fuses close packaging and runtime paths. They stop the packaged app being re-used as a generic Node runtime and detect tampering with the archive. They do not contain code that is already running.
- Local-first reduces server-side exposure, not local exposure. Nothing on this page protects a machine that is already compromised.
- Public source is not an audit. Anyone can read the code. Nobody independent has been paid to.
- A tool set bounds the Daintree tool surface, not the model process. It governs what the Assistant can call through Daintree. The CLI backing it is still a process on your machine with whatever else that binary can reach.
- The local audit log records Daintree tool calls. It records activity through that tool surface subject to local retention, and does not record everything the underlying CLI did outside it.
Where your data goes
The workspace and the agent terminals run on your machine. Ordinary coding CLI traffic follows each CLI's configured provider without a Daintree model relay. Agents run locally in your terminal, and any context they send to a provider API is between you and that CLI. Daintree reads your files locally where you ask it to, in the file viewer and in Review Hub, without requiring a hosted workspace.
Running agents on another machine does not change that. Daintree never proxies remote work through infrastructure we operate. Remote compute is a per-worktree lifecycle hook: the environment is a Docker stack, a cloud VM or a sandbox that you describe in .daintree/config.json, and Daintree runs the commands you wrote against the hardware you chose.
The features that do reach the network, all of them:
- Update and plugin checks
- Model metadata
- Connected forges
- Remote browsers
- Optional voice services
- Opt-in telemetry
- The Assistant's documentation and runbook search, described below
An agent or optional service can receive context you give it. The Assistant's runbook search receives a one-sentence summary of each task you give it.
Reference: privacy and data boundaries, the privacy policy
The Assistant's two search services
The Daintree Assistant is Claude Code or Codex, launched in Daintree's assistant sidebar on your own subscription. Its model traffic goes from the CLI to your provider; Daintree relays none of it and holds no provider credentials. What Daintree does operate in the Assistant's path is two read-only search services. The CLI connects to them itself over MCP, with no Daintree token, account or device ID attached.
- Documentation search at
daintree.org/api/mcpreceives the queries the Assistant writes to look something up in these docs. - Runbook search at
assistant.daintree.orgis connected while Follow runbooks is on, which is the default. Before it acts, the Assistant sends a one-sentence summary of the task and is instructed to leave out names, numbers, branches, files and pasted output. That is an instruction to the model, not a filter. The service returns procedures from a fixed catalog, makes no model call, and its application log records request metadata, not the query.
Both can be turned off under Settings → Assistant → Daintree Assistant → Behavior, and neither is contacted outside an Assistant session. The privacy policy sets out exactly what each one receives.
Telemetry: off by default
Telemetry defaults to disabled (enabled: false hardcoded in the store). Daintree supports three levels: off, errors-only (scrubbed error events via Sentry), and full (adds a small set of anonymous usage analytics). No diagnostic or usage event is sent at the default setting. Telemetry settings do not disable the other feature network requests described above; agent CLIs you launch continue to talk to their own providers on their own terms.
Participating logging and telemetry paths scrub recognized credential patterns and redact known path shapes. This is a best-effort filter, not a guarantee that arbitrary secrets or every filesystem path are removed. The pre-consent event buffer caps at 100 events and is never flushed without consent.
Source: telemetry initialization and sanitizer, scrubber pattern list
Where credentials are stored
Agent CLIs retain their own credential and network behavior. Optional voice credentials go to the selected transcription or correction provider; MCP credentials authenticate the local tool connection. Daintree feature credentials are stored locally in plaintext. The Assistant has no credentials of its own: the Claude Code or Codex session behind it signs in the way that CLI always does.
Source: the credential patterns that get scrubbed from logs. Reference: what is stored and where
What the desktop app hardens
These narrow specific paths into and through the packaged application. Read them against the limits above: each one closes something particular, and none of them contains code that is already running.
Renderer sandboxing
All Electron renderer processes run with contextIsolation: true, nodeIntegration: false, and sandbox: true. These values are hardcoded in the source, not user-configurable. Every embedded webview enforces the same flags.
Communication between the UI and the main process passes through a contextBridge preload. IPC has sender validation and global invocation budgets. Domain handlers validate their inputs, commonly with Zod; the exact validation depends on the handler.
Navigation lockdown. The main renderer window is locked to the app://daintree protocol (and the localhost dev server in development). All other navigations are blocked via will-navigate and will-redirect. window.open is denied for all origins. shell.openExternal only permits http:, https:, and mailto: schemes. The Portal browser panel allows full http:/https: navigation by design, but runs in a sandboxed webview with the same isolation flags.
Source: sender validation and invoke budgets, protocol handlers and limits, renderer CSP, embedded-browser policies. Reference: desktop and IPC boundaries
Electron Fuses
Electron Fuses are compile-time binary flags that permanently disable attack surfaces. They narrow how the packaged executable starts and loads code. They do not contain an attacker who already has arbitrary code execution.
runAsNode false Prevents the binary from being abused as a generic Node.js runtime via ELECTRON_RUN_AS_NODEenableCookieEncryption true Enables Chromium's cookie-encryption feature in the binary. The app also sets --use-mock-keychain, so this flag alone does not establish OS-backed cookie protectionenableNodeOptionsEnvironmentVariable false Blocks NODE_OPTIONS injection from the environmentenableNodeCliInspectArguments false Blocks --inspect from the command lineenableEmbeddedAsarIntegrityValidation true Detects tampered ASAR bundles before loading themonlyLoadAppFromAsar true Prevents loading the app from unpacked filesystem pathsgrantFileProtocolExtraPrivileges false Removes special privileges from the file:// protocolloadBrowserProcessSpecificV8Snapshot false Disables loading a separate V8 snapshot for the browser processLocal MCP server
The general MCP listener is opt-in and disabled by default; starting the in-app Assistant provisions its own authorized local connection. When enabled, it binds to 127.0.0.1 (localhost only, not 0.0.0.0), so it is not reachable from the network or other machines. The default port is 45454.
If no API key is configured, any local process can connect to the MCP server. Set an API key in Settings → MCP Server to require Bearer token authentication.
Host and origin validation restrict the HTTP transport to local callers. The discovery file is written to ~/.daintree/mcp.json.
IPC rate limiting
Daintree applies per-category rate limiting to IPC handlers to prevent runaway or malicious usage patterns from the renderer process. Three categories are enforced: fileOps (CopyTree operations), gitOps (worktree and git operations) and terminalSpawn (terminal process creation). Category-specific rates, queue bounds and terminal spawn batches limit bursts. The transport also has a separate invocation budget.
Source: invoke budgets and error filtering, security regression tests. Reference: the IPC reference
Code signing & notarization
The macOS packaging configuration specifies hardenedRuntime: true and forceCodeSigning: true, with a notarization step in the release pipeline. This describes the build configuration; verify the signature and notarization of the artifact you downloaded. Hardened runtime entitlements are limited to exactly what Daintree needs:
- JIT (required by the V8 JavaScript engine)
- Unsigned executable memory (required by node-pty native modules)
- Disable library validation (required by the Electron framework)
- Microphone (voice input only)
- Camera: explicitly false
The other two platforms are not at parity, and saying so is more useful than implying they are. On Windows, check the downloaded installer's digital signature and publisher, and compare the release checksum; build configuration alone does not establish that an individual artifact was signed. On Linux, check the supplied package format and compare the release checksum; package availability and signing depend on the release.
Source: packaging and signing configuration. Checksums and assets are attached to each release
Don't take our word for it
Daintree is fully open source. Clone the reviewed commit and point one of your own agents at it. The prompt below is a starting point for a source review, not a security audit: an automated read can surface things worth checking, and it cannot certify that an application is safe to run.
Clone the reviewed commit
git clone https://github.com/daintreehq/daintree.git && cd daintree
git checkout 64360dcc3df7cd740765e5e5beaa9af43668e509 Open your agent
claude codex agy opencode Ask it to review the source
Paste this prompt into the agent. It asks for cited findings separated into what the model verified and what it only suspects, and no install verdict.
Review the source of this Electron application and tell me what a human reviewer should look at. Cover: hardcoded secrets or credentials; any network call that sends user data off the machine, and whether it is opt-in; Electron configuration including nodeIntegration, contextIsolation, and the Fuses (runAsNode, ASAR integrity validation, cookie encryption, nodeOptionsEnvironmentVariable); IPC handler surface and whether rate limiting is enforced for the fileOps, gitOps and terminalSpawn categories; the local MCP server on port 45454 and the discovery file at ~/.daintree/mcp.json; uses of shell.openExternal; paths that could lead to remote code execution; and the breadth of filesystem access. For every finding, cite the file and line, and label it as VERIFIED (you read the code that proves it) or HYPOTHESIS (it looks plausible but you did not confirm it). Rank findings by severity and list the areas you could not assess. Do not give a verdict on whether the application is safe to install; that is not something a source read can establish. Report a vulnerability
Please do not open a public issue for a security report. Include the affected version, the platform, and enough detail to reproduce the issue. Expect an acknowledgement within three working days. Fixes ship in the next release; if a report warrants it, one goes out sooner and is called out in the changelog.
The most recent release is the supported version. There is no long-term-support branch, and older releases do not receive backported fixes. The machine-readable version of this is at /.well-known/security.txt.