Privacy Policy

Everything below describes what the code actually does. Where a mechanism is designed but not yet live, it is marked.

1. Who we are

We are the data controller for the information described here.

Registered name	Exceedity Ltd
Company number	14683104
Registered in	England and Wales
Registered office	Willoughby House, 2 Broad Street, Stamford, United Kingdom, PE9 1PB
VAT number	GB437416589
ICO registration	applied for on 17 August 2026 — number to follow
Contact for anything in this notice	inbox@exceedity.com

Write to inbox@exceedity.com about any part of this notice, or to exercise any of the rights in section 16. A real person reads it.

2. The short version

We cannot read your sessions. Not "we promise not to" — the words are encrypted between your phone and your own computer, and our server forwards sealed bytes it has no key for.
There is no account and no password. Nothing to phish, no password database to leak.
We hold almost nothing. An install identifier, a hash of your install's token, a label saying whose it is, when it was created, and roughly when it last connected.
Stripe holds your billing details. We never see your full card number.
There is no analytics on our website or in the app. No trackers, no telemetry, no third-party scripts.
You need your own Anthropic subscription. atdesk does not include, resell or proxy Claude, and never sends your prompts to Anthropic — your own copy of Claude Code does that, under your agreement with Anthropic.

3. What we cannot see, and the mechanism that makes it true

A privacy promise you cannot check is worth nothing, so here is how it works.

Your phone and your computer agree a key with each other, not with us. When you run vsr pair, your computer shows a QR code on its own screen containing a one-time secret. That secret is never sent through our server — it goes from a screen to a camera in the same room. The phone proves it knows the secret, and you then compare a fingerprint shown on both screens and approve the pairing at the computer by hand.

Every message is sealed before it reaches us. Phone-to-computer and computer-to-phone use different encryption keys, derived from the key exchange and bound to that session. Each message is encrypted with AES-GCM and carries an authentication tag.

Our relay forwards without decoding. The relay's job is to carry sealed payloads between your phone and your computer. The payload is treated as opaque bytes: it is not decoded there, and the code says in terms that it must never learn how. The relay holds no key that either end trusts, so it also cannot forge a message or enrol a device.

If we tampered, you would find out. Messages are numbered, and the numbering is covered by the authentication tag. If our relay removed or reordered a message, the receiving end sees a gap and drops the connection rather than carrying on. A relay that started censoring would break visibly.

The limits of that claim — stated, not hidden

We would rather understate this than be caught overstating it.

We can see traffic patterns. Our relay knows that a particular install connected, when, for how long, how many messages passed and how big they were. It cannot see what they said. Denial of service and traffic analysis are inherent to relaying anything and we do not claim otherwise.
We serve the app that holds your key. The phone app is JavaScript served from atdesk.dev. Your device's private key lives on your phone and is generated as non-extractable — no script can read it out, including ours — but a compromise of that origin is the real residual risk, which is why the site carries no third-party scripts at all, why pairing needs a human keypress at your computer, and why the origin is deliberately kept tiny.
Install identifiers are addresses, not secrets. Knowing one lets somebody open a channel to your computer; it does not let them complete a handshake, because that needs a key you approved at your machine.
Notifications reveal timing to your phone's push service. See section 8.

4. What our relay actually stores

Our relay runs on a server we own and administer. This is the complete list of what it keeps on disk, per install:

What	Contents	Notes
Install record	The install id; a SHA-256 hash of that install's relay token; an `owner` label; who minted it; the date it was created; the date it first connected	The token itself exists once, at the moment it is created, and is never written down or logged by us. A stolen copy of this store tells an attacker who exists and when they connected — not how to connect, read or forge
Revocation marker	An empty file named after the install id	Created if an install is revoked; never updated
Last-seen	A single timestamp, overwritten	Written at most once every 15 minutes, so it is a "last seen at" and not a connection history
Invite records	A SHA-256 hash of the invite code, the date created, the date it expires, and the `owner` label	The code itself is never stored. When used, the file is renamed and kept as a receipt
Audit log	One line per event, each with a timestamp: install created, install activated, install revoked, invite minted, invite used, invite refused, an admin request refused	Append-only

What the relay never writes to disk: the contents of your session, in any form. Messages in flight are held in memory only, and only while your computer is briefly away — capped at 64 messages per channel — and are discarded as soon as they are delivered. Channel identifiers are random, per-connection, and are routing labels only.

