Your code never leaves your Mac.

Atelier is local-first and private by design. Here's exactly what it does — and doesn't do — with your data, in plain terms. No lawyer-speak.

What Atelier never sends

Atelier never sends us your prompts, your code, your agent transcripts, the commands you run, your file paths, or your repo and branch names — not to us, not to anyone, on any setting, and there is no toggle that turns it on. Some of it the app does keep on your Mac, because work that vanishes on relaunch is not work: what each agent is doing, the requests you made of it, a bounded tail of the conversation, and — if you switch the beta on — the lessons a Work Area has distilled. Those sit on your disk under your own account, we never receive them, and closing the pane or deleting the Work Area deletes them. The same is true of your IP address: nothing Atelier sends us is stored with one.

Local-first

Everything runs on your machine. Your workspaces, files, terminals, and agent sessions live on your disk and nowhere else. Your license is verified offline — the cryptographic signature is checked on your Mac, so the app works with no network at all.

What we collect, split in two

There are exactly two kinds of data Atelier can send about itself, and they are governed separately — because one of them is a choice you should be asked to make, and the other is what keeps the app working at all.

1. Product usage — only if you say yes

On first launch Atelier asks, once, with two plain buttons and nothing pre-ticked. If you choose “Help improve Atelier”, it sends anonymous counts of what gets used: event names, how many panels or agents you opened, which features you touched, which app version you're on, timestamps. If you choose “No thanks” — or close the window without answering — none of it is sent, and nothing is queued up waiting for you to change your mind.

This is off unless you agreed. Never a default, never assumed from silence. Change your answer any time in Settings ▸ Advanced, under Privacy & data. Your identity for this is a random id that rotates every 90 days, and turning it off deletes it.

2. Product health — on by default, and you can turn it off

Two signals are sent whether or not you opted into usage analytics, because without them a crash-on-launch or a broken installer is invisible to us until someone writes in:

• A crash marker. When a launch follows an unclean exit, Atelier sends the fact that a crash happened — one event, no parameters. The crash details, the reason and the stack stay on your Mac, for the app's own Stability Dashboard. We never receive them.
• One trial counter. The first time a trial starts, Atelier sends a random install id, the app version, and the OS version — once per install, ever. We keep those three, plus a coarse country (a two-letter code like DE, worked out from the request as it arrives and never from a stored address) and the date. Five fields, and that is the whole record: no email, no name, no device id, no license id, and nothing that could be joined to a purchase. We keep the two version numbers so that when a release breaks something we can see which build people were on — they describe the software, not you. When a trial is new, we also send Google Analytics the fact that one started, with the country and those two version numbers — never the install id, so it cannot be tied back to this record or to anything else.

Both are on by default, and both are switched off together by Settings ▸ Advanced ▸ “Send anonymous product-health data”. Off means neither is sent. We say “on by default” plainly rather than calling it consent, because it isn't: it's a legitimate interest in knowing the product works, and your right to refuse it is a real switch in the app, not an email you have to send.

One consequence, stated because it cuts against us: since the health signals are refusable, our own trial counts are near-complete rather than exact. We'd rather have a number with an honest asterisk than one nobody could decline.

The mobile companion (opt-in)

When you choose to connect the mobile app, that's the one time your work leaves your Mac — because seeing and replying to your agents from your phone is the whole point. Here's the honest breakdown:

• What crosses the relay: agent status, your agent conversation, and bounded terminal snapshots — so you can read them on your phone — plus the replies you send back and any photo or file you attach to one.
• Encrypted in transit (TLS). The relay also holds a rolling buffer of the last 500 events for your room, so your phone can catch up on what it missed while it was offline or asleep. Events leave that buffer when newer ones push them out — it ages out by volume, not on a clock, so on a quiet room an event can sit there a while. It holds event titles and bodies and, only if you switch message previews on, the short redacted preview your Mac chose to attach. We do not read it; it is there to deliver what you already missed.
• What the relay can see: connection metadata (which device, when) needed to route messages and stop abuse, plus whatever is sitting in that rolling buffer.
• On the roadmap: end-to-end encryption, so not even we could read what passes through — and the option to self-host the relay so your data never touches our infrastructure at all.

Two things the phone app does on its own, which the sections above are about the desktop and do not cover:

• Push notifications. To wake your phone when an agent needs you, the app registers a device push token with Apple or Google and gives it to the relay. The relay needs it to reach that one device; it is not tied to a name or an email. Alert text carries a preview only if you switched previews on.
• Its own usage analytics, on by default. Unlike the desktop, the phone app starts with anonymous usage counts on, and you can switch them off in the app. Its identity is a random id stored on the device that rotates every 90 days. One honest difference from the website above: the phone talks to Google Analytics directly, so unlike this site — where the counting runs on our server and Google never meets your browser — Google does see your device's IP address on those requests.

If you never connect the mobile app, none of this applies — the desktop app stays fully local.

This website

Everything above is about the app. The site you are reading is measured too, and it works differently — so it gets its own paragraph rather than being folded into one about “our services”.

We do measure how this site gets used — which pages were opened, which buttons were clicked, how far down the page people read. We use Google Analytics for it, and we are saying so plainly rather than burying it.

What is unusual is how. There is no Google tag on this page, no analytics vendor script, nothing from an ad network: your browser talks only to us. It sends us a short list of things that happened, our own server counts them, and the counts go to Google. Google gets the numbers and never meets you — it never sees your browser, and never your IP address.

No cookies — not analytics cookies, not “essential” ones, none at all — and nothing written to or read from your browser, not even briefly. That is why you were not shown a cookie banner: consent is required for storing things on your device, and we store nothing. It is not an oversight, and it is not us deciding on your behalf that you would have said yes.

We never send your name, your email, or anything you typed. The address of the page you are on is sent, but rebuilt from a fixed list of allowed parts, so a link carrying anything personal cannot smuggle it through. Because nothing is stored in your browser, we cannot tell that two visits were the same person, and we do not try to: no cookie, no fingerprint from your address or your browser version, nothing. The numbers we work from are counts of events, not profiles of people.

Our own server also counts four things directly, without your browser being involved: that someone was forwarded to the checkout, that a trial started, that a license was activated, and that an order was paid. These are records of our own transactions. The purchase count carries a one-way fingerprint of the order — enough for us to avoid counting the same order twice, not enough for anyone to look it up.

Worth being straight about one consequence: because the counting runs on our own server rather than through a third-party script, a tracker blocker will not stop it. We are not doing that to get around your blocker. It is what removing the third party costs, and the trade it buys is real: no vendor script on the page, no cookie, and nothing about you leaving this site.

Buying a license

A purchase goes through our payment provider, who handles your payment details — we never see a card number. We keep the licensing record a licence needs: your email (so we can send you the key and help you when something goes wrong), the order, and a one-way hash of each Mac you activate on. Never the Mac's name or serial.

Questions about any of this? Email us — we'll answer plainly. This page will grow into the full policy before launch.