Telemetry

Styre keeps three kinds of record, and it is worth being precise about which is which — because two of them never leave your machine, and the third is anonymous and small.

The run database — your local record

Everything a run does is written to a SQLite database as it happens: the ticket, the work units, every step and its result, every agent dispatch, the ground-truth verdicts, the review findings, and the acceptance checks. This is the run’s state of record — it is what makes a run auditable after the fact and resumable if it dies.

This database is local. It lives on your machine — a throwaway file per run, or one you manage with --db — and Styre never sends it anywhere. See Files and paths for where it sits.

The run stream — stdout and stderr

While a run is going, it emits two streams and keeps them strictly separate:

• stdout carries NDJSON telemetry — one JSON object per line, each tagged with a type. There are five: event (a step happened), dispatch (an agent ran), signal (a ground-truth verdict), summary (the once-per-run rollup), and ci_handoff (the one CI read at PR-open).
• stderr carries everything a human reads — progress, the final summary, warnings.

styre run ENG-482 | jq -c 'select(.type == "dispatch")'

That split is the whole point: you can pipe a run into jq, a log pipeline, or a file and get clean machine-readable output, while still watching the human version in your terminal.

Like the database, this stream is yours. It goes to your terminal, or wherever you redirect it. Nothing about it phones home.

Product analytics — what leaves your machine

Styre sends anonymous usage analytics, to help understand how it is used in the wild. This is the only telemetry that leaves your machine, so here is exactly what it is.

Four events, and only four: setup finished, a run started, a run finished, and a command errored.

The identity is a random number. On first use Styre generates a UUID and stores it in telemetry.json. It is not derived from your machine, your user, your repo, or your keys — it exists only to tell one install’s events apart from another’s.

Everything is bucketed, and nothing is free text. A run’s event does not carry “47 dispatches”, it carries “21–50”. Not a duration but “15–60m”. Failure reasons are mapped to a fixed set of categories before they are sent; the raw text never is. What can be sent is a fixed allow-list of keys, enforced in code — the version, your OS and architecture, whether you are in CI, coarse bucketed counts, and the run’s outcome.

What is never sent: your code, your ticket text, your repo name, file paths, commit messages, credentials, agent output, or anything an agent wrote. None of it is on the allow-list, and the allow-list is what governs the wire.

Turning it off

Analytics is on by default. Any one of these turns it off:

How	Effect
telemetry: false in config	Off for runs that read that config.
STYRE_TELEMETRY=0	Off, by environment variable.
DO_NOT_TRACK=1	Off — Styre honours the Do Not Track standard.

Any one of them is enough; they do not need to agree. The two local records — the database and the run stream — are unaffected, because they never left your machine to begin with.