atriumatrium

Telemetry

What atrium collects, when, and how to opt out.

atrium has two tiers of telemetry: a small set of core events required for the app to be usable, and an opt-in analytics stream that helps us understand how the product is used. Both are off by default on first launch until you make a choice in the onboarding wizard or Settings → General → Telemetry.

Config

Three flags control telemetry, stored in ~/.atrium/config.json under telemetry:

{
  "enabled": true,
  "analyticsOptIn": false,
  "coreTelemetryDisclosed": false
}
  • enabled — master kill-switch. When false, atrium sends nothing, regardless of the other two flags.
  • analyticsOptIn — user explicitly opted into product analytics.
  • coreTelemetryDisclosed — user has acknowledged the core telemetry disclosure. The onboarding wizard sets this to true when you complete the telemetry step.

Tier 1 — Core

Always-on when enabled: true and coreTelemetryDisclosed: true. Includes:

  • App lifecycle — launch, quit, version, channel.
  • app_active heartbeat — fires every 10 minutes while the atrium window is focused, with the same payload as launch (version, OS, arch, locale). This is the signal we use to measure daily-active installs without relying on launch-only events, since users keep atrium open across days. The event is dropped while the window is unfocused or backgrounded.
  • Update checks — requests to the updater endpoint and their outcomes.
Core telemetry exists so we can tell whether updates are reaching installed builds, the app is launching at all, and which installs are actively in use. It does not include file contents, command history, pane contents, or agent transcripts. Tier 1 events are sent to PostHog.

Tier 2 — Analytics & crash reports

Only collected when all three flags align: enabled: true, analyticsOptIn: true, coreTelemetryDisclosed: true.

  • Feature usage — which pane types are opened, which commands run, which keybindings fire. Counts only — no argument contents. The Tier 2 schema covers vault commits and restores, activity sidebar transitions, dictation start/stop, layout operations (split, snap, restore, popout, expose), code-review dispatch, launcher and restore-chooser interactions, browser open and crash signals, room switches and pinning, file-tree multiselect actions, and task and run lifecycle transitions.
  • Adapter launches — which adapters are started and their versions.
  • Performance — mosaic render times, pane switch latency, terminal throughput (aggregate, not per-session).
  • Activation milestones — one-shot events the first time a user reaches a step like "first agent run", "first commit through atrium", "first review dispatched". One event per install, used to understand which features users actually reach.
  • Crashes & errors — Rust panics and uncaught webview exceptions, with stack traces and release/commit attribution but without user content. Captured via Sentry and gated on the same opt-in as analytics, so users who want lifecycle data without crash collection can keep analyticsOptIn: false.
Behavioral events route to PostHog; failure events route to Sentry. Both project IDs and public keys are embedded in the app binary, and Sentry is configured with send_default_pii: false so it never captures IP, username, or hostname. Every Tier 2 event still has a count-only or enum-valued payload — no argument contents, no file paths, no command text.

What we never collect

  • Terminal scrollback.
  • Editor or markdown buffer contents.
  • Browser pane URLs, cookies, or form inputs.
  • Task card contents, comments, or descriptions.
  • Files from the workspace directory.
  • AI agent prompts or responses.
  • Keybindings or search query text.

How to opt out

  • Master switch: Settings → General → Telemetry → Enable telemetry to off, or set telemetry.enabled to false in config.json. atrium sends nothing — neither PostHog nor Sentry.
  • Analytics + crash reports off: set analyticsOptIn to false. Tier 1 lifecycle events still flow (assuming the disclosure has been acknowledged), but Sentry is not initialized at all and PostHog feature-usage events are suppressed.
Opting out is persistent. atrium re-checks consent before every outbound request, and Sentry's init runs zero code paths when the flag is off.

How to inspect what is being sent

Run atrium with diagnostics enabled under Settings → Diagnostics. The diagnostics traces include outbound telemetry payloads so you can see what left the app and when. This is also how we developers verify no regressions leak data.

Licensing note

Telemetry is currently always-opt-in before 1.0, and licensing or paid-tier gating is deferred past the 1.0 release. Nothing in the telemetry path is tied to a license check today.

Contact

If you see behavior that surprises you — a request that does not look like it should be happening, a payload that includes more than expected — open an issue and we will investigate.