Privacy
The short version
- The website collects one thing: the e-mail address you type into the form, with a consent proof. Nothing is collected if you do not.
- There is no analytics, no tracking pixel, no advertising network, no cookie and no third-party script on the website, and no analytics, crash-reporting or advertising code in the apps.
-
The apps work through a server. Your Mac sends it what your Claude
Code sessions are doing — your prompt and Claude's last message, shortened, the
session's name, folder and account, each tool step — and your iPhone and Mac read
it back and send your answers. The default server,
pulse.synccy.com, runs on hardware in the Netherlands that the maker owns and operates. Use a server of your own and none of it reaches the maker. - It is not kept forever: tool steps for two days, usage for seven, and the latest 2,000 events. The full list.
- Two outside parties carry data: Google delivers the list's e-mails, and Apple delivers the notifications. Nothing is sold, rented or shared beyond that.
- Unsubscribing stops every e-mail at once — one click, no reason asked, here or from the link in any e-mail. Removing a device in Pulse's settings removes it from the server at once.
1. Who is responsible
The controller is Jarrel Pothoff, a private individual in the Netherlands, who builds Pulse alone.
Two ways reach the maker, and a person reads both:
- Reply to any e-mail you received from the list. Everyone on it has had one: before your address is on the list at all, a confirmation e-mail goes to it.
- Testing Pulse through TestFlight? Use Send Beta Feedback in TestFlight. More on the support page.
There is no company behind Pulse, so no Chamber of Commerce or VAT number is printed here. Pulse is not made by, affiliated with or endorsed by Anthropic.
The rules for using Pulse are in the terms of use.
2. What the website collects, and why
| Data | Why | Legal basis | Kept |
|---|---|---|---|
| E-mail address | To tell you when early access to Pulse opens, and the occasional update. | Consent — Art. 6(1)(a) GDPR | Until you ask for it to be erased (see 5) |
| Salted hash of your IP |
Proof that consent was given, without keeping the address. This site's server
hashes it before anything is sent onward (src/lib/ip-hash.ts);
the list itself never sees a plain IP.
| Legal obligation to demonstrate consent — Art. 7(1) GDPR | With the signup |
| User-agent string, timestamp, consent wording version | The rest of the same proof. | Art. 7(1) GDPR | With the signup |
| Which form you used (top or bottom of the page) | To know which of the two invitations works. It says nothing about you. | Consent — Art. 6(1)(a) GDPR | With the signup |
| Referral code (only if you arrived through someone's link) | So the person who shared the link is credited. It is a random code, not an identifier of you. You get one of your own to share. | Consent — Art. 6(1)(a) GDPR | With the signup |
That is the complete list for the website. There is no account, no profile, and no field asking for your name, company or role.
In your browser
This site sets no cookies. It keeps at most two small values in your browser's own storage, and neither leaves your device:
-
pulse_ref— the referral code from a link you followed, so it still counts if you sign up a page later. Cleared when you close the tab. -
vf-theme— light or dark, only if you pick one with the switch in the menu. Kept until you clear your browser's site data.
3. Where the list goes
The form posts to this site's own server, which hashes your IP and passes the signup to a small waitlist service in the same Kubernetes cluster, over internal cluster DNS — that service is never exposed to the internet. Both run on a machine in the Netherlands that the maker operates. Its nightly backups include the list.
One outside party carries the list's data: Google. The e-mails — the confirmation and, later, the one telling you early access is open — are sent through Google's mail service (Gmail), so Google receives your address and the message in order to deliver it. Nothing else does: no analytics, no mailing-list SaaS, no CDN in front of this site, no hosted error tracker.
4. The Pulse apps
Pulse has three parts: the hooks on your Mac, which report what Claude Code is doing; a server, which stores those events and sends the notifications; and the iPhone and Mac apps, which show them and send your answers back. Your Mac then types an answer into the session's iTerm tab.
The server
The apps connect to pulse.synccy.com unless you enter another address,
during setup or later in the settings. That server runs on a machine in the maker's home in the Netherlands,
and is reached over HTTPS only. Its domain name is resolved by Cloudflare, but the
traffic itself does not pass through Cloudflare. If you run your own Pulse server,
your data goes there and the maker never sees it.
A Pulse server keeps one shared history, which belongs to its owner's account: every device signed in to that account — with Apple or with the device key — sees the same sessions, events and answers.
The owner is the oldest account on a server — on pulse.synccy.com, the
maker's. The owner also sees every other account on that server, with its Apple
identifier and when it was made, and every device signed in to one, with its platform,
name, model and when it was last used, and can end those sign-ins. Everyone else sees
only their own account and devices, and none of the owner's events.
What your Mac sends
When a session starts, works, finishes, fails or waits for you, the hooks send:
- your prompt (up to 4,000 characters) and Claude's last message (up to 6,000);
- when Claude asks something: the question and its options; when it asks for permission: a short summary of what it wants to do — for a shell command, the command itself;
- for each tool step while it works: one line, and short pieces of Claude's in-between text;
- about the session: its name, the account it runs under, the project folder (its full path), your Mac's computer name, the iTerm session and terminal it runs in, the model, the permission mode, and how long a turn took;
- the usage your Claude Code status line already shows: cost, how full the context is, the five-hour and weekly limits, and how long the session has run.
Before anything goes to the server, the Pulse hook takes secrets — passwords, tokens,
keys, and a user name and password in a URL — out of commands and text, on your Mac.
Only the value is hidden, so the command stays readable: export API_KEY=•••.
This works on recognizable forms and is not a guarantee.
What the apps send
- Your answers: Allow or Deny, the option you picked, or the message you typed.
- Requests you make: start a session (its first prompt, the account, the folder and, if you pick one, the model), or close one.
- To register a device for notifications: its push token from Apple, the device's name and model, its iOS or macOS version, the Pulse version, your notification preferences, and your language (English or Dutch), so its notifications come in that language.
Through Apple
Notifications travel through Apple's push service. A notification carries the session's name, the account and project, and up to 600 characters of text — for example the start of Claude's answer, the question it asks, or the command it wants to run — so Apple carries that text to your device.
How long it is kept
| Data | Kept |
|---|---|
| Events: prompts, Claude's messages, questions, statuses | The latest 2,000. Older ones are deleted in a cleanup that runs after every 50 new events. |
| Your answers | Deleted with the event they answer. An answer your Mac has not picked up expires — after an hour for a message, 15 minutes for a permission or an option — and is never typed after that. |
| Requests to start or close a session | Expire after 10 minutes (start) or 2 minutes (close) if your Mac does not take them, and are deleted in the next cleanup. |
| Tool steps | The latest 40 per session, and none older than two days. |
| Usage per account | Deleted seven days after it was last updated. |
| Registered devices | Until you remove the device in Pulse's settings, its sign-in ends, or Apple reports that its push token is no longer valid (for example after you delete the app). |
| Signing in with Apple | A sign-in stops working after 30 days without use, and after 90 days at the latest; its record is deleted 30 days after it ends. Your account stays until you delete it — see below. |
| Backups | The server's database is in the machine's nightly backup. About two weeks of backups are kept on that machine, with copies on the maker's own computer, so deleted data can live on in a backup for that long. |
The server also writes a technical log of what it did — for example which device registered (by its name), which account and computer an event or answer belongs to, and the folder a new session was asked to start in. It is written so as to leave out the text of your prompts, messages and answers. No fixed retention period is set for that log yet.
Signing in with Apple
Where the server offers it, a device signs in with Sign in with Apple. Pulse asks Apple for no name and no e-mail address. The server checks Apple's answer and keeps only what it needs:
- Your account: the identifier Apple gives Pulse for your Apple Account — the same every time, and different from the one any other developer gets — and the date the account was created.
- Each signed-in device: whether it is an iPhone, a Mac or a browser, the device's name and model, and when it signed in, was last used, and stops working. The key that device uses from then on is stored only as a hash, so the server itself cannot read it back.
A sign-in stops working after 30 days without use, and after 90 days at the latest; you then sign in again. Signing out in Pulse's settings ends that sign-in on the server at once. When a sign-in ends, either way, the device is taken off the list for notifications, and the record of that sign-in is deleted 30 days later. Your account stays until you delete it.
There is no sign-up. Signing in with Apple only opens an account the server already has — or, once, the first account on a server, made by someone who holds its device key, which then takes over the history that is already there. While you sign in, the server keeps a hash of your IP address with the sign-in request, only to limit attempts. The request expires after ten minutes, and used or expired requests are deleted within a minute. The server's log names an account only by a short hash of its identifier.
Deleting your account
You can delete your account in Pulse's settings: under Account in the apps, and under Server on the web. The server then erases it at once and for good: your account, its devices, events, answers, activity and usage, the record of which notifications went where, and every sign-in on every device. The keys those sign-ins used stop working, and your devices get no more notifications. Backups are not edited; what was in them runs out as in the table above.
On the iPhone or Mac you delete it from, Pulse then removes its sign-in, the device key, its copies of your sessions, notifications and devices, and the notifications it showed. The server address, the device's name and your preferences stay.
Pulse does not yet end Sign in with Apple for you. The server cannot tell Apple yet, so Pulse stays in the list of apps you signed in to with Apple. You can remove it there yourself: on iPhone in Settings › your name › Sign-In & Security › Sign in with Apple, on a Mac in System Settings › your name › Sign-In & Security › Sign in with Apple, or at account.apple.com. Pulse reminds you of this once it has deleted your account.
Two exceptions. If yours is the account the server's hooks report to and other accounts are still on that server, the server refuses and erases nothing — otherwise the hooks would pass to someone else; the other accounts have to go first. And an account the maker set up in advance comes back, empty, the next time the server starts, until the maker takes it off that list.
The device key
A device can also sign in to the server with a device key. Pulse
keeps it in the Keychain of each device, available after the device's first unlock
and not synced through iCloud. On the Mac it is also in
~/.config/pulse/device-key, readable only by your user account. The hooks
use a separate key, which can only report events and cannot read anything back.
Treat the device key like a password. Anyone who has it can read everything on that server — prompts, Claude's messages, your answers — and can answer permission requests and start sessions on your Mac. Do not share it, and do not paste it anywhere public.
On your own devices
The apps keep a copy of recent events and sessions on the device, so they open
without waiting for the server. On the Mac, the hooks keep their own files in
~/.config/pulse: events that could not be sent yet (at most 200, sent
with the next one), the latest tool steps, the latest usage, and a log of what the
hooks sent, capped at 512 KB.
To type into the right session, and to close one safely, the Mac app also looks at the
Mac itself: the running processes, Claude Code's own files in ~/.claude*,
and the text on screen in the session's iTerm tab. It reads that screen text:
- when it starts a session for you — to see whether Claude Code is ready, asks whether you trust the folder, or the shell reports an error;
- before it closes a session — to see whether there is text in the input field;
-
after you change the model from your phone — to see Claude Code's
Set model to … confirmation, and to answer its Switch model?
question with the choice you already made. Pulse then puts the account's default
model back in Claude Code's
settings.json, so the change only affects that session.
The screen text stays on your Mac. Only the outcome goes back to the server, and from there to your other devices: typed or not, and why not. That outcome can name a few things: the shell's one-line error when a new session does not start, the model Claude Code confirmed, the programs still running in a tab Pulse left open, and the command to resume a session it closed. When a close stops because there is text in the input field, the outcome says only how many characters there are, with a random reference — never the text itself. Your Mac keeps that text in memory for ten minutes, so that if you close anyway, your phone only sends the reference back, and the Mac closes the session only if the field hasn't changed. Apart from that, nothing on this list leaves your devices except as described above.
What Pulse does not do
There is no analytics, crash-reporting or advertising code in the apps, and no sign-up for a Pulse account. The only address built into the apps is the default server. Pulse does not need Accessibility or Screen Recording on the Mac: it only talks to iTerm, through AppleScript, with the Automation permission macOS asks you for. That is also how it reads a tab's text — from iTerm, not by capturing the screen.
Why
All of this is processed to do what you set Pulse up for — tell you what your Claude Code sessions are doing and carry your answers back — which is the legal basis under Art. 6(1)(b) GDPR.
5. Your rights
Under the GDPR you may ask for access, correction, erasure, restriction or portability, and you may withdraw your consent at any time.
Leaving the list is one click: unsubscribe, or use the link in any e-mail from the list. From that moment you get no more e-mail. The signup itself stays, marked as unsubscribed with the date — that mark is what keeps you from being mailed again, and it is the record that your consent was given and taken back.
In the apps, removing a device in Pulse's settings removes it from the server straight away, and deleting your account there erases it with everything linked to it — see section 4.
For anything else — erasing your signup or your events from the server, a copy of what is stored, a correction — use one of the ways in section 1. It is done by hand, within a month at the latest, as the GDPR requires.
You may also complain to the Dutch data protection authority, the Autoriteit Persoonsgegevens.
6. Security
The website is served over HTTPS only (HSTS, with a forced redirect at the ingress), sets a restrictive Content-Security-Policy, and runs as a non-root user in a read-only container. The waitlist database is not reachable from the internet.
Apart from a health check and signing in, the Pulse server answers only requests that carry a key: the hooks' key for reporting events, and for everything else the key a device got by signing in with Apple, or the device key. The default server is reached over HTTPS only, and its database is not reachable from the internet.
Found a weakness? Use one of the ways in section 1, and keep the details out of public places. There is no bounty — just a fast answer, and credit if you want it.
7. Changes
The version and date at the top are the record. A material change to what is collected will be announced by e-mail to the address on the list.