Security and data flow
Canopy is a desktop app. Most data stays on your machine. This page explains what goes where, how agent sessions work, and what we protect against.
What stays local, what goes external
Stays on your machine
- Source code and project files
- Terminal output and session history
- Workspace layouts, settings, and preferences
- Git data (branches, worktrees, diffs)
- Crash reports (stored locally, not sent automatically)
- SQLite database with session metadata
Leaves your machine
- AI prompts and code context: sent by the agent CLI (Claude Code, Gemini CLI) directly to the provider's API (Anthropic, Google). Canopy does not proxy or store these.
- Telemetry ping (optional): one daily HTTP request to analytics.itsol.tech with screen resolution, locale, app version, OS, and CPU architecture. No user ID, no IP logging. Disable in Settings > Privacy.
- Update checks: periodic requests to GitHub via electron-updater. Transmits app version, OS, and your IP address to GitHub's servers.
- Task tracker API calls: if you connect Jira, YouTrack, or GitHub Issues, Canopy fetches task data from those services using tokens stored in the OS keychain.
How Canopy interacts with AI agents
Canopy is an orchestrator. It spawns Claude Code, Gemini CLI, or Codex as child processes and reads their stdout. It does not modify prompts, inject system instructions, or intercept API calls. The agent runs the same way it would in a standalone terminal.
When you send an inline review comment from the diff panel, Canopy writes it to the agent's stdin. That is the only input Canopy adds to an agent session.
Canopy filters environment variables before passing them to agent processes. A blocklist prevents common secret variables (API keys, tokens, credentials) from leaking into the agent's environment. File operations are restricted to registered workspace directories via path validation.
Credential and secret handling
API tokens for task trackers and saved browser passwords are encrypted using Electron's safeStorage API, backed by macOS Keychain or Windows Credential Manager. On Linux without a system keyring, Canopy falls back to base64 encoding and logs a warning.
Credentials are decrypted only in the main Electron process. The renderer process receives masked versions (no passwords) over IPC. Plaintext secrets never cross the process boundary to the UI.
Signed builds and release process
macOS: builds are signed with an Apple Developer certificate and submitted to Apple's notary service. The app passes Gatekeeper without warnings or manual overrides.
Windows: builds are signed via Microsoft Azure Trusted Signing. SmartScreen recognizes the certificate, so users do not see unknown publisher warnings.
Releases follow semantic versioning. Each release is tagged in git and generates a changelog entry via semantic-release. Binaries are published to GitHub Releases.
What we protect against, what we do not
Canopy applies defense-in-depth for local operations. It does not claim to protect against every threat in the agent ecosystem.
Canopy protects against
- Accidental credential leakage to agent processes (environment variable blocklist)
- File operations outside the registered workspace (path validation)
- Unsigned or tampered binaries (code signing and notarization)
- Plaintext secret storage (OS keychain encryption)
- Cross-process data leaks in Electron (context isolation, IPC masking)
Canopy does not protect against
- Malicious MCP servers that you connect to the agent CLI. Canopy does not manage MCP server configuration.
- Prompt injection in agent output. Canopy displays agent output as-is.
- Supply chain attacks on the agent CLI itself (Claude Code, Gemini CLI). Those are maintained by their respective vendors.
- Actions taken by an agent with elevated permissions. If you grant Claude Code filesystem or network access, Canopy does not add a second permission layer.
Reporting vulnerabilities
Report security issues through GitHub Security Advisories on the Canopy repository. Do not open public issues for vulnerabilities.
We acknowledge reports within 48 hours and provide a status update within 7 days. Patched versions are credited in the changelog unless the reporter requests anonymity.
Report a vulnerability on GitHub