Development preview · These guides describe unreleased source code.
This page is not available in the selected version. Start with its overview below.
Control optional telemetry
Delegator’s optional telemetry helps the maintainer understand whether consenting instances continue to use the product and which workflows and settings need work. It is configured independently for each Delegator data directory.
Read the complete Delegator privacy notice for the exact data inventory, service providers, local storage, retention, and deletion process.
Choose during setup
Section titled “Choose during setup”Interactive dg init asks whether to enable telemetry while the setting is
null. The prompt selects Yes initially, but viewing it does not grant consent.
Delegator records the choice only when you submit it. Cancelling, reaching end of
input, or leaving setup before submission keeps null; both null and false
send nothing.
Automated setup can submit a choice without a prompt:
dg init --telemetry=truedg init --telemetry=falseWithout that flag, scripted setup preserves the current value or leaves a new
data directory at null.
Read or change the setting
Section titled “Read or change the setting”Use config to inspect, enable, or disable telemetry:
dg config get telemetrydg config set telemetry truedg config set telemetry falseThe get command returns true, false, or null. Setting false prevents new
reports, but it does not contact the collector or erase reports already received.
Re-enabling starts a new consent period and does not fill in days while telemetry
was disabled. To request deletion of received reports, follow the email process
in the privacy notice.
What reports contain
Section titled “What reports contain”After the first explicit Yes, Delegator immediately attempts an installation report. This identifies a consenting initialized instance; it cannot measure all downloads, installations, devices, or people. Daily reports contain aggregate ticket and run counts, normalized agent families, and a snapshot of selected current settings. Delegator does not send ticket text, prompts, source code, paths, project names, logs, errors, command arguments, credentials, or individual ticket and run identifiers.
An installation report without later daily activity does not prove that someone abandoned or uninstalled Delegator. It can also mean brief use, disabled telemetry, no later invocation, a network failure, or an eligible final day that was never sent. Zero-count daily rows confirm reporting coverage; they do not prove active use.
Reports use a random instance identifier stored in the local SQLite database and, when the operating system provides suitable input, an application-specific derived machine hash. Raw operating-system machine identifiers and network-interface addresses are not sent. These values are pseudonymous: they can connect reports from the same instance or machine, but a machine hash may change or be shared and does not reliably represent one person.
Whole-day reporting and retries
Section titled “Whole-day reporting and retries”Daily reports cover only whole Coordinated Universal Time (UTC) days that were fully inside the current uninterrupted consent period. Delegator skips the partial day when you opt in, any disabled or interrupted day, and the current unfinished day. On a later invocation it catches up every eligible day through yesterday, including zero-count days, within the 90-day reporting window.
A failed request does not affect command output or queue work. Delegator rebuilds the request from local data and can retry after at least 15 minutes, or later when the server asks it to wait longer. There is no permanent telemetry process. A request already in flight may still arrive after you disable telemetry.
The collector validates allowlisted fields and removes unknown fields before it stores a small envelope and sanitized JavaScript Object Notation (JSON). Each report has a stable identifier. The first accepted copy is retained, and later retries cannot replace its counts, settings, or receipt time. Linkable reports are removed after 90 days; Cloudflare D1 recoverable history can retain deleted data separately for up to 30 days depending on its service plan.
Deletion is handled by the operator through protected access. A request adds the instance identifier to a revocation register, removes its installation, usage, and settings reports, and prevents delayed reports from recreating them. The revocation record remains for the service lifetime for that limited purpose.
Reference: dg init, dg config get, and dg config set.