Privacy & Diagnostics
Privacy & Diagnostics is the App Settings section that holds NEXUS's two optional telemetry categories. This page describes that section for versions of NEXUS that include it. If your version has no Privacy & Diagnostics section, NEXUS sends no telemetry at all, and nothing below applies yet.
Both categories are off by default. Until you turn one on, NEXUS creates no identifier, queues nothing, and never contacts a telemetry service — and turning one category on does not turn on the other. Declining costs you nothing: no feature depends on either switch, and nothing asks again on a schedule.
Like every App Settings control, everything here applies the instant you change it — there is no Save step.
Controls
| Label | What it does | Default |
|---|---|---|
| Share anonymous usage statistics | Sends which parts of NEXUS are used, how often, and whether operations succeed. | Off |
| Send anonymous crash & error reports | Sends crash, hang, and internal-error reports with call stacks, but never content. | Off |
| Status | Read-only, per category: Off, On since a date, Paused (the disclosure changed, or Chainabit paused the category from its side), or Locked by your organization. | Off |
| Identifier | Read-only, per enabled category: a short identifier prefix, with Copy. | — |
| Queued & sent data | Opens a local view of what is waiting to be sent and what has been sent, per category. | — |
| Reset & delete previous telemetry | Asks Chainabit to delete what each enabled category has sent so far, then starts that category over with a new identifier. | — |
| Consent history | Read-only: every decision made here or in the welcome tour, newest first. | — |
| Privacy Policy / Terms of Service | Opens the same documents linked from Terms & Policies, and shows which version of the disclosure your decision was made under. | — |
Where you decide
The first time you launch NEXUS, the welcome tour includes a card titled Help improve NEXUS with the same two switches, both off, and a single Continue button that means the same thing whichever way the switches are set. Dismissing the tour leaves both off. If you never decided, the card is offered once more later, after you have used NEXUS for a while — and never again after that; from then on, this section is the only place the choice lives.
An agent can see whether a category is on through the local MCP settings tools, but no tool can change it. Only a person can, here or in the welcome tour.
The two categories
Usage statistics answers product questions — which destinations get used, how long sessions last, whether a Marketplace install succeeds — as event names paired with values drawn from short fixed lists. A session's length is reported as a bucket such as "10 minutes to 1 hour", never as an exact figure; a plugin is reported by its public Marketplace id, and one installed from elsewhere as "other".
Crash & error reports answers reliability questions. On macOS, crash and hang reports come from the operating system's own diagnostics service, which hands them to the app after the fact rather than at the moment of the crash. A report carries the signal or exception type, a call stack whose frames name only NEXUS's own executables and system frameworks (any other image is reduced to "other"), the app and OS versions, and a short trail of the names of the last events before the crash. Free-text error messages, process paths, and environment variables are dropped before the report is queued. A crash that happened before you turned this category on is never sent, even if the report arrives afterwards.
What is sent
Uploads happen in small batches over an encrypted connection to a Chainabit-operated endpoint dedicated to telemetry, separate from anything your account does. Every batch belongs to exactly one category. A batch of usage statistics looks like this, trimmed to the fields that matter to you:
{
"category": "analytics",
"sent_at": "2026-09-06T10:00:03Z",
"catalog_version": 1,
"ctx": {
"app_version": "1.0.0",
"channel": "stable",
"platform": "macos",
"os_major": 15
},
"events": [
{
"name": "screen.viewed",
"ts": "2026-09-06T10:00:01Z",
"session_ref": "9f1c3a7b2d4e6f80",
"props": { "destination": "agents", "entry": "rail" }
}
]
}| Field | What it is |
|---|---|
category | Which switch this batch belongs to. A batch never mixes the two. |
sent_at, ts | When the batch was sent and when each event happened, to the second. |
catalog_version | The version of the published list of allowed event names and values. |
ctx | The app version and release channel, the platform, and the operating system's major version. Nothing else: no language, region, hardware model, memory size, account, or plan. |
name | One of a fixed list of event names. An event not on the list cannot be produced. |
session_ref | A one-way reference to the current launch of the app. The two categories use different references, so usage rows and crash rows cannot be joined. |
props | Only values from fixed lists or ranges. There is no free text anywhere in an event. |
Not shown above: each batch also carries the token Chainabit issued for that category when you turned it on. It is a random value, not derived from your hardware or your account, and the two categories' tokens are unrelated. The Identifier row shows its short prefix.
What is never collected
None of the following can appear in either category. The list is enforced by the app — the event vocabulary has no place to put any of it — not merely promised.
- Prompts, messages, and agent thoughts
- Terminal input and output, commands, and command history
- Clipboard contents
- File contents, file names, paths, and working directories
- The names of your workspaces, agents, teams, sessions, channels, and canvases
- Repository URLs, remotes, and branch names
- Marketplace search text
- Environment variables
- Credentials, tokens, keys, and licence keys
- Your account identity: email, username, account id, workspace id
- Hardware identifiers: serial number, platform UUID, network address, model name
- Your IP address or location. The address an upload comes from is used to rate-limit the request and is not stored with the telemetry data; as with any web request it may appear in ordinary connection logs, which the Privacy Policy covers.
- Free-text error messages
- Audio, transcripts, and screen content, including anything the browser tools capture
- Knowledge content: memory, wiki pages, notes, and bits
- Notification text
- Anything from the transcripts or configuration of the CLI providers you run
Inspecting queued and sent data
Queued & sent data is read entirely from files on your machine; nothing in it is fetched from a server. Per category it shows the current status, when the token was issued, the disclosure and catalog versions, the last successful upload, and lists of events queued, sent (the last 200), rejected by the service (with the reason), expired unsent, and dropped locally (with the reason). Event rows show the name, the time, and the properties — all of which are safe to show, because none can hold content. Any pending deletion request appears here too, with its state.
Turning a category off
Turning a switch off takes effect immediately:
- Recording for that category stops.
- Its queue is deleted from disk.
- For crash & error reports, crash-report collection is unsubscribed and the local crash-detection marker and event trail are removed.
- A deletion request for what that category has already sent is written to disk, then the token is discarded. The request is retried whenever a connection is available and never expires; the status line reads Deletion requested — waiting for connection until Chainabit acknowledges it, then Deletion acknowledged with the date by which deletion completes.
Chainabit deletes the data shared in that category within 30 days after your device delivers the deletion request. If the device never reconnects, the data is deleted automatically when its retention period ends: 90 days for usage statistics, 180 days for crash & error reports. Aggregate daily totals that contain no identifier are kept longer and are not affected by deletion. The authoritative retention and deletion terms are those in the published Privacy Policy; where this page and the policy differ, the policy governs.
Reset & delete previous telemetry
Reset & delete previous telemetry does, for each category that is on, exactly what turning it off does — a deletion request for everything sent so far — and then turns it back on with a fresh token. What NEXUS sends from that moment cannot be joined to what it sent before. Offline, the deletion request waits for a connection, and new events are held locally until the new token arrives. A category that is off is untouched.
If the disclosure changes
A decision is valid for the version of the disclosure it was made under. If an update changes what telemetry involves — a new category, purpose, or processor — both categories show Paused and stay off until you decide again; you see one non-blocking card at the next launch and can otherwise ignore it. Changes to the Terms or Privacy Policy that do not concern telemetry never touch these switches.
Organization policy
An organization can restrict these categories — never enable them — with a managed preference named TelemetryAllowedCategories, delivered through a configuration profile for the NEXUS app. Its value is an array containing analytics (usage statistics), diagnostics (crash & error reports), both, or neither:
| Value | Effect |
|---|---|
| Key absent | Both categories are available; your own choice applies. |
["analytics"] | Only usage statistics can be turned on. |
["diagnostics"] | Only crash & error reports can be turned on. |
[] | Both are locked off. |
Only a value that is forced by management counts; the same key merely present in preferences is ignored. When a policy locks a category that is currently on, NEXUS treats it exactly as if you had turned it off, deletion request included, and the switch shows Locked by your organization.
Files on disk
Everything this section works with lives under one owner-only directory, created the first time a category is turned on:
~/.chainabit/nexus/telemetry/| Path | Holds |
|---|---|
analytics/seg-*.jsonl, diagnostics/seg-*.jsonl | Queued events waiting to be sent, one per line. Deleted when the category is turned off. |
sent.local.jsonl | The last 200 events sent — what Queued & sent data reads. |
tickets.local.json | Deletion requests until acknowledged, kept 30 days longer so the outcome stays visible. |
epochs.json | When each category was turned on. Reports produced before that moment are never sent. |
policy.json | The last policy received from the telemetry service — for example, an event family paused from Chainabit's side. |
launch-marker.json | Written only while a category is on; lets the next launch tell a clean exit from a crash. |
crash/ | Crash and hang reports awaiting processing, only while crash & error reports are on. |
.lock | Ensures one NEXUS process at a time writes here. |
The two .local. files are covered by the same rule that keeps credential files out of version control — a deletion request carries the discarded token until the service acknowledges it. See Paths & Credentials.
What these switches do not control
Each of the following is a feature you invoke, governed where it lives, and none of them is affected by this section:
- Signing in and entitlement checks — Account.
- Feedback — the form sends the text you typed, only when you press Send, and never attaches logs.
- Cloud Rooms — a workspace's room mode, which you choose per workspace.
- Update checks, which run while you are signed in.
- 3D Room asset downloads and Marketplace browsing and installs.
- The telemetry settings of the CLI providers you run, which each provider controls on its own.
Where to go next
- Settings reference — the control-by-control contract for this section.
- Paths & Credentials — the telemetry directory alongside every other file NEXUS keeps.
- Local-First — the stance this section is the one deliberate, opt-in exception to.
- Terms & Policies — the Privacy Policy that governs retention and deletion.