Application log. The relay writes a line, with a timestamp, when a computer's stream comes up or goes down, when a device connects or disconnects, and when a credential is refused. These lines contain the install id and a truncated channel id. They do not contain IP addresses and never contain message content.

Web server log. Our relay sits behind nginx, which is the only way in. nginx passes the connecting IP address to the relay as a header and, by default, writes a standard access log line for each request — the IP address, the time, the request path, the response status and the browser's user agent. So yes: IP addresses are processed at our ingress. We use this only to keep the service running and to deal with abuse.

5. Billing information

Checkout and the customer portal are hosted by Stripe. Your card details are entered on Stripe's pages, not ours. We never receive, see or store your full card number or security code.

Through Stripe we can see, and use for running the business:

your name and email address, as given to Stripe;
your billing address and country (needed so Stripe Tax can work out the VAT included in the price);
the card's brand, expiry date and last four digits;
your subscription status, renewal date and payment history, including failed payments;
your invoices and receipts.

We keep the record of the sale for as long as UK tax law requires, which is currently six years from the end of the accounting period.

6. Email

We will send you transactional email — your invite code, receipts, a warning before a renewal, and notices if the service is affected. We send these ourselves, from our own server. No third-party email provider receives your address in order to deliver them. Your address is written to a queue on that server, and the file is deleted once the message is accepted for delivery — normally within seconds.

Your email address is read from Stripe when we send, never from a cached copy, so changing it in the Stripe portal changes where our email goes.

We do not send marketing email. If we ever do, we will ask for your consent first and every message will carry a one-click unsubscribe. Withdrawing consent will never affect your subscription.

7. What stays on your own machines

Most of atdesk's data never reaches us at all. Listing it here because you should know what is on your own disk.

On your computer, in ~/.config/vscode-remote (permissions 600 — readable only by you):

your computer's identity key, which your phones pin at pairing;
the list of phones you have paired, by public key and fingerprint;
the local access token used between atdesk's own two background services;
the loopback TLS certificates those two services use to talk to each other;
the notification keys and, for each paired phone, its push subscription (see section 8);
a short-lived pairing file while a pairing window is open, deleted when it closes or expires.

atdesk reads the session transcripts Claude Code already writes on your computer, in ~/.claude/projects. It does not copy them anywhere. Its background service listens on loopback (127.0.0.1) only and is not reachable from any network.

Its logs are written to ~/Library/Logs on macOS and %LOCALAPPDATA%\vscode-remote\logs on Windows. They stay on your machine; nothing sends them to us.

On your phone, see section 15.

8. Notifications

If you turn notifications on, your computer — not our server — sends the notification directly to the push service your phone's browser nominated: Apple, Google, Mozilla or Microsoft. The subscription address is stored in the config file on your computer and is never sent to us.

The text of the notification is encrypted (RFC 8291) with a key your phone's browser generated and never released, so the push service relays words it cannot read. Your computer will only send to a short allowlist of genuine push service hostnames, and will not follow redirects away from them.

The unavoidable part: the push service learns the timing. Apple can see that your computer pinged your device at 02:14, even though it cannot see what about. That is the price of a phone buzzing in a pocket, and it cannot be engineered away.

Push services are not our processors — your browser chooses them, and they operate under their own terms and privacy notices.

9. Claude, and Anthropic

atdesk does not include, resell or proxy Claude. You need your own Anthropic subscription and your own installation of Claude Code. atdesk never contacts Anthropic — there is no call to Anthropic's API anywhere in the product. Your prompts go from your own computer to Anthropic under your agreement with Anthropic, exactly as they did before you installed atdesk. What atdesk adds is a view of that session on your phone, and a way to type into it.

atdesk is not affiliated with, endorsed by, or sponsored by Anthropic.

10. Why we are allowed to hold this (lawful bases)

What we do	Data used	Lawful basis (UK GDPR Art. 6)
Give you an install slot and let your computer connect	Install record, revocation marker, last-seen timestamp	Contract — we cannot deliver the service without it
Take payment and manage your subscription	Billing data held by Stripe	Contract
Send transactional email (invite code, receipts, service notices)	Email address	Contract
Keep VAT and accounting records	Invoice and sale records	Legal obligation
Keep the service running, and detect and stop abuse	Access logs including IP address; audit log of credential events	Legitimate interests — running a secure service. We keep the data thin and never inspect message content
Answer your support request	Whatever you choose to tell us	Legitimate interests, or Contract where it concerns your subscription
Marketing email, if we ever send any	Email address	Consent, freely given and withdrawable
Defend or bring a legal claim	The above, as relevant	Legitimate interests

