Privacy Policy

The Short Version

• No Copse account or backend. The desktop app talks directly to other services; 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, SSH workspaces, browser sessions and web search, custom tools, hooks, the Mobile Companion, and the automatic checks 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, normally 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. When you open the ACP agents settings, Copse asks the npm registry for the latest version of each agent's adapter package, and an adapter you approve is installed through npm.

SSH workspaces and remote agents over SSH

Both are off by default (Settings → SSH). An SSH workspace runs file, shell, terminal, Git, and search operations on the host you configure, through your system OpenSSH, so that host receives the commands and file content they involve. With agents on the remote machine turned on, the ACP agent itself runs on the SSH host: it receives your prompts and makes its own model calls from there. Copse forwards the agent's configured keys to that host only after you approve it in a dialog, and installs a missing adapter there only with your approval. SSH passwords and passphrases you ask Copse to remember are stored encrypted on this machine.

Mobile Companion

Off by default (Settings → Experimental). When you turn it on, Copse listens on your local network — on the private address you choose, never the internet — so a phone you pair can follow your work. Pairing needs a code shown on the phone and your approval on the desktop. A paired phone can read project names, thread titles and status, recent messages, and pending approvals and questions; one you allow to control Copse can also answer approvals and questions, stop runs, and send messages, which then run against your model. Copse keeps its local certificate authority and the list of paired phones (with hashed tokens) in ~/.copse/lan/. You can revoke a phone or turn the companion off from the same settings.

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.

The agent's web search sends its search query to DuckDuckGo. DuckDuckGo is an approved origin by default, so a search runs without asking unless you set the web tools to ask first. Fetching a page sends a normal request to that site, and only to approved origins. Two optional services need your own API key and are off until you add one: Parallel search sends the agent's search objective and queries to Parallel, and Artificial Analysis model data is downloaded from Artificial Analysis with your key.

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.

Automatic Checks

These run without a separate action from you. None of them sends your prompts or code.

Updates

The packaged macOS app checks its update feed on GitHub (copse-dev/copse-releases) on launch and when you choose Check for Updates. When an update is available, Copse also fetches the release notes from the GitHub API to show what changed. Copse asks before downloading an update. Once downloaded, the update installs when you restart or next quit. Development builds do not use the feed.

Coding plan usage

To show how much of your coding plans you have used, and to choose a default model that makes the best use of them, Copse can read the sign-in another tool on this Mac already holds — but only for a provider you have set up in Settings → General: Claude Code or Codex once you have added and enabled that agent, Cursor once you have added its agent or saved a Cursor key, and Hugging Face once you have saved a Hugging Face key in Copse. For those, it reads Claude Code's Keychain item or ~/.claude/.credentials.json, Codex's ~/.codex/auth.json, Cursor's Keychain item or local app state, or your Hugging Face token, and sends each token only to the service that issued it — Anthropic, OpenAI's ChatGPT service, Cursor, or Hugging Face — to read that plan's usage. Nothing is read for a provider you have not set up. This runs when you open Settings → Usage, and when Copse resolves the default “best value” chat model as a thread opens or an agent runs, at most every five minutes. Copse keeps recent usage samples locally. macOS may ask before Copse reads another app's Keychain item.

Model information

The value chart in Settings → Usage checks which models have published model cards by requesting public pages on Hugging Face and on model vendors' sites. These requests carry a model name and your network address, nothing else, and their results are cached locally.

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;
• cached model-card checks and coding plan usage samples, and remembered SSH passwords and passphrases (encrypted);
• when the Mobile Companion has been set up, its certificate authority and paired phones in ~/.copse/lan/; 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.