Overview

Forkbench ("we," "our," or "us") is the controller of the personal data described here. This Policy explains what we collect when you use the Forkbench application, website, and related services (the "Service"), why, and the rights you have. Where the General Data Protection Regulation (GDPR) of the EU/EEA or the UK applies, we process your data as a controller on the legal bases set out below. For any privacy question or request, contact us at [email protected].

Information we collect

Account data

When you create an account, we collect:

Your email address.
A name, if you choose to provide one.
A password hash (we never store plain-text passwords), or an identifier from Google or Apple if you sign in with one of those providers.
Timestamps for account creation, email verification, and sign-in.
Session metadata so you can review and manage your sessions.

Payment data

When you subscribe, payments are processed by Polar as merchant of record; it receives your billing details (such as name, email, payment method, and billing address) and processes the charge. We receive a purchase record (transaction id, product id, status, renewal date) and a customer id so we can grant your subscription and show your purchase history. We never receive your full card number or security code. See the processor's own privacy policy for how it handles billing data.

Notebooks content

We store your notes and notebooks so we can synchronize them across your devices and the Threads you share them with. This content is end-to-end encrypted. It is encrypted on your Mac before it reaches us, under a key held by your enrolled devices and never by us, so what our servers hold is ciphertext we cannot read. There is no passphrase involved and no copy of the key on our side.

We do still hold, and can see, the facts that come with storing it for you: how many items you have, how large each stored blob is, when each last changed, and which of your devices wrote it. Those are described together in What is encrypted, and what we can read below.

Vault content

If you use Vault, the values of your credentials are held encrypted on your Mac under a key sealed to that Mac's secure hardware, and they never leave it in a readable form. Where they synchronize between the Macs you have enrolled, we store and serve only ciphertext, together with a signed record of the set, which is what lets your own devices detect a stored item being dropped, rolled back or swapped. We cannot read the value of a credential, and we cannot recover one. As above, we can see how many items exist, their sizes, and when they changed.

Shared Threads

When you invite somebody into a Thread, we store what is needed to run that membership: who is a member, at what role, when they joined or were removed, and the invitation and redemption records. The Thread's own contents, including its notes and its board, are encrypted under a key belonging to that Thread, which we do not hold. So we can see that a Thread exists, who is in it, and that its contents changed; we cannot see what the objective says, what the tasks say, or what the notes say. The short secret used to admit somebody is never sent to us.

Talk data

To connect the web to the agents on your paired Macs, we process:

Device and pairing data — a device name, platform, app version, online status, and last-seen time for each Mac you pair, so you can identify and manage your devices.
Conversation and message data — the messages, instructions, and commands you send, and the agent replies and status your Macs relay back, plus related metadata such as project names and paths. This content passes through and is stored on our servers so we can deliver it and queue it while a Mac is offline.

Talk is not end-to-end encrypted, and we will not imply that it is. Unlike your notes, your credentials and your shared Threads, the conversation content that crosses Talk is held in a form our servers can read, and our servers do read it in the ordinary course of assembling and delivering it. It is encrypted in transit and at rest in the usual sense, and access to it is restricted, but the protection is operational rather than mathematical: we could read it, so treat it as you would any hosted message. What crosses is the parsed conversation, meaning the prompts and the replies, along with conversation titles. Raw tool output and terminal scrollback are not sent. Conversation content is deleted a few minutes after a conversation stops being live, unless it belongs to a shared board.

The AI coding agents you run are third-party tools. The code and prompts those agents process on your machines are handled by the agents and their AI providers under their own policies; we relay the messages you choose to send to and from them, and we do not control the agents' own processing. We do not use your notes or messages to train AI models.

Transactional email

We use Resend to send account email (verification, password resets, receipts, and billing notices). Resend receives the recipient address and the content needed to deliver the message, and does not use it for marketing.

Error tracking

If error tracking is enabled, we use Sentry to record application errors and the minimum note needed to diagnose them (such as app or browser version, error stack, and a request id). We scrub identifiable information from these reports where practical.

Website analytics