We do not ask for or want special category data, and we have no way of reading your session content, which is the only place any could plausibly appear.

11. Who else handles it

Who	What for	Role
Stripe	Checkout, subscriptions, the customer portal, invoices, VAT calculation	Processor (and independent controller for its own fraud and compliance purposes)
No email provider	Transactional email is sent by our own server, not a third party. Your address is written to a queue on that server and deleted once the message is accepted for delivery. Nobody else is involved in sending it	—
**Gandi SAS**	The physical/virtual server our relay runs on, in France	Sub-processor (infrastructure only)
Cloudflare	Serving the atdesk web app and the website	Processor. It sees the IP address of anyone loading the site

The relay is ours. It runs on a server Exceedity rents and administers, in a container with no route to any of our other services, with one writable directory holding only what section 4 lists. It is not a third-party service and no third party operates it — beyond the hosting provider that supplies the machine.

We do not sell your data, share it for advertising, or hand it to anyone else except where the law requires it.

12. Sending data outside the UK

Our relay is hosted in France, on a server supplied by Gandi SAS (63–65 Boulevard Masséna, 75013 Paris, France). So the data described in section 4 — install identifiers, token hashes, the audit log, and the IP addresses in our web server log — is stored in the EEA rather than the UK.

Some of our processors are outside the UK too: Stripe and Cloudflare are US-headquartered and operate globally. Email is not among them — we send it from our own server, so no third party receives your address in order to deliver it.

Where personal data is transferred outside the UK, we rely on the UK's adequacy regulations where they apply — which currently cover the EEA, and so cover our own server — and otherwise on the International Data Transfer Agreement or the UK Addendum to the EU Standard Contractual Clauses, together with the processor's own safeguards.

13. How long we keep things

We would rather tell you the truth about this than quote a tidy number we do not enforce.

What	How long
Install record, last-seen timestamp	90 days after your subscription ends, then deleted automatically, along with the link between your subscription and your install
Install records that were minted but never used	7 days, then deleted automatically
Revocation marker	Kept. It is an empty file naming an install that was shut off, and deleting it could let a revoked install be silently re-created. Security records do not expire
Queued email (your address, while an activation code is waiting to be sent)	Seconds, normally. The relay writes the message to a spool and the sending job deletes each file once it is accepted. A message that cannot be sent is retried five times and then kept in a `failed/` folder until a person looks at it — that is deliberate, because a parked message is a customer who paid and never got their code
Invite records	Kept. An unused invite expires after 14 days by default (1–90 days if we set it) and stops working, but the record — a hash, two dates and a label — is not deleted. A used invite is kept as a receipt
Audit log on the relay	12 months. Lines older than that are pruned automatically
Relay application log (container log)	Capped at 3 files of 50 MB. At this service's volume that is far more than 14 days of lines, and it is now bounded rather than growing forever
Web server access log (IP addresses)	14 days. Measured on the server 2026-08-17: `/etc/logrotate.d/nginx` rotates daily with `rotate 14` and compresses, and the oldest file present is `access.log.14.gz`
Billing records	Six years from the end of the accounting period, as UK tax law requires
Email we exchange with you	24 months, then deleted
Your session content	We never hold it, so there is nothing to retain

14. Cancelling, and leaving cleanly

Cancel any time through the Stripe customer portal. What happens next, stated honestly:

What we do. Your subscription stops at the end of the period you have paid for. After that your install is no longer entitled and your computer can no longer connect through our relay.

What is left on our side. Your install record, and the timestamp of when it last connected, remain on the relay unless you ask us to remove them. That is a hash, an identifier, a label and two or three dates — never any session content. Ask us at inbox@exceedity.com and we will delete the record; we will keep the billing record, because tax law requires it.

What is left on your computer, and what you must do. This is the part most companies do not print.

vsr uninstall does not delete anything in ~/.config/vscode-remote, and does not touch the separate transport daemon. What it does to the running service depends on your operating system, and the honest answer is different on each — verified against the code on 2026-08-17:

On macOS it unloads the job and removes it. The background service does stop. It does not tell you that it has, which is the only thing wrong with it.
On Windows it removes the logon task but does not stop the service that is already running — it keeps going until you reboot or run vsr stop. It says so on screen.

