Crash Data Privacy Policy

The facts

Here is the short version:

• Nothing is uploaded by default. A record is sent only when you click Report in the prompt, and we ask every time before sending.
• Before anything is sent it is scrubbed: your username, email addresses, API keys and tokens, and the user folder in file paths are removed or replaced, and URLs lose their query strings.
• Crash records carry no account identifier. We do not send a user ID, device name, breadcrumbs, request data, or session content with crash data; conversation and file content do not appear in error messages.
• The memory snapshot of a native crash (a minidump) is attached only when you click Report; our server discards the original file as soon as it has extracted the stack.
• You can turn reporting off entirely in Settings. When off, records stay only on your device, and you can still report one manually from the notification center.

What we collect

When BiRoot Studio hits an uncaught error, a renderer or child process exits unexpectedly, the app crashes natively, or its Roost component panics, we create a crash record for the incident, stored in the app data folder on your device. A record contains:

• the error type and message (truncated to a limited length), and the call stack: function names, file paths, and line numbers, keeping at most a limited number of frames nearest the failure;
• the app version, release channel, and environment;
• the operating system name and version, and the CPU architecture;
• for native crashes, a memory snapshot file (a minidump), written only to your machine and sent only if you choose to;
• the interface component stack (for interface-level errors), and the code location and thread name of a Roost panic.

What we never collect

The following never enters a crash record, and there is no code path that could add it:

• your conversations, prompts, or AI responses;
• your file contents, repositories, or folder trees;
• your account email, user ID, or sign-in credentials;
• your AI provider API keys or connector tokens (token-shaped strings are replaced wholesale with [redacted]);
• clipboard contents, screenshots, or screen recordings;
• breadcrumbs, page requests, or any other analytics-style behavioral data.

How records are scrubbed

Every record is scrubbed as it is written locally; what gets sent is the scrubbed version. The rules are deterministic, pure functions covered by unit tests:

• your home directory is replaced with ~ (so /Users/yourname/... is kept only as ~/...), and your system username (when 3 or more characters) is replaced with [user];
• email addresses become [email]; URLs lose their userinfo and all query parameters;
• values of sensitive keys such as key=, token=, and password= become [redacted]; known token formats (sk-, ghp_, xox, AKIA, JWT) and sufficiently long hex or base64 runs are replaced wholesale;
• error messages are capped at 300 characters, each stack-frame field at 200, and extra text at 1000; anything longer is truncated.

One honest caveat: the memory snapshot of a native crash contains slices of each thread's stack memory, and strings from the moment of the crash may survive in them. That is exactly why it is not sent by default and why the server discards the original file as soon as it has extracted the stack. You can send the error record without the snapshot.

Where it goes and how long it is kept

Records you report are sent over HTTPS to our own crash collection service at report.biroot.com (a self-hosted Sentry used for errors only). We do not use a third-party crash cloud. On arrival:

• the server parses the stack and groups the problem with similar ones, to locate and fix defects;
• the server does not keep raw memory snapshot files; they are discarded once parsed;
• parsed events are synced into our own database as the record of truth, and the Sentry side deletes them after 90 days;
• an event shares one identifier across all three systems, so a deletion request can find it everywhere at once.

Records kept on your device are pruned after 90 days or 200 records, whichever comes first; the oldest records and their memory snapshots are deleted automatically, and a snapshot is deleted from your device after its record is successfully reported. Deleting Studio's application data folder removes all local records immediately.

Your choices

The first time something goes wrong, Studio asks whether you want to allow reporting; even after allowing, we still ask before each send. If the app crashed and could not ask, it asks at the next launch. At any time you can:

• turn crash reporting off in Settings. There is then no upload path at all; records stay local, and you can still choose Report on a single record in the notification center;
• choose Not now on any prompt to skip that record;
• click View what will be sent before reporting, to read the exact content that would leave your device, including attachment names and sizes.

Our promises

• we will never attempt to identify or track you with crash data, and the data itself carries nothing that identifies you;
• we do not sell crash data, and we do not use it for advertising or product analytics;
• crash data is used only to fix defects, never to train or improve AI models;
• without your consent, not one byte leaves your device; this is guaranteed by construction: the crash collector starts in local-only mode and the whole pipeline has exactly one network exit, triggered only by your click in the interface.

Development and test builds always keep records local and never upload, regardless of settings.

Contact

Questions, suggestions, or deletion requests about crash data can go to [email protected]. Deletion requests cover reported records too: we can delete the matching events in every system by their identifier.