When you visit our website, we use our own first-party, privacy-first analytics — we do not use Google Analytics. To measure traffic and improve the site, we record lightweight events such as page views and where a visit came from, together with:

A random visitor identifier kept in your browser's local storage, and mirrored into a first-party cookie (see Cookies, storage, and consent below). It is not a fingerprint and is not derived from your IP address or your account; it lets us count unique visits and group a session. We honour the browser Do-Not-Track signal — when it is on, we record no website analytics.
The page path, the referring website, and any campaign (UTM) tags of your visit.
A coarse location — a country code, and, where our edge can resolve it, an approximate city, region, and a city-level point (latitude/longitude of the city, used for an activity map) — derived at our edge from the network connection. We do not store your IP address with this analytics data.

If you are signed in, these website events are associated with your account so we can understand the signed-in experience; if you are not signed in, they remain tied only to the random identifier. When you first arrive we also record the acquisition source (referrer/campaign) and, if you later create an account, attach that first-touch source to your account so we can understand which channels bring users.

Precise location (only if we enable it): we can optionally resolve a more precise location — finer coordinates than the coarse city-level point above — from your IP address using a local geolocation database inside our own infrastructure — your IP is not sent to any third party for this. This precise tier is off by default; if we turn it on we will obtain consent first where required, and we still do not store your IP address unless separately stated here.

Cookies, storage, and consent

We keep the use of cookies and browser storage to a minimum:

Strictly necessary — a first-party session cookie keeps you signed in and secures forms. This is required for the Service to work and does not need consent.
Analytics (first-party) — the random visitor/session identifiers described under Website analytics are stored in your browser's local storage, and a small record of your consent choice is stored there too. The visitor identifier is also mirrored into a first-party cookie, because local storage cannot be read by our server: without it, signing in with Google or Apple could not be connected to the visit that brought you here. It is set only where analytics is permitted, holds nothing but that same random identifier, and is cleared with your site data. No third-party analytics cookies are set.
Marketing (only if enabled) — if we turn on any advertising measurement (see How we share), the relevant provider may set its own cookies; these load only where you have consented.

We do not set third-party analytics cookies, and we honour the browser Do-Not-Track signal for analytics. You can clear all first-party storage at any time by clearing site data in your browser.

App usage data (optional)

The Forkbench desktop application can share anonymous usage data with us — only if you choose to turn it on. The app asks once on first launch, sends nothing until you agree, and you can change your mind at any time in the app's Settings → Privacy; turning it off also deletes the app's local telemetry identifier and queue.

If you enable it, the app sends:

A random installation identifier generated on your device. It is not derived from your hardware, account, or network, and it is not linked to your account — usage data is analyzed separately from who you are.
The app version, macOS version, device architecture, and language setting.
A coarse location — a country code, and (where our edge can resolve it) an approximate city, region, and a city-level point (latitude/longitude of the city) — derived at our edge from the network connection when an event arrives. We never store your IP address with usage data. City, region, and coordinates are kept only on the short-lived raw events; once those are reduced to aggregates (see retention below), only the country code remains.
Content-free usage counters — for example that the app was launched, that a feature was used, how long a session lasted, or that a connection dropped and recovered.
How much you hold and how you work — plain counts of how many Threads, notebooks, notes and stored credentials exist on the install; which agent programs you run and how many run at the same time; whether a note or a credential was created by you or by one of your agents; whether a library was opened as a tab or in the side panel; and whether an invitation was sent, refused or accepted. These are numbers and fixed labels from a list we publish in the app's source — never a name, a folder, a value, or anything you typed.

The app never sends the content you work with. No code, prompts, commands, transcripts, file names, file paths, project or workspace names, error message text, or keystrokes are ever included in usage data.

We use this data solely to understand which versions are in use, how features are adopted, and where reliability needs work. Raw usage events are kept for at most 90 days, after which they are reduced to aggregate statistics (counts per day) that no longer contain the installation identifier, and the raw events are deleted.

Logs and usage data

