Telemetry and privacy

What the cua SDK, the cua CLI, cua daemon, cua-spacesd and the Cua Spaces app collect, what they never collect, and how to turn it off.

Cua collects usage data so we can see which features are used and where things break. It's on by default, like in VS Code or Docker Desktop. It never contains your content: no files, file paths, names, emails, prompts or screen content, only fixed event names and counts. When you're signed in, it's linked to your Cua account through a random account ID. You can see every event before or after it is sent, and turn it off with one switch.

Turn it off#

Any of these turns usage telemetry, and the Spaces app's crash reports, off for every Cua program on the machine (SDK in any language, cua CLI, cua daemon, the Spaces app, and Cua Driver):

CI environments (CI, GITHUB_ACTIONS, BUILDKITE, ...) are off by default. CUA_TELEMETRY=1 turns them on, and their events are marked is_ci. The older CUA_TELEMETRY_ENABLED=false and CUA_DRIVER_RS_TELEMETRY_ENABLED=false still work.

See what is sent#

cua telemetry status      # on or off, why, and the properties every event carries
cua telemetry show-last   # the last events, exactly as sent
cua telemetry schema      # every event and property, with its allowed values
cua telemetry reset-id    # a new anonymous install id

Nothing is sent from a machine until the first-run notice has been shown there once (in the terminal, or in the Spaces app's onboarding or Settings). The process that shows it sends nothing. In the Spaces app the notice is on the first run's Welcome page, next to a "Share usage data to help improve Cua" switch: nothing is queued or sent until you leave that page, and if you turn the switch off there, nothing is sent at all (the setting is saved for every Cua program on the machine).

Linked to your account when you're signed in#

When you're signed in, usage data is linked to your account so we can see where people get stuck. We see which steps you reached, not what you did.

• A random account ID. The Cua service gives a signed-in app or CLI an ID like acct_3f9c..., a one-way code made from your account. It is never your email, name or sign-in id. One PostHog $identify joins this install's earlier events to it. The Spaces app asks for it when you sign in and each time it starts; the CLI and the SDKs when you sign in, and at most every few hours while you stay signed in.
• You see it first. Nothing is linked before the notice has been shown on this machine. Installs that saw the older "anonymous" wording get a one-time notice with "Turn off usage data" right there.
• Off means off. Signing out, cua telemetry off and cua telemetry reset-id unlink this machine. cua telemetry status shows whether it's linked.

Our service also records sign-ups, checkouts and subscription changes under the same ID, and the hosted relay records your hourly relay usage (sessions and hours against your plan, and relay_plan_limit_refused when it turns down a new session over a plan limit). Those are records of our service, so the switch doesn't change them.

How it works#

• Install id. 128 random bits in $CUA_HOME/telemetry/install_id, created on the first event actually sent, never while telemetry is off. It is not derived from your machine or account. reset-id deletes it.
• No location. Every event sets $geoip_disable: true. Like any HTTPS request, the upload reaches PostHog (EU) from your IP address; it is never an event property and is not used for location. Events that aren't linked to an account set $process_person_profile: false; linked events belong to the account's PostHog person, which never holds a name or an email.
• Closed vocabularies. Every property is one of a fixed list of values, a bucket, a boolean or a version. An image reference that is not in the public image catalog is sent as custom; an app outside the public teleport catalog as other; an error as its category (not_found, timeout), never its message. An event with any other property or value is dropped before it is queued.
• Never in the way. Events go out in batches from a background thread with a 3 second budget. Offline, up to 500 events wait on disk for 7 days at most. Exiting waits at most 0.4 seconds.

What is collected#

A fixed set of events with closed-vocabulary properties. The full list, each property and why it is collected: Telemetry events.

The Cua Spaces app also sends crash and error reports, when it crashes or hits an unexpected error. They go to Sentry, not PostHog, and the same switch controls them. A report holds the app version and channel, the operating system and CPU type, which part of the app failed, and the call stack (names of Cua's own functions, never your files). It never holds the error message, screen content, screenshots or your Space names. The app also counts one anonymous session per launch, so we can tell what share of launches end in a crash. What is in a report, how it is cleaned, and what we use it for: Crash and error reports.

Durable agents#

When you run an agent with --durable, or make a durable Space, the machine that keeps the account's sessions sends a few events about how it went: that it started, that it was restarted and why (the process exited, it printed nothing for too long, its machine stopped answering), that it moved to another machine, how long recovery took, that it ran out of attempts, and how it ended (done, failed or stopped). They hold fixed words and counts, and a random-looking hash of the session so the events of one session can be put together. They never hold the task, prompts, tool inputs or outputs, file paths, repository names, keys, your email, or the names of your machines, sessions or Spaces. They follow the same switch as everything above: cua telemetry off, CUA_TELEMETRY=0 or DO_NOT_TRACK=1 stops them. See cua_durable_agent in the event list.

What we use it for#

To answer how many people install Cua Spaces, finish the first run, sign in, make a first Space, teleport and run an agent; where creates fail or stall; which features are used; and who still uses Cua a day, a week and a month later. The funnel joins events on the install id, and on the account ID once you sign in. The first_* steps are sent once per install. How installers, an AI agent using a Space, agent runs and retention are counted: How events are counted.

Never collected#

File paths, file names, names, usernames, hostnames, IP addresses, emails, window titles, URLs, clipboard, keystrokes or typed text, screenshots, screen or accessibility content, prompts, model output, sandbox or Space names, error messages, and anything stored in the Keyvault (only consent decisions are counted). Tests enforce this: every event builder is fed paths, emails, hostnames and window titles, and none may appear in a payload. The same holds for crash reports: the app's crash reporting is also fed paths, emails and hostnames in tests, and none may leave it.