## Why Telemetry cannot tell a physical iPhone from a simulator: `platform` is `ios` for both, and the tool-server's `kind` never reaches the events. Physical-iOS support shipped in 0.24.0 with no way to count its adoption except through `ios_device_*` failure stages on `tool:fail`. Physical Android phones have the same gap. ## What `tool:invoke` / `tool:complete` / `tool:fail` gain `device_kind: simulator | emulator | vvd | device | app`, derived from the same device id as `platform` (single classifier in `telemetry-platform.ts`, which `debugger:tool_outcome` and `lens:*` also go through for their platform). `platform: ios` + `device_kind: device` is a physical iPhone. The kind is emitted only for positively recognised id shapes, so the metric is not polluted by ids that are not devices: | id shape | platform | device_kind | |---|---|---| | simulator UUID / `remote:` | ios / ios-remote (tvos when the cache is warm) | simulator | | physical iPhone UDID | ios | device | | `emulator-NNNN` | android (android-tv when warm) | emulator | | USB serial, 6–20 alnum with a digit and a letter | android | device | | non-loopback `ip:port` | android | device (best effort) | | loopback `127.0.0.1:port` / `localhost:port` / `::1:port` | android | emulator | | anything else non-iOS-shaped (Metro 40-hex handle, `booted`, `Pixel_7`, IPv6, mDNS) | android | omitted | | `chromium-cdp-<port>` / `amazon-…` | chromium / vega | app / vvd | | `avdName`-only boot | android | omitted | A child sub-tool that names its own device replaces the parent's platform, kind and provider label wholesale, so an `avdName`-only child never reports the parent's `simulator` next to its own `android`. A logical-keyed Metro session strips the kind. `unknown` (in the registry `DeviceKind`) is rejected by the sanitizer like `platform: "unknown"`; no registry change. ## Querying - Physical iPhone adoption: `tool:invoke` where `platform = 'ios' and device_kind = 'device'`, distinct users over it. `isIosPhysicalUdid` is a positive match, so invoke is clean. - Physical Android: count on `tool:complete` (the device answered). `tool:invoke` / `tool:fail` still carry residual mistakes that happen to look like a serial (`Pixel7`), and a non-loopback `ip:port` may be a networked virtual device. ## Docs - `Telemetry.md` → 1.04, effective date 7 September 2026 (adjust to the release date on merge). Discloses the new category and, while touching that section, the external-provider label that #735 added without a notice line — happy to drop that second bullet if it should ship separately. - No docs-site change: `docs/reference/telemetry.mdx` links to `Telemetry.md` and has no per-property list. ## Notes - Pre-existing, unchanged: HTTP-edge failures carry no `tool_invocation_id`; `stop-all-simulator-servers` declares no capability, so its invoke row has neither field while its fail row has both. `device_kind` follows `platform` in each site. - Legacy 40-hex iPhone UDIDs already classify as `android` today; they now get no kind rather than a wrong one. - Design went through three adversarial review rounds before implementation and one on the diff; the fallback-bucket and child-attribution rules above came out of those. ## Verification - `packages/telemetry`: 319 tests, `packages/tool-server`: full suite 5670 passed / 1 skipped; `typecheck:tests` both packages; `eslint --max-warnings 0`; `knip`; prettier. - New: `test/telemetry-device-kind.test.ts` (the shape table above), plus cases in `http-tools-meta`, `http-platform-alias`, `sanitize`, `registry-listener`. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01BSGpeAwvoCv2JAhbLsuto2 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Telemetry now records a device category—such as simulator, emulator, physical device, virtual device, or desktop app—alongside the platform. * Device categories are inferred from device information and may include a short label for external device providers. * Device category information is included in tool invocation, completion, and failure telemetry when available. * Device identifiers themselves continue to be excluded from telemetry. * **Documentation** * Updated the Argent Privacy Notice (Telemetry) to version 1.04, effective 7 September 2026. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
9.2 KiB
Argent Privacy Notice (Telemetry)
Effective date: 7 September 2026 · Version: 1.04
This notice is a product-specific supplement to the Software Mansion Privacy Policy (the "Policy") and applies to telemetry collected by Argent, a Software Mansion Software Product. Capitalised terms used but not defined here (including Personal Data, Usage Data, Legitimate Interest, EEA and Software Mansion Software Product) have the meaning given to them in the Policy. Where this notice and the Policy differ in respect of Argent telemetry, this notice prevails.
Argent collects a small amount of usage and diagnostic data ("telemetry") to help us understand how the tool is used and to make it more reliable. We have designed it to be minimal by default: we do not collect the content of your work - no source code, no file paths, no tool inputs, no application data, no error messages, and no device identifiers.
How to opt out
Telemetry is enabled by default. You can disable it at any time, and the change takes effect immediately and permanently for that installation. This is also how you exercise your right to object (see Your rights below).
argent telemetry disable
To check the current status:
argent telemetry status
Disabling telemetry does not affect any functionality of Argent.
Why we collect telemetry
We use telemetry, in our Legitimate Interest, only to:
- understand which features are used, so we can prioritise development;
- detect where installation, updates, or tools fail, so we can fix them;
- measure reliability and performance (e.g. how long operations run, error rates);
- understand the environments Argent runs in (operating system, runtime versions, terminal vs CI);
- measure how many distinct devices use Argent, without over-counting reinstallations.
We do not use telemetry for advertising, marketing, profiling, automated decision-making, or sale of data, and we never combine it with any account or with Personal Data collected through other Services.
What we collect
Installation, update and uninstallation
- the progress of an installation: which options were selected; whether it started, completed, failed, or was cancelled; and at which step it was cancelled;
- the progress of an update to a newer version;
- the progress of an uninstallation of Argent.
Tool and process usage
- which Argent tools are invoked, and whether they succeeded or returned an error;
- which AI coding tool is driving Argent;
- how long a process ran in the terminal or in CI, and which Argent component emitted the event;
- start and stop of the Argent tool-server, its uptime, the number of tools used, and the reason it stopped.
Design review (Argent Lens)
When you use the Argent Lens design-review flow (previewing and choosing between proposed UI variants), we collect aggregate, non-content signals about the review interaction:
- that a human opened the review preview for a round, and whether the review was completed or abandoned;
- per-round aggregate counts only: how many elements and variants were proposed, and how many per-element comments, skipped-element comments, and free-form annotations were left — never the comment text, element names, variant code, or file paths;
- whether a round carried a round-wide comment, and whether the optional comment inspector or "reveal off-screen choices" affordances were used;
- how long a review round took, from the first proposal to submission;
- how many times the
argent lenscommand was run, and how many coding-agent choices its picker offered (a count only, never the agent names).
Environment
- Argent version, Node.js version, operating system, processor architecture;
- whether the process runs in an interactive terminal and whether it runs in a CI environment;
- whether Argent is used in connection with Android, iOS, tvOS (Apple TV), Android TV, VegaOS, or a Chromium-based target, and whether that target is a simulator or emulator, a virtual device, a physical device, or a desktop application. This category is inferred from the form of the device identifier; the identifier itself is never recorded;
- when a device is supplied by an external device provider, a short label for that provider (the leading segment of the name the provider registers under), never the identifier of the device it supplies.
Diagnostics
- the fact that an error occurred (event type and code only — never the error content or message);
- when a tool call is rejected because its parameters fail validation: which parameter names failed. These names come exclusively from Argent's own published tool schemas — never the values you supplied, and never key names you typed that are not part of the schema (an unrecognised key is recorded only as the fixed marker "unrecognized_keys", not the key itself);
- the outcome of a debugger connectivity check, recorded as one of a fixed set of coded reasons (for example: connected, Metro not running, no app attached) — never the underlying error text.
Identifiers
- an installation identifier used to distinguish devices and to de-duplicate events. It is a one-way HMAC-SHA256 hash derived from a device identifier: the raw device identifier is never transmitted or stored and cannot be recovered from the hash. The identifier is stable across installations and reinstallations of Argent on the same device, so that reinstalling Argent does not create a new counted user. It is not linked to your name, username, or any account;
- a random session identifier generated for each usage session.
What we never collect
To be explicit, Argent telemetry never includes:
- tool input or argument values (for a rejected call we record only which schema-declared parameter names failed validation, as described under Diagnostics — never their values, and never key names that are not part of Argent's own schemas);
- file paths or file names;
- source code or its contents;
- application data;
- device identifiers (e.g. hardware IDs, MAC addresses, serial numbers);
- the content or text of error messages.
Who we disclose the data to
Telemetry is transmitted using the OpenTelemetry protocol to a telemetry collector operated by Software Mansion, the controller named below. We do not share it with a third-party product-analytics provider.
Telemetry data is stored within the European Economic Area (EEA). Where we rely on an infrastructure provider (for example, cloud hosting) to operate the collector, that provider acts as our processor under a Data Processing Agreement and is engaged on the basis of EEA hosting; we keep any such list of sub-processors to a strict minimum, and the current list is available from us on request.
Legal basis for processing
The controller is Software Mansion S.A. (details below). To the extent that the telemetry described here constitutes Personal Data, we process it on the basis of our Legitimate Interest (Article 6(1)(f) GDPR) in maintaining, securing, and improving Argent, consistent with the legitimate-interest grounds set out in the Policy. We have carried out a balancing assessment, taking into account the minimal and non-content nature of the data and the simple opt-out above, and concluded that this interest is not overridden by your interests or fundamental rights and freedoms. You may object to this processing at any time by opting out.
How long we keep the data
Telemetry events are retained for up to 72 months, after which they are deleted or aggregated into non-identifiable statistics.
International data transfers
Telemetry data is stored within the EEA. Should any access from outside the EEA occur (for example, for support or to operate our infrastructure), it is governed by an appropriate transfer mechanism, such as the European Commission's Standard Contractual Clauses.
Your rights
Subject to the conditions in the GDPR, you have the right of access, rectification, erasure, restriction of processing, data portability, and the right to object, as described in the Data Subject Rights section of the Policy. Because the data is not linked to a named individual or account, we may be unable to identify your specific records without additional information from you (Article 11 GDPR); the most effective way to stop processing is to opt out as described above.
To exercise these rights, contact us at legal@swmansion.com.
You also have the right to lodge a complaint with a competent supervisory authority. In Poland this is the Personal Data Protection Office (UODO), ul. Stawki 2, 00-193 Warszawa.
Controller and contact
The controller of your Personal Data is Software Mansion S.A., a joint stock company with its principal place of business at ul. Zabłocie 43b, 30-701 Kraków, Poland, entered in the register of businesses conducted by the District Court in Kraków for Kraków-Śródmieście, XI Commercial Division of the National Court Register with KRS number 0000961952, NIP 6793131302, REGON 364909814.
For any questions or requests regarding this notice, contact us at legal@swmansion.com.
Changes to this notice
We may update this notice as Argent evolves. The most current version will be available with the effective date and version shown at the top, and material changes will be announced through the usual Argent release channels.