We keep server-side request logs (such as IP address, timestamp, and route) for operational and security purposes, and for account security we record the IP address and device/browser associated with sign-ins, two-factor checks, and new-device approvals so that you and we can detect suspicious activity. These are retained for a limited period and are not used for marketing. This account-security logging is separate from website analytics, which does not store your IP address.

What is encrypted, and what we can read

Different parts of the Service are protected in genuinely different ways, and the difference matters enough to set out in one place rather than leave you to infer it.

Encrypted so that we cannot read it. Your Notebooks content, the values of your Vault credentials, and the contents of a shared Thread including its board are encrypted on your devices under keys we do not hold. We store and serve ciphertext. No employee, no support request, no subpoena and no compromise of our servers alone produces the plaintext, because the plaintext is not something our servers have.

Readable by us, because delivering it requires that. Your account and billing records, your device and pairing records, Talk conversation content, and our operational logs are held in a form we can read. These are protected by ordinary means: encrypted connections, restricted access, and retention limits.

What we can see even where we cannot read. Encryption hides content, not the existence of content. For the encrypted surfaces above we still learn, and you should assume we hold: how many items you have and how large each stored blob is; when each was created or last changed and from which of your devices; which Threads exist, who is a member of each and at what role; the labels attached to task rows, such as which agent or owner a task is assigned to; and the base folder names of the projects you open. We use this to run the Service, not to build a profile of you.

Encryption stops us reading your data. It does not by itself stop us, or anyone who compromised us, from altering it. That matters here more than in most products, because your agents act on what they read: an item silently dropped, rolled back, or swapped is a way to steer an agent without ever decrypting anything. So your devices verify a signed record of the whole set before they act on it, and a check that fails causes your device to refuse the update. It never causes anything to be deleted.

Where the protection stops. We are describing how the Service is built, not promising an outcome. The keys live on your devices, so the security of your data rests in part on the security of those devices and of the operating system underneath them, which are outside our control.

Legal bases for processing

Where the GDPR applies, we rely on the following legal bases:

Performance of a contract — to create and run your account, provide the Service (including synchronizing your notes and relaying your Talk messages to and from your paired Macs), and handle subscriptions and billing.
Our legitimate interests — to secure the Service and your account, prevent and investigate abuse, debug, and keep the Service reliable, balanced against your rights and freedoms.
Your consent — where we ask for it: for the optional app usage data sharing, and when you choose to sign in with Google or Apple. You can withdraw consent at any time — in the app's Settings → Privacy for app usage — without affecting processing that already took place.
Legal obligations — to meet accounting, tax, and other legal requirements.

How we use information

We use the information we collect to:

Authenticate you and protect your account, devices, and the Service from abuse.
Provide the Service — including synchronizing your notes and relaying your Talk messages to and from your paired Macs.
Provide Paid Features to subscribers and manage billing.
Send transactional email about your account and purchases.
Diagnose and fix problems and improve reliability and security.
Comply with legal obligations and enforce our Terms.

We do not sell your personal information for money.

How we share information

We share information only with the service providers needed to run the Service, acting as our processors, and only as needed:

Polar — payment processing and billing.
Resend — transactional email delivery.
Cloudflare — our network edge and infrastructure: it serves and protects all of our website and application traffic and hosts downloads. As the edge, it processes visitor connections (including IP addresses) and provides the coarse country/city used for analytics; it acts as our processor for this.
Sentry — error tracking, where enabled.
Google and Apple — only if you choose to sign in with them.

Advertising measurement (only if we enable it). We may enable one or more advertising-measurement tools to understand which campaigns bring visitors — for example Meta, Google, TikTok, LinkedIn, X (Twitter), Pinterest, Snap, or Reddit. These are off unless we turn them on, and where consent is required they load only after you agree. If measurement with Meta is enabled, our server may additionally send Meta a limited, mostly hashed event record — such as a hashed email address, together with your IP address and browser user-agent — to match a conversion. Each provider processes the data it receives under its own privacy policy.

We may also disclose information when required by law or to protect the rights, property, safety, or security of Forkbench, our users, or others. If we are involved in a merger, acquisition, or sale of assets, information may be transferred as part of that transaction.

