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

1. Diagnostics, never content. Telemetry reports that something broke and enough environment to reproduce it—never what you built or ran.
2. Allowlist, not autocapture. Only explicitly enumerated fields are attached. Daemon objects, Workload specs, and environment variables are never serialized into an event.
3. Pseudonymous. A random install UUID ties events together for crash-free-rate math. No email, account, IP address, hostname, or OS username.
4. 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 a claude CLI is installed or a rust-http template 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).