Privacy and Telemetry
Cosmonic Desktop's telemetry is opt-in and off by default. Until you turn it on, the app and daemon send no telemetry. (The app still checks the release feed for updates unless you turn that off in Settings → Updates; that request carries the pseudonymous install ID only when usage analytics is on.) There are two independent consents—crash & error reports and usage analytics—each with its own toggle in Settings → Privacy: turn on either, both, or neither, anytime.
The principles
- Diagnostics, never content. Telemetry reports that something broke and enough environment to reproduce it—never what you built or ran.
- Allowlist, not autocapture. Only explicitly enumerated fields are attached. Daemon objects, Workload specs, and environment variables are never serialized into an event.
- Pseudonymous. A random install UUID ties events together for crash-free-rate math. No email, account, IP address, hostname, or OS username.
- Scrubbed on the way out. Every event passes through a scrubber that relativizes file paths (your home directory becomes
~), redacts secret-shaped strings, and drops server names and IPs—defense in depth even if a field slips through.
What we collect when a toggle is on
Crash & error reporting covers the stability and diagnostic items below; usage analytics covers the counts and usage events. Both attach the same basic environment and version fields, and everything on this page is subject to the same allowlist and scrubbing.
- Environment: OS name and version, architecture, CPU count, coarse total RAM.
- Versions: app, daemon, and runtime versions; release channel; packaged vs. development build.
- Stability: crash reports and release-health sessions (the crash-free rate), keyed by the random install UUID; which feature flags are enabled, so crashes can be correlated to them.
- Counts only: the number of workloads, components, hosts, secret references, and projects—never their names.
- Health and performance: daemon status and uptime bucket, coarse resource metrics, and sampled operation timings (app start, build, deploy).
- Usage events: which app surfaces and tools are used (for example, that an MCP tool call happened and whether it succeeded)—action types, never values.
- Taxonomies and reduced diagnostics: component languages and capability kinds (
rust,wasi:http—never custom interface names); the image registry's hostname (ghcr.io—the host, never the image path); which known developer CLIs and project templates are present (for example, that aclaudeCLI is installed or arust-httptemplate was used); scrubbed error messages and stack-frame paths (home directories relativized, secrets redacted); and request paths reduced to their templates (/v1/workloads/{ns}/{name}—never real workload or namespace names).
We never collect...
Component names, image references (beyond the registry hostname above), Workload spec contents, code, prompts, secret values, environment variables, file contents, email addresses, IP addresses, hostnames, or OS usernames. Secrets in particular can't leak by construction: the daemon only ever handles secret references; resolved values live in memory during workload start and are zeroized after injection.
Enabling and disabling
The first-run disclosure asks explicitly about crash & error reporting; usage analytics stays off until you enable it in Settings → Privacy. Changes take full effect after the host restarts. For automation, two environment variables pre-decide consent and lock the corresponding toggle: COSMONIC_TELEMETRY (crash & error reports) and COSMONIC_USAGE (usage analytics).
Who processes it
Two named sub-processors, each tied to one consent toggle:
| Processor | What it receives | Gated by | Processed in |
|---|---|---|---|
| Sentry | Crash reports, error events, and release-health sessions | Crash & error reports | United States |
| Amplitude | Product-analytics events—the counts, timings and action types listed above | Usage analytics | United States |
Both are US-region deployments, and that is fixed in the software rather than a
matter of configuration: the daemon posts to Sentry's ingest.us.sentry.io and
Amplitude's api2.amplitude.com (their EU-residency endpoints are different
hostnames, which we do not use).
For users in the EEA, the UK or Switzerland, that is a transfer to the United States. Amplitude's Data Processing Addendum incorporates the 2021 Standard Contractual Clauses (and the UK Addendum), which take precedence over the rest of that DPA for such transfers; Amplitude's sub-processors are listed here. Sentry's terms are at sentry.io/legal.
Nothing else leaves the machine. The daemon holds the only outbound connection; the app and the MCP server hand events to it and open no connection of their own, so there is no second path to audit.
The pseudonymous device identifier
Events are tied together by a random install UUID. It is generated on the device, is not derived from your hardware, account, email or network, and is the only identifier attached. We hold nothing else that points at you—which is the design, and also means we cannot look you up without it.
You can read it, with a copy button, in Settings → Privacy.
How long it is kept
Retention differs by what the data is and where it lives, so it is worth being specific rather than quoting one number.
What leaves your machine (only with the matching consent on)
| Data | Processor | Retained |
|---|---|---|
| Product-analytics events—the counts, timings and action types above | Amplitude (US) | Until deleted. No automatic expiry is configured. |
| Survey free text, if you submit a survey | Amplitude (US) | Same as above. This is the only user-authored content on the stream. |
| Crash reports and error events | Sentry (US) | Sentry's default event retention, 90 days. |
| Release-health sessions (the crash-free rate) | Sentry (US) | Same schedule as crash reports. |
| The pseudonymous device identifier | attached to the rows above | Lives exactly as long as the events carrying it. |
On "until deleted": Amplitude does not expire event data on its own. Automatic expiry is an opt-in control that has to be enabled on the account, and we have not enabled it—so rather than publish a number the configuration does not enforce, we say what is true. You can have the events tied to your device identifier deleted at any time (see below), and turning usage analytics off stops new ones immediately.
What never leaves your machine
None of this is transmitted anywhere. It is listed because "how long is it kept" is a fair question about local data too, and because all of it is yours to delete.
| Data | Where | Retained |
|---|---|---|
| Recent daemon and workload logs | memory | The newest 5,000 records; gone when the daemon restarts. |
| The daemon's log file | ~/Library/Logs/Cosmonic/cosmonicd.log (macOS; equivalents elsewhere) | Until you delete it—we do not rotate or expire it. |
| The security audit trail | <state dir>/audit/audit.jsonl | Size-based, not time-based: rotates at 8 MB keeping 5 generations, so roughly the last 48 MB of security-relevant events. On Linux a copy also goes to the system journal, under the journal's own retention. |
| Deployment revision history | state dir | The last 10 revisions per workload. |
| Cached component images | content-addressed image cache | Until pruned; nothing expires on its own. |
| Workload specs, named configs, secret references | state dir | Until you delete them. |
| Your device identifier and install-age markers | <state dir>/telemetry-state.yaml | Until you delete it. Removing it makes a fresh one. |
| Telemetry waiting to be sent, if you are offline | state dir | Bounded to 1,000 events / 1 MB, oldest dropped first. Discarded, not stored, once consent is off. |
cosmonicd paths prints the resolved locations on your platform.
Neither processor is used to build a profile of you, and neither receives content—only the categories enumerated above.
Cosmonic Desktop's own logs, audit trail and workload state never leave your
machine at all. They live under the platform data directory (cosmonicd paths
prints the resolved locations) and are yours to delete.
Access and deletion
Because the stream is pseudonymous, a request has to carry the device identifier—it is the only thing that connects the events to you. Copy it from Settings → Privacy and email it to legal@cosmonic.com, and we will retrieve or delete the events tied to it.
Turning both toggles off stops collection immediately; it does not by itself delete what was already sent, so send the identifier if that is what you want.
The Claude Desktop extension and other MCP clients
Cosmonic Desktop ships an MCP server (cosmonic-mcp, Apache-2.0), packaged as a
Claude Desktop extension and registerable with any MCP client. It speaks to the
local daemon over a unix socket (a named pipe on Windows) and opens no network
listener and needs no API key.
What it reports is deliberately narrower than the app's:
- on connect, which client connected—normalized to a fixed enumeration, never the raw client name, which routinely carries a filesystem path or a hostname—plus the client's major version only;
- on disconnect, the session duration and tool-call count, both as buckets rather than values;
- per call, the name of the tool invoked.
It never sends prompt text, tool arguments, tool results, file contents, manifests, or component bytes. All of it is gated by the same usage-analytics consent and passes through the same allowlist and scrubber; with the toggle off it sends nothing.
How this relates to the main policy
This page describes Cosmonic Desktop, the local daemon, and the MCP server specifically. The Cosmonic Privacy Policy governs Cosmonic's websites and hosted services and applies alongside it. Where this page is more specific about the desktop product, this page is the accurate description of what the software does.
Questions, or a data-subject request: legal@cosmonic.com, or Cosmonic Corp, 4105 18th St N, Arlington, VA 22207.