Skip to main content
Vibrai’s telemetry is opt-in and off by default. This page is the complete data inventory — everything the CLI (vibrai) and the MCP server (Vibrai.Mcp) can ever send, and everything they never send, regardless of settings. If something isn’t listed here as collected, it isn’t collected.
This is a factual inventory, not marketing copy. Where we’re not certain of an exact figure (retention days, for example) we say so rather than promise a number we can’t guarantee.

​
The two-key gate

Telemetry only sends data when both of the following are true at once:
  1. You’ve recorded consent — you ran vibrai telemetry enable.
  2. A delivery destination is configured — the VIBRAI_SENTRY_DSN environment variable points at a Sentry.io project.
A default install has no DSN baked in. That means running vibrai telemetry enable on a typical install still sends zero bytes — consent alone isn’t enough. Both keys have to be present before anything leaves your machine. vibrai telemetry status always tells you which of the two keys is (or isn’t) set, and whether telemetry is effectively active as a result.
If a future Vibrai build ships with a maintainer-configured DSN baked in ahead of time, that changes which installs have key #2 satisfied by default — and this page will say so plainly, naming it as a Sentry.io project DSN. As of this writing, no build ships with one.
Live-set names and instrument tag strings are NOT collected, even though an earlier design draft considered it. A set name can encode a client name or an unreleased track title, so the debugging value didn’t clear the privacy bar. This is a deliberate default, not an oversight.

​
What’s never collected

The following are never collected, under any settings, on any passively-collected telemetry event, breadcrumb, or span. A scrubber runs last on every event, in every host, and fails closed: if it can’t fully process an event, that event is dropped rather than sent raw.
  • Filesystem paths — absolute or relative, home directories, project locations. Any path-shaped token is redacted or removed entirely.
  • .vibrai / .vibraigenre file contents, and any captured project YAML. Never read into an event. (The one exception, described below, is a SHA-256 hash — never the contents — sent only via vibrai feedback.)
  • MIDI note data, clip contents, arrangement data — your music, never.
  • Prompt text or other natural-language input you type to an agent or the CLI.
  • License keys, DSNs, tokens, secrets, or environment variable values. Environment variables are never enumerated into an event.
  • Any personally identifying information — no name, email, IP address (Sentry’s IP capture is disabled at the SDK level), MAC address, hostname, username, or OS account. This ban is absolute for every passively-collected event. The one carve-out is described next.
  • Session replay or screen recordings. Sentry offers this as a product feature; Vibrai disables it at the SDK-configuration level, not just by leaving it unused.
  • Set names and instrument tag strings — see the note above.
  • Anything in a command argument or tool-call payload, other than the bare operation name itself.

​
vibrai feedback / submit_feedback: the one place you type something in

vibrai feedback (CLI) and submit_feedback (MCP) are a deliberate exception to “passively collected,” because you’re explicitly typing something in order to send it. Scrubbing your own message before sending it would make the feature a silent no-op, so: Everything in that bundle other than your message and (optional) email still goes through the same never-list scrubbing as passive telemetry — the exemption is narrowly scoped to the two fields you explicitly typed. Consent doesn’t gate feedback the way it gates passive telemetry. If consent is off, or you pass --no-send, the bundle is written to ~/.vibrai/feedback-<timestamp>.json instead of being sent, and Vibrai prints the file path plus a GitHub issue URL so you can attach it by hand. Feedback is never sent silently.
See the full parameter reference: feedback (CLI) / submit_feedback (MCP).

​
Retention

Event and trace retention is governed by whichever Sentry.io plan tier Vibrai’s backend project is on at any given time — there’s no separate, custom retention configuration to audit. At the time this policy was written, the plan under consideration was Sentry’s Team tier, whose documented retention is 90 days; we’re recording that as the figure we were planning against, not as a contractual promise this page can guarantee going forward. If you need the authoritative current figure, ask us directly rather than relying on this paragraph to stay perfectly in sync with whatever plan is active.

​
install_id: what it is and how to reset it

install_id is a randomly generated UUID, created the first time you run vibrai telemetry enable and stored in ~/.vibrai/telemetry.json. It’s the one stable token telemetry attaches to your data:
  • It identifies an install of Vibrai, not a person.
  • It’s scoped to this machine’s install — no cross-machine or cross-account linkage.
  • You can reset it at any time by deleting ~/.vibrai/telemetry.json. The next vibrai telemetry enable generates a fresh one, severing the link between past and future telemetry.

​
Controlling telemetry

Consent can only be granted or withdrawn from the CLI — enabling telemetry is a decision only a human should make, so no MCP tool can flip it. The MCP surface exposes a read-only status check instead.

​
When disable takes effect

Immediately for everything that reads consent per use: every new vibrai CLI run, every call Vibrai makes to the Live bridge (consent is re-checked per request, and the Max-for-Live device is told to shut its own reporting down), and every vibrai feedback submission — which falls back to writing a local file instead of sending. The one exception is a Vibrai MCP server that is already running with telemetry active. It initialized its crash reporter at startup, and nothing watches the consent file to tear that down mid-process, so it keeps reporting until it restarts. Restart the MCP server (or the app hosting it) if you want the change to apply there too. status (both surfaces) reports two distinct facts: whether consent is recorded, and whether telemetry is effectively sending anything (both gate keys satisfied). A user with consent on but no configured VIBRAI_SENTRY_DSN is still sending zero bytes — status says so explicitly rather than collapsing that into a bare “off.” The very first time you run any vibrai CLI command, you’ll see a one-line disclosure on stderr pointing back at this page — it’s informational only and never enables anything by itself. See the full parameter reference: telemetry (CLI) / telemetry_status (MCP).