International data transfers

Some of our service providers process data in countries outside your own, which may include countries outside the EEA or UK. Where we transfer personal data outside the EEA or UK, we rely on appropriate safeguards — such as a European Commission (or UK) adequacy decision, or Standard Contractual Clauses — so that your data keeps an equivalent level of protection.

Your rights

Subject to applicable law, you have the right to access, correct, delete, or receive a portable copy of your personal data, to restrict or object to certain processing, and to withdraw consent where processing is based on it.

Four of these are self-service, and work immediately without asking us:

Get a copy of everything (access, portability). Your account page has a Download your data link. It produces a single JSON file containing every record we hold about your account — profile, sign-in history, devices, notebooks and notes, Threads and boards, Talk conversations, Vault entries, sharing history, and the analytics events recorded while you were signed in. End-to-end encrypted content is included in its sealed form, because we cannot decrypt it; open it on a paired Mac for plaintext. Credentials — your password hash, two-factor secret, wrapped keys and passkeys — are deliberately left out.
Correct what's wrong. Your name and email address are editable from your account page.
Delete everything. See the next section.
Clear the website analytics tied to your browser. Those records key off a random identifier stored in your browser, not off your account. Clearing this site's data removes the link at your end; the records themselves lose their identifiers on the schedule below.

For anything else — restriction, objection, or a question about the above — email [email protected]. We answer within one month, as the law requires, and we will tell you if we need longer and why. We do not charge for any of this.

If you are in the EU/EEA or the UK, you also have the right to lodge a complaint with your local data protection supervisory authority, and you may do so without going through us first.

Data retention and deletion

We keep personal data only for as long as the purpose we collected it for lasts, and no longer. In practice that means two different mechanisms: most things live exactly as long as your account does, and a handful of stores — logs, telemetry, expired sign-in links — run on a clock of their own.

How long we keep each thing

Account and profile — Life of the account, then erased within 30 days. Your email address, name, sign-in method, and the devices you have paired. Needed to provide the Service under our agreement with you. The purpose ends when the account does.
Your content — Life of the account, then erased within 30 days. Notebooks and notes, Threads and their boards, Talk conversations, and Vault entries. Stored to provide the features you are using. Deleted items follow their own shorter clock (below); the rest is erased with the account.
Deleted notes and Threads — 30 days. An item you delete is held so you can restore it, then destroyed for good. A restore window that protects you from your own mis-click. After it, the rows are hard-deleted, not merely hidden.
Billing and tax records — 10 years. Invoices, payments, refunds and the ledger entries behind them. Accounting and tax law require a business to keep its books for a fixed period that outlives the customer relationship. These survive account deletion, with the email address they were billed to, because a ledger entry that cannot be matched to a customer does not discharge the obligation it exists for. Nothing else about you is kept with them.
Terms acceptance records — 6 years after the account closes. Which version of the Terms you accepted, and when. Kept to establish or defend a legal claim about what was agreed. Six years tracks the ordinary limitation period for a contract claim.
Security events — 12 months. Sign-ins, failed sign-ins, new-device alerts, two-factor changes, and the IP and browser they came from. Needed to detect and investigate account takeover, and to show you your own sign-in history. A year covers a full cycle of seasonal fraud patterns; beyond it the record is of no further use.
Sharing and access history — 12 months. Who opened, claimed or was granted one of your notes or secrets, and from which machine. This log exists so that you can audit access to your own material. It is only useful for as long as you might ask the question, and it is erased with the account regardless.
App usage events — 90 days, then aggregate only. Optional, pseudonymous product analytics from the Mac app — which features are used, never what you typed. Raw events carry a random install identifier. After 90 days they are folded into per-day counts that carry no identifier at all, and the raw rows are deleted.
Website analytics — 90 days, then aggregate only. Which pages were visited, from which country, and where the visit came from. After 90 days the random visitor and session identifiers are stripped, leaving records that cannot be tied back to a browser.
Crawler and bot hits — 6 months. Requests our site received from search-engine and AI crawlers. Used to see which crawlers reach the site. Not tied to any person; kept short because it stops being informative once it is stale.
Email delivery records — 24 months. Which service emails we sent you and when, so that we do not send them twice. The record of a send is what stops a repeat send. It also evidences that a required notice was actually given, which is why it outlives the message itself.
Sign-in links and codes — 7 days after they expire. Email verification links, password-reset links, pairing codes, and two-factor challenges. These are single-use and short-lived by design; every route already refuses an expired one. The sweep is what stops the spent rows accumulating.
Encrypted database backups — 35 days. Point-in-time snapshots taken so the Service can be restored after a failure. Data you delete is removed from the live database immediately, but a snapshot taken before that deletion still contains it until the snapshot itself expires. Backups are never used to repopulate a deleted account.

