What we store

This page is about the account server — the one you sign up and sign in to — and what it actually writes to disk.

Stored

• Your email address and when you signed up.
• The devices you signed in from: the device name you reported, the platform (android / ios / windows / macos / linux / web), and when each was first and last used.
• A hash of each sign-in token, never the token itself — leaking this data does not let anyone into your account.
• The end-to-end public key each signed-in device registers (for remote control — your other devices use it to recognise that one). The matching private key is generated on that device and is never sent to us.

Not stored

• Passwords — there are none.
• Sign-in codes themselves are not stored: only a hash of each, kept in the database, which expires after 10 minutes and is then deleted.
• Your code, your conversations with the model, your API keys, your sessions. This server has no endpoint that accepts them.

One-tap reports (only when you tap)

The app's settings have a "Send to the developer" button. Before anything leaves your phone it tells you how big it is and what is inside; you tap once more to actually send it.

• What arrives is exactly the diagnostics file you can export yourself, byte for byte: version, device, timings, exit codes, error text. No command lines, no command output, no file contents, no conversation text, no API keys.
• Not linked to any account: no sign-in needed, and we don't attach your email. You get a reference code; we can only find the report if you tell us that code.
• Kept for 30 days, then deleted automatically.

Also worth saying

• Rate limiting counts requests per source IP. On this server that counter is written to the database (each row holds only the source and a timestamp) and deleted as the window passes, so at most one hour.
• Sign-in codes and new-device alerts are sent through Resend, an email delivery service. It sees your email address and the full message — including the code; an email cannot be sent any other way. What we hand it is the recipient, the subject and the body, and nothing else.
• This server is rented in Oracle Cloud's Tokyo data center. As with any cloud server, that company controls the machine's hardware. The layer that handles https (Caddy) runs on the same machine and keeps no access log; when it or our services hit an error they write a line to this machine's system log (Caddy's line may include the source IP), and that log is kept for 14 days. Our own services log one line per request — method, path, status and duration — with no IP and no email address.
• Account data (email addresses, sign-in records, device public keys) is backed up once a day, encrypted, to Cloudflare R2, an object storage service. It holds only ciphertext: the key that decrypts it is not on this server, and Cloudflare doesn't have it either. Backups are kept for at most 15 days — so after you delete your account, your email address can remain in an encrypted backup for up to that long. Reports, sign-in codes and rate-limit counters are not backed up.
• Remote control — letting one of your devices drive a session running on another: the desktop app can be the one being controlled and the phone app the one in control. It goes through our relay: what passes between your two devices is end-to-end encrypted, so the relay can't read it and doesn't store it. What the relay does see is metadata — which of your devices are online, how many LeanCarve programs each one has open (one for the desktop app, one per terminal running leancarve), and when, which one connected to which, and how big each frame is.
• Session handoff — passing a session, together with its workspace, to another of your computers so it carries on there — goes the same way: the workspace files and the conversation are end-to-end encrypted just like the above, so the relay can't read them and doesn't store them. It still sees only that metadata, which means it can tell roughly how many bytes one handoff moved, but not what they were. The API keys you keep in your keychain are not part of what gets sent.
• Which devices count as yours (the roster) is decided by the account server. So the encryption protects you from the relay and from anyone on the network, but not from a compromised account server: it could slip a device into your roster. Anyone who can read the codes in your inbox can do the same — which is why we email you every time a new device signs in.