So, until a single "remove everything" command exists, leaving cleanly means:

vsr stop — stop the background service. On Windows this is necessary; on macOS vsr uninstall has already done it, and running this first is harmless;
vsr uninstall — remove the login item;
remove the transport daemon (vsr vsrd uninstall);
delete ~/.config/vscode-remote, which removes your identity key, your paired phones, your notification keys and the local token;
delete the atdesk app from your phone's home screen, which removes the device key held there;
email us to have your install record on the relay deleted;
if you enabled VS Code's local debugging port during setup, turn it back off.

15. Cookies, local storage, and the device key

We set no cookies for tracking. There is no analytics on the website or in the app. No Google Analytics, no pixels, no third-party scripts of any kind. The app's content security policy blocks every external request by design.

The app does store two things on your own phone:

Your device key, in the browser's IndexedDB, in a database called atdesk. It holds a private key that is generated as non-extractable — it can sign, and it can never be read out, not by our page and not by anything else that later runs on that origin — plus the public key, the identifier of the computer it is paired with, and the date it was created. This is what makes the encryption work. It is not a tracking cookie: it is never sent to us, it identifies your phone only to your computer, and it cannot be read by any other website.
A one-shot pairing note, in sessionStorage, used to carry a pairing link across a single page load and deleted the moment it is read.

Under the Privacy and Electronic Communications Regulations, both are strictly necessary to provide the service you asked for, so we do not show a consent banner. There is nothing to consent to, because there is nothing being tracked.

Add to Home Screen matters for a privacy reason too. iOS deletes a website's storage after 7 days without interaction, and your device key lives in that storage. Home-screen apps are exempt.

16. Your rights

Under UK GDPR you can ask us to:

tell you what we hold about you, and give you a copy (right of access);
correct anything that is wrong;
delete it (right to erasure), subject to records we must keep for tax;
restrict or object to our use of it where we rely on legitimate interests;
give you a portable copy of data you gave us, where we rely on contract or consent;
withdraw consent at any time, where consent is the basis.

How to ask: email inbox@exceedity.com. We will answer within one month. There is no charge unless a request is manifestly unfounded or excessive.

One honest complication. There is no account system — that is deliberate, and it is why there is no password to leak. It also means we usually cannot connect a request to an install without help from you. To act on a request about relay data, please tell us your install id and email us from the address on your Stripe subscription. If you cannot supply enough to identify the data, we may not be able to act on the request, and we will tell you so rather than guess.

17. How we protect it

Session content is encrypted end to end, with a separate key in each direction, and our relay cannot decrypt it.
Relay tokens are stored only as SHA-256 hashes; the token itself is shown once, at creation, and is never logged.
Invite codes are stored only as hashes.
The administrative interface that creates and revokes installs is unreachable from a browser and gated on a secret we hold only as a hash, with rate limits on failed attempts.
The relay runs in a read-only container, on its own network with no route to any of our other systems, with a single writable directory.
Your local configuration file is written with permissions 600, and the local service listens on loopback only.
Nobody at Exceedity has a way to read a customer's session. There is no support tool that could, and building one would require breaking the design.

No system is perfect. If we ever suffer a breach that is likely to risk your rights and freedoms, we will report it to the ICO within 72 hours and tell you without undue delay.

18. Children

atdesk is a developer tool sold to adults. It is not directed at children and we do not knowingly collect data about anyone under 18. If you believe we have, email inbox@exceedity.com and we will delete it.

19. Automated decision-making

We do not make any decision about you by automated means that produces a legal or similarly significant effect. The only automated decisions in the product are technical: whether an install is entitled to connect, and whether a credential is valid.

20. Changes to this notice

If we change it, we will change the date at the top. If a change materially affects your rights — a new processor, a new category of data, a new purpose — we will email you before it takes effect.

21. Complaining

Please tell us first: inbox@exceedity.com. We would rather fix it.

You also have the right to complain to the Information Commissioner's Office, the UK's data protection regulator, at any time:

Website: ico.org.uk/make-a-complaint
Helpline: 0303 123 1113
Post: Information Commissioner's Office, Wycliffe House, Water Lane, Wilmslow, Cheshire, SK9 5AF

(Please check the ICO's current contact details on its website before writing.)

This notice, and any dispute arising from it, is governed by the law of England and Wales.