Each of these periods is enforced by a scheduled job that deletes the data, not by a policy someone is meant to remember. The list above is generated from the same schedule those jobs read, so it cannot describe a period we are not actually applying.

Deleting your account

You can delete your account at any time from your account page. What happens is:

Immediately. The account stops working. Every web session is signed out and every paired Mac is disconnected. Nothing is destroyed yet.
Within 30 days. We email you a confirmation with a link that cancels the deletion. That link works without signing in — which matters, because if someone else requested the deletion using your account, they hold the session and you do not.
After 30 days. Everything is erased: your notebooks and notes, Threads and boards, Talk conversations, Vault entries, paired devices, sign-in and sharing history, and the account record itself. This is a real deletion at the database level, not a flag that hides the data. It cannot be undone, by you or by us.

Two things survive, and only two. Billing and tax records, because accounting law requires a business to keep its books for a fixed period that outlasts the customer relationship. And the record of which version of our Terms you accepted, in case of a legal claim about what was agreed. Both are held for the periods in the table above and then deleted.

Backups. Deletion removes your data from the live database straight away, but encrypted backups taken beforehand still contain a copy until they expire, within 35 days. Backups are never used to restore a deleted account.

Encrypted content. Where content is end-to-end encrypted, erasing it here removes our copy. Any copy on a Mac you have enrolled stays on that Mac — we never held the keys and cannot reach it.

Accounts nobody uses

If an account goes unused for 2 years, we delete it. Holding on to personal data we have no live reason to hold is not something we are willing to do, and an account nobody has touched in 2 years has no purpose left to justify it.

You get 30 days' notice by email, and a second reminder 7 days before it happens. Both carry a one-click link that keeps the account, and neither requires you to sign in. Signing in, or using a paired Mac, has exactly the same effect and resets the clock completely. Accounts with a subscription or any payment history are never treated as dormant.

Security

We use industry-standard safeguards, including encrypted transport (HTTPS), hashed passwords, signed webhooks, and least-privilege access to infrastructure. No system is perfectly secure. Because sessions use signed tokens, signing out and changes such as a password reset apply going forward and to new sign-ins; an already-issued session may remain valid until it expires (within 7 days). Report security concerns to [email protected].

Beyond those ordinary safeguards, the sections above describe the parts of the Service that are encrypted so that we cannot read them at all. Two consequences of that design belong here rather than in the small print:

We cannot recover encrypted data on your behalf. If you lose access to every Mac you have enrolled and to your recovery code, that data is gone permanently, for you and for us. Keep your recovery code, keep an enrolled Mac, and export anything you could not afford to lose.
We hold no security or compliance certification. We are not SOC 2, ISO 27001, PCI DSS or HIPAA certified or audited, and we do not act as a HIPAA business associate. Please do not use the Service for data whose handling requires an assurance we have not given you.

We publish a vulnerability disclosure policy, with a safe harbour for good-faith research, in our Terms of Service and at our published security contact. If you believe you have found a security problem, write to [email protected] rather than to support.

Children

The Service is not directed to children, and we do not knowingly collect personal data from children below the age of digital consent that applies to them. If you believe a child has provided us personal data, contact [email protected].

Changes

We may update this Privacy Policy from time to time. If we make material changes, we will notify you through the Service or by email.

Contact

Questions about this Privacy Policy, or want to exercise your rights? Email [email protected].