Agent Remote is operated by HDT Software Services. Payments are processed by Paddle, our merchant of record.
What 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.
- If you turn on two-step sign-in, the key your authenticator app shares with us (stored encrypted) and your backup codes (stored only as hashes). Turning it off deletes both.
- For each passkey you add: its public key (never the private key, which stays on your device or in your password manager), the name you give it, when you added it and when it was last used. The one-time challenges used to add a passkey or sign in with one are stored only as hashes, deleted when used, and cleared away once they expire. Removing a passkey deletes all of this.
- A scrambled identifier for each browser you sign in from (the latest 20), so we can email you when your account is signed in from a browser we have not seen before. It comes from a random value in a cookie on that browser and is scrambled differently for each account, so it cannot be matched across accounts. We read the browser's name to say which kind of browser it was in that email, but we do not keep it, and we do not store the network address or the location.
- Your workspaces, 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.
- If you subscribe in the App Store, what Apple tells us about that subscription: its original transaction id, the product (which plan and billing period), the environment (a real purchase or an Apple test purchase), and its status and dates — when it was bought, when it renews or expires, and when it was cancelled or refunded — plus a random identifier for your workspace that the app hands to Apple with the purchase, so the plan reaches the right workspace. We use these only to give your workspace its plan. We receive no payment card data from Apple: Apple takes the payment.
- 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.
- For each linked computer, the name, operating system and version, and processor type it reports when it checks your plan — used only to show your computers in your workspace's list, so you can tell them apart.
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. The one way that data passes through this service is our relay, when your phone reaches your computer through your account, and it passes encrypted so that we cannot read it — see Connections through our relay below, including the exceptions.
This stays true of the crash reports, update checks, daily usage counts, 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.
Connections through our relay
Remote sessions are encrypted between your paired devices and your computer, so our relay cannot read them. The relay still sees when you connect and how much data moves. Web previews are not end-to-end encrypted, and notifications go through a separate service that sees the session, the event type and your computer's name, never what is in the session. On your own network, the relay is not involved.
To route an encrypted connection, the relay processes the following, and never what is inside it:
- your computer's relay hostname and the account link it belongs to
- your phone's IP address
- that an encrypted connection exists, and when it opens and closes
- how many messages pass, their timing, and their size, rounded up by padding so exact keystroke and command lengths stay hidden
- whether your computer is online
Our administrators can see which linked computers are connected to the relay right now, when each one connected, and how many connections are open through it, never what passes through them.
A web preview of your dev server opened on your phone is the exception: the relay sees those pages, and the preview's access token and cookie, in the clear while they pass. So does a relay connection to a computer you set to allow unencrypted connections (relayPlaintext set to allow); computers refuse them by default. The push notification signal is a separate channel, described below.
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. Their privacy policy covers what happens to that data once it reaches them.
Apple sells and bills subscriptions bought in the App Store, and handles their payment, renewal and refunds. It receives your payment details through your Apple ID; we never see them. Apple's privacy policy covers what happens to 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 six things: a session identifier, the kind of event ("needs input", "done", "exited" or "error"), the shape of the question (a yes/no or a numbered menu, so the notification can offer the right buttons — never its text), a label you chose for the computer, that computer's random identifier (so your phone answers the right one when you have several), 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.
If the phone app crashes below its own code, a crash report goes to Google Firebase Crashlytics — see Crash reports (mobile) below for what it contains and how to turn it off. Failures the phone app catches itself come to us instead, as described under Crash reports.
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.
The phone app reports its own failures to us the same way. When a screen cannot render or the app hits an uncaught error, it sends us a report containing the app version, your operating system and processor architecture, the kind of failure, and one diagnostic line built from the error. Credentials, your computer's name and address, email addresses and key-like strings are removed on the phone first, and a report that cannot be cleaned is discarded rather than sent. The same error is reported at most once each time the app starts; a report that cannot be sent yet is kept on the phone (five at most) and tried again on a later start. Everything below applies to it exactly as it does to a desktop report. You can turn these off in the phone app under Settings → Send crash reports — the same switch that covers the native crash reports described under Crash reports (mobile).
No released version of the phone app sends crash reports yet. Both kinds start with the phone-app release that ships them, together with that switch; until then the phone sends no crash report of any kind.
A report is not linked to your account, your workspace 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.
Crash reports (mobile)
If the phone app itself crashes at the native level, a crash report is sent to Google Firebase Crashlytics, a crash-diagnosis service run by Google, so we can find and fix the fault. This is the one kind of crash report that goes to a third party rather than to a server we run. It happens automatically and you can turn it off in the phone app under Settings → Send crash reports; the change takes effect the next time the app starts, and from then on nothing more is sent.
A report contains the stack trace of the crash, the app version and build, your device model and operating-system version, basic device state at the moment of the crash (such as free memory and screen orientation), and a random Crashlytics installation identifier that Firebase generates for the app on your phone. We do not attach your account, your email, your workspace, your computer's name or any identifier of our own to it. That installation identifier repeats across reports from the same phone, so treat it as a pseudonym rather than as anonymity.
Google keeps these reports, and the identifiers attached to them, for 90 days, under Firebase's privacy terms. 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. The server package checks only when you ask it to — when you run its update or status command — and never by itself. Either way, 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 software is in use, 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, platforms and processor types asked for updates — for example "12 checks from version 0.3.0 on one platform and processor type". 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 workspace 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. The daily counts your computer sends, described next, are a different thing, and you can turn them off.
Daily usage counts from your computer
If your computer is linked to your account, it sends us one small report a day saying how often a few features were used the day before. This is so we can see which features people rely on and whether notifications and reconnecting are fast enough. A computer that is not linked to an account sends nothing.
It contains counts only, never content. A report carries the date, the app version, and these numbers for that day:
- how many times a web preview was opened,
- how many times feedback was sent,
- how many times a terminal was opened,
- how many times a request was answered from a notification (whatever the answer),
- how many times the connection through our relay had to reconnect,
- how long it took to answer after a notification, and how long reconnecting took — each only as a count per rough time range (for example "3 answered within 30 seconds"), never as individual times.
Never your terminal output, session content, commands, code, file names or folder names, your computer's name or address, or a record of each individual action. We drop anything else a report contains rather than store it.
We add the reports up and keep one total per workspace per day for each app version. The totals are linked to your workspace (if you are the only member, that means you), but not to which of your computers sent them. They are deleted after 395 days (13 months). To make sure a report that arrives twice is counted once, we keep a scrambled reference for each computer and day — never the computer itself — and delete it after 7 days.
The report carries your computer's link to your workspace, which is how we know whose totals to add it to. It arrives from your IP address, like any request; the address is not stored with the counts.
This is on by default. You can turn it off at any time:
- in the desktop app, open Config → Usage counts and turn off Send daily usage counts;
- for the server package (used without the desktop app), set
usageReporttofalsein its config, or set the environment variableAGENT_REMOTE_USAGE_REPORT=0.
Turning it off stops future reports: nothing more is counted for this report and nothing is sent. Versions of the computer software from before this report existed send no such report.
We do this on the basis of our legitimate interest in understanding which features are used and how well connections work. You have the right to object. The switch above is the quickest way, and you can also write to [email protected].
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.)
You can also write to us from the Support page on this website. That message is kept the same way, with two differences: an email address is required, because the website has no other way to reply, and nothing from your computer — no app version, platform or diagnostics — is attached. A web support message stores your message, the reply email you give, and a salted address fingerprint (a scrambled fingerprint of the network address it was sent from — never the address itself). If you are signed in, it is also linked to your account. Messages that look automated, and too many from one address, are refused and not stored; the note we keep of a refusal holds only that salted fingerprint and is deleted after 180 days. A message we did store follows the same 30-day deletion.
You can also email the support address, [email protected]. That email becomes a support conversation kept the same way: we store its text — never its formatting or pictures, and not its attachments, only each attachment's name and size — the address it came from, and our replies, so the conversation stays in one place. Emails that fail the check proving who sent them, and too many from one address, are refused and not stored; the note we keep of a refusal holds only a salted fingerprint of the address and is deleted after 180 days. A conversation is deleted 30 days after its last message.
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 workspace 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 workspace and a machine.
Data requests & deletion
You can delete your account (and the workspaces 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.
Analytics
To see which pages of this website are read and how fast they load, we use Cloudflare Web Analytics. When a page loads, a small script reports the page address (without anything after a "?"), the page you came from, your browser type and country, and loading-speed measurements. We see only totals, such as page views per day.
It sets no cookies and saves nothing in your browser, does not identify you or follow you across other sites, and is not used for advertising. Cloudflare's privacy policy covers the data it handles. It runs on this website only, never in the apps.
Cookies
We use the cookies sign-in needs to keep you signed in, and one that remembers which workspace you are currently viewing. No third-party advertising or tracking cookies.
When you sign in, we also set a browser identifier cookie: a random value that names this browser and nothing else, kept for up to two years so we can tell a browser you have used before from a new one and email you about a sign-in from a new browser. Scripts on the page cannot read it, and it is sent only to this site.
Two small choices are also saved in your browser's own storage, not in a cookie: your light or dark appearance, and that you closed the cookie notice. They stay on your device, are never sent to us, and are gone when you clear this site's data. None of our own cookies or saved choices is optional or used to follow you, so there is nothing to opt in to.
On the Billing page we load the checkout of Paddle, our payment provider. Paddle may set its own cookies there to take the payment and prevent fraud; those are covered by Paddle's privacy policy, not this one.
Contact
Questions about this policy go to [email protected]. 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.