Agent RemoteWhat we store
- Your email and (optionally) name, and a hashed password if you set one.
- If you sign in with Google or Apple, we receive your email and name from them (with Apple's Hide My Email, the relay address Apple gives us) and keep the identifier they assign to you, so your next sign-in reaches the same account. We never receive your Google or Apple password, and an account created this way has no password here.
- Your teams, memberships, and roles.
- Billing metadata: a payment-provider customer id and subscription status. We never see or store your card details — the payment provider handles them, not us.
- A record of the billing messages the payment provider sent us — a reference for each one, what kind of message it was, and when it arrived — so that a message delivered twice cannot be charged or applied twice. It keeps none of the customer details such a message arrives with: not your name, not your billing address, not the country your card was issued in. These records are deleted after 180 days.
- Server-link records (a hashed token + a "last seen" timestamp) for servers you link.
What we do NOT store
We do not store your terminal output, session content, code, keystrokes, or anything the Agent Remote software runs on your machine. That data never reaches this service.
This stays true of the crash reports, update checks, support cases and administrator-settings reports described below: what those carry is diagnostic and version information, plus — where each section says so — a scrambled fingerprint of the network address. Never the contents of your work.
Who else processes your data
Paddle.com Market Ltd sells and bills new subscriptions as the merchant of record, and handles invoicing, VAT and chargebacks. It receives the payment and billing details you enter at checkout, plus your email; we never see or store your card details. Some earlier subscriptions are still billed by Stripe, Inc.on the same basis. See each provider's privacy policy for how they handle that data.
If you turn on push notifications, your computer sends this service a small signal so the notification can be delivered to your phone, and we pass it to Google Firebase Cloud Messaging. That signal is limited, by design, to four things: a session identifier, the kind of event ("needs input" or "exited"), a label you chose for the computer, and your device's push token. The notification text is written here from the event type — your computer cannot supply it.
Terminal output, session content and command text are never part of that signal and never reach this service. The server rejects any other field rather than forwarding it, so this stays true even if a future version of the software tries to send more. Push notifications are off unless you enable them.
Crash reports
If the desktop app crashes, it sends us a report on its next start. This happens automatically and you can turn it off in Config → Crash reports — the app tells you this the first time you run it, rather than leaving you to find it here.
A report contains the error, the app version, your operating system and processor architecture, whether the local service was running, and a short diagnostic line. Credentials are removed from that text on your machine before it is sent, and if that removal cannot be completed the report is discarded rather than sent.
A report is not linked to your account, your team or your email, and you are never asked who you are to send one. It is not completely untraceable, though, and we would rather say so than let you assume otherwise: we keep a scrambled fingerprint of the network address it arrived from, so that one machine cannot flood us with reports. Never the address itself.
Treat that fingerprint as a pseudonym rather than as anonymity. We cannot turn one back into an address. Each section on this page keeps its own separate kind, so one address produces a different fingerprint for a crash report than it does for a support case — the records described here cannot be matched up to one another. Within any one of them the same address does repeat, which is what makes the flood limit possible.
Crash reports are deleted after 90 days. Your code, terminal output, screen contents, files and session content are never part of a crash report.
Update checks
The desktop app checks once at startup whether a newer version exists. That request reaches a server we run and tells it the version, platform and processor architecture it is asking about — which is itself a signal that a copy of the app started, even though nothing else is sent. It carries no account, no identifier for your computer, and nothing about what you were doing. Update checks are never restricted by whether you have paid.
Usage counts
We keep a small set of daily counts to see whether the product is being used: how many linked computers checked in, how many are new, how many exist in total, how many update checks arrived, and how many phones we sent a notification to. Nothing is collected from your machine to produce these — every one is counted from a request the software was already making for another reason.
We also keep a daily tally of which app versions and platformsasked for updates — for example "12 checks from version 0.3.0 on macOS/arm64". It is how we know whether an old release is still in use and worth supporting. Like the rest, it is a total per day with no installation, device or account attached.
The unit is a day, not a person. A row records a date and a number. There is no row describing an installation, a device or an account, and these counts cannot be traced back to you, your team or your computer.
One count is by country. Your address is used to work out the country at the moment of the request and is never written down for these counts; what is stored is a country and a total for that day, never alongside anything identifying. Where the country cannot be determined it is counted as unknown rather than guessed.
That sentence is about these counts and nothing else. The crash reports, support cases and administrator-settings reports described below each keep a scrambled fingerprint of the address they arrived from, and each section says so. Nowhere do we write down the address itself.
Notification counts work the same way: the number of phones reached that day is kept, and the device tokens used to reach them are not — not stored, and not kept in any form from which a device could be recognised again.
These counts are separate from the crash reports above. A crash report is content sent from your machine when something goes wrong; these are totals derived from requests that were happening anyway. They have no opt-out because there is nothing about you in them to opt out of.
Support cases and feedback
If you send a support case or feedback from the app, that message leaves your machine — it is the one thing here that you type and send deliberately. Nothing is sent unless you write it and press send; there is no automatic version of this, and so nothing to switch off.
Feedback travels the same way and carries less: your message and the email address you filled in, if you did. No diagnostics are offered or attached — it is an opinion, not a fault report, so there is nothing to diagnose.
A case carries your message, the app version and platform, and — if you choose to attach them — the same diagnostics a crash report would carry, through the same redaction. It never carries your terminal output, session content, code or files.
This is not anonymous, and only as far as you make it. A case is identified by a one-time code the app keeps so it can show you the status; we store only a hash of that code, never the code itself. An email address is optional and typed by you, per case — without one the case is still filed and you can still check it, there is simply nowhere for us to reply. Signing in is never required to send one. As with a crash report, we keep a scrambled fingerprint of the network address the case arrived from — never the address itself.
Cases are deleted after 30 days without activity — sooner than crash reports, because a case can carry an email address you typed, which a crash report never does. (Both keep the scrambled network fingerprint described above; that is a different thing.)
Settings applied by an administrator
This section applies only if someone administers this software for you — a workplace, or a team you belong to. If you installed it yourself you are your own administrator, there are no applied settings to check, and nothing in this section ever happens on your computer.
Where an administrator has applied settings, your computer checks they are genuinely theirs before using them. If it cannot read them, or cannot confirm they are the ones your administrator applied, it stops rather than run with settings nobody chose — and it tells us, so your administrator can be told. The settings that work this way are the ones that decide what a device may reach and what is recorded; the rest stay yours whoever administers the software.
If those settings have simply expired rather than been altered, none of that happens: your computer goes back to using its own settings, carries on, and sends nothing.
That report is sent automatically and you cannot turn it off.It is the only thing on this page with no switch, so we would rather say it here than leave you to find out. It works that way deliberately: turning it off is exactly what someone bypassing their administrator's settings would do, so the report is not a by-product of the check — it is the check. The app tells you on screen that it was sent.
The report says which of the two failures it was, and carries a reference for the settings being checked so your administrator can match it to what they applied. It identifies the computer and the team it belongs to, and carries the app version, your operating system and processor architecture. We also keep a scrambled fingerprint of the network address it arrived from — never the address itself — only to stop one computer flooding us with reports.
It is not anonymous. Along with a support case, it is one of the two things here that names you — and unlike a support case, you did not choose to send it. It carries no terminal output, session content, code or files.
If your computer cannot reach us it keeps the report and sends it the next time it can. Disconnecting delays it; it does not prevent it.
These reports are deleted after 30 days — sooner than crash reports, for the same reason support cases are: this one names a team and a machine.
Data requests & deletion
You can delete your account (and the teams you solely own) from account settings, which removes the associated records. For an export or other request, contact us.
One thing is not removed by that, and we would rather say so than let you assume otherwise: the record of billing messages described above is attached to no account, so there is nothing for an account deletion to reach. It carries none of your details, and it is deleted on its own 180-day schedule.
Cookies
We use a session cookie to keep you signed in, and one that remembers which team you are currently viewing. No third-party advertising or tracking cookies.
Contact
There is no published privacy contact yet. Everything this page describes is enforced in the software rather than by request — what leaves your machine is listed above, and turning it off is a setting, not an email.