Last updated: 15 August 2026
Telemetry Policy
Reticle's CLI and local daemon send anonymous product analytics. This page states exactly what that means, what it can never include, and how to switch it off. It supplements our Privacy Policy; where the two differ on personal data, the Privacy Policy governs.
The engineering detail behind every statement here, the full event list field by field, is published at docs.reticle.sh/telemetry.
The short version
- Anonymous. The only identifier is a random UUID minted on your machine. We cannot tell who you are, and we do not try.
- No code, no app data. Nothing from the application under test (DOM, network traffic, console output, application state, screenshots, source, file paths) never leaves your machine.
- The one exception is feedback you deliberately send, which is never collected passively.
- Opt out permanently with one command:
reticle telemetry disable.
What we collect
A small, fixed set of event kinds, each a single JSON object. In summary:
- Lifecycle. The first run on a machine, daemon start and stop, version changes, and completion of
reticle init. - Usage. Which CLI subcommand ran and which flags were present by name; a count of which tools an agent called, sent once per session as a histogram of tool names.
- Outcomes. That a verification produced a verdict and why it came out that way; the kind of defect Reticle found in an app under test, never what it was found in; that a tool refused a request, which tool, and which of six reason buckets applied.
- Reliability. Uncaught errors in Reticle's own code (error type, Reticle's own stack frames, and the message with variables stripped), agent connection and disconnection, and a snapshot of the machine's own resources (our process's memory, system RAM, load average, CPU count) taken at shutdown and on any crash.
- Project shape. A coarse profile of the project: framework, package manager, and similar characteristics.
Each event carries a locally generated random identifier for the machine and a one-way hash identifying the project. The hash lets us count distinct projects and see that a project came back; it cannot be reversed into a repository, and we cannot look you up from it.
Parameter names are collected. Their values are not.
We record that a tool was called with ref and action, and that you ran reticle serve --headed --port. We do not record what you set them to.
This distinction is the core safety property, and for CLI flags it is absolute: no flag value is ever transmitted, because flags carry secrets (--http-token), URLs (--drive) and file paths (--storage-state). For tool parameters there is one narrow exception: a short, explicit allowlist of parameters whose values are enumerations we defined ourselves, such as action: "click". Any value outside that allowlist is reported as other, so a future change cannot quietly begin forwarding free text. Text typed into the application under test, which on a login form is a password, is never in that allowlist.
What we never collect
Your code. Your application's DOM, network requests or responses, console logs, application state, or screenshots. File paths, project names, or git remote URLs. Your name, email, employer, or any account identifier. Environment variables. Anything typed into the application under test. The names of your flows, baselines, or tests. Error messages, and any stack frame belonging to your application.
Three worth stating plainly, because they are the ones a product team is most tempted by:
- We do not send your project's name or its repository URL. The project identifier is a one-way hash.
- We do not try to work out who you work for. No domain sniffing, no email inference, no matching a repository against a company.
- We do not record what you asked your agent to verify. We know a verification happened and how it turned out. The prompt behind it is not something Reticle can see, and we do not reconstruct it.
Feedback and identification are opt-in, always
Reticle is used by AI agents, and the feedback channel is how an agent reports that a tool misbehaved. Because it is the only part of Reticle that transmits words a person or agent wrote, it is stricter than everything above: there is no code path that sends feedback on its own. A feedback event exists only because someone explicitly invoked it.
Likewise, reticle identify exists only so you can tell us who you are if you want support, an enterprise conversation, or a design-partner relationship. It transmits what you choose to put in it, and nothing runs it for you. Running reticle identify --forget withdraws it.
Where it goes
Events are sent over HTTPS to PostHog (US cloud), a product-analytics provider acting as our data processor, and are used only in aggregate: counts, retention curves, and feature popularity. We do not sell this data or share it for advertising.
Legal basis and retention
Where data-protection law such as the GDPR applies, we process this data on the basis of our legitimate interest in understanding and improving Reticle. We minimise what is collected to the categories listed here and honour every opt-out signal below. The data is designed not to identify you: the only identifier is a locally minted random UUID and the project reference is a one-way hash.
Retention follows the Privacy Policy. To remove the local identifier from your own machine at any time, delete ~/.reticle/telemetry-id.
Your choices
Telemetry is on by default, and Reticle says so the first time it runs: once, in one line, with a pointer to this policy. To see the current state:
reticle telemetry status
Three ways to opt out:
| Method | Scope |
|---|---|
reticle telemetry disable | This machine, permanently, until reticle telemetry enable |
RETICLE_TELEMETRY=0 | Wherever the variable is set. Useful for CI or a fleet-wide profile |
DO_NOT_TRACK=1 | The cross-tool convention, which Reticle honours |
Opting out changes nothing about how Reticle works. A failed or blocked send never delays, alters, or fails a command; sends are best-effort and asynchronous by design.
Changes
Any change to what is collected will be reflected on this page, described at docs.reticle.sh/telemetry, and called out in the release notes of the version that introduces it. We will revise the "last updated" date above.
Contact
Questions, or a request relating to this data? Email hey@reticle.sh. If you believe anything described here falls short of the intent stated above, please open an issue; we treat that as a bug.