Privacy Policy

The Short Version

• No Copse account or backend. The desktop app talks directly to services you configure; Copse does not operate an intermediary service for your prompts or code.
• No telemetry. No analytics, no crash reporting, no usage data collection. Maintainers do not automatically receive diagnostics.
• External features send data. Cloud models, remote agents, MCP/ACP, browser sessions, custom tools, hooks, and updates have the data flows described below.
• Local does not mean encrypted. Conversations are stored as ordinary files. API keys use OS secure storage when available; otherwise plaintext storage requires explicit consent.

Data Sent to Services You Choose

Model providers

A cloud model request can include your prompt and images, earlier conversation, system instructions, tool definitions, tool calls and results, and source or file content included in context. Requests go directly from the app's main process to the configured provider. Local providers remain local only when their configured endpoint is local.

Provider-key validation and model-list refreshes also contact the provider. The provider's privacy, retention, logging, and training policies apply after it receives the data.

By default Copse asks each provider for the most protective request-level handling it offers: OpenRouter traffic is restricted to zero-data-retention, non-training upstreams, and direct OpenAI requests send store: false. Every request also carries the same app-attribution headers (HTTP-Referer: https://copse.dev/ and X-Title: Copse). Those name the application, not you. Optional on-device PII redaction can redact the text you typed before it leaves the machine; it is off by default and does not cover repository files or tool output.

Remote agents

Selecting a Cursor or Anthropic remote agent sends the current prompt and images. The first handoff can also include prior user/assistant conversation and the current Git branch. A repo-backed session sends the repository URL and branch so the service can clone or mount the project; Claude's repo-backed flow also sends the configured GitHub token to the service for that mount. The remote service may modify a branch or open a pull request according to the selected settings.

MCP and ACP

MCP servers receive tool arguments, which may contain paths, file content, prompt-derived text, or other workspace data. Results return through Copse and are stored in the thread. An MCP server can be a local process or remote HTTP service and controls its own networking, logs, and retention. Project MCP configuration is workspace-trust gated; server and tool approvals apply according to your settings.

An ACP agent is an external program running on the same machine. Copse gives it the prompt, workspace path, selected MCP configuration, and any tools exposed through the optional localhost bridge. Copse strips its provider keys from the inherited base environment, but values explicitly configured for the agent are passed to it. The ACP program may have its own credentials, storage, and network behavior.

Browser and web tools

Websites opened in Copse receive normal browser requests and any data entered into them. The interactive browser and agent automation use separate persistent profiles, so the agent does not inherit the user's interactive logins. Agent snapshots, screenshots, and interaction results may be sent to the selected model as tool results and are stored in the thread. Browser cookies and site storage remain in their local profiles.

Custom tools and hooks

User-installed custom tools and configured hooks run code on the device and can read or transmit whatever their implementation and permissions allow. Review them as code, not as passive configuration.

Updates

The packaged macOS app checks its GitHub Releases update feed on launch. Copse asks before downloading an update. Once downloaded, the update installs when you restart or next quit. Development builds do not use the feed.

Credentials and Environment Scanning

Keys entered in Settings are written to ~/.copse/user-data/settings.json (or the profile COPSE_DIR selects). They are encrypted with AES-256-GCM under a random data key that Copse keeps as a single item in the operating system's keyring — the macOS Keychain, Windows Credential Manager, or a Linux Secret Service keyring. That key belongs to the OS user account, not to the Copse profile. Keys sealed by earlier versions with Electron secure storage are still read, and are rewritten in the new format the first time they are used. If no keyring is available, Copse refuses to persist the key until you explicitly approve base64 plaintext storage. Base64 is recoverable by anyone who can read the file.

Environment-only keys are not written to settings. The environment-key scan runs only when you choose it. It reads process.env and a fixed allow-list of shell startup files in the main process and shows the renderer only masked previews. Importing a detected key turns it into a stored key.

Local Storage

Copse stores data locally, including:

• settings, credentials, provider configuration, projects, and UI preferences;
• conversation messages, reasoning, tool calls/results, images, hooks, and subagents;
• separate browser profiles and agent-browser screenshots;
• semantic-search indexes; and
• short-lived Git worktree backup refs inside opened repositories.

Conversations are integrity-hashed but are not encrypted by Copse. Disk encryption and OS account permissions protect them at rest. Deleting a local record does not delete copies already retained by an external provider, agent, server, or website.

Telemetry, Exports, and Diagnostics

Copse includes no product analytics, crash reporter, or automatic diagnostic upload. The built-in thread export is deliberately complete, not secret-redacted: it can include prompts, source code, paths, attachments, tool data, reasoning, and nested agent transcripts. Inspect and redact a copy before sharing it through GitHub or email. Never share settings, environment dumps, shell startup files, or browser profiles.

More Detail and Source Code

The complete feature-by-feature data-flow and storage inventory is maintained with the source code:

Read the data-flow documentation · View source code on GitHub

Contact

For privacy questions and ordinary bugs, use GitHub Issues without including sensitive data. Report suspected vulnerabilities privately to security@copse.dev.

For privacy questions, ordinary bugs, and suspected vulnerabilities, write to security@copse.dev without including sensitive data.