Privacy Policy

This Privacy Policy explains how CodedWords ("we", "us", "our") handles personal data in connection with the Plexus desktop application ("Plexus", the "App") and our website. We are committed to protecting your privacy and to processing personal data in line with the EU General Data Protection Regulation (GDPR).

Note. This policy describes the anonymous usage analytics Plexus collects (section 3), the feedback you can choose to send us (section 3a), the managed connection service it uses when you connect a git provider (section 5), the optional Plexus account you can create (section 5a), Settings sync if you switch it on (section 5b), your prompt library if you switch that on (section 5c), the workspaces your organization shares with you (section 5d), the settings it manages on your machine (section 5e), the prompts it publishes to you (section 5f), and — if you buy one — the paid subscription on that account, which is invoiced through the provider described in section 5 and recorded as set out in section 5a. Two of the ten store nothing that identifies you, your machine or your work — the analytics and the managed connection service; the feedback you send us, the account you create, the settings you sync, the prompts you save, the workspaces your organization shares, the settings it manages, the prompts it publishes and the subscription you buy are the deliberate exceptions. Five of those eight, like the connection service, exist only because you asked for them. The last three are the exceptions to even that: a workspace your organization shares, a setting it manages, and a prompt it publishes, can reach you without your asking, because somebody else put them there — which is why sections 5d, 5e and 5f say what an administrator can put on your machine, what we record about you when they do, and what neither they nor we can reach. Section 5e is also where the one thing your machine sends back is described: during a dry run of a setting, a single yes or no. Separately from the App, our website uses Google Analytics only if you accept it in its cookie banner (section 4b).

1. Who is responsible

The controller for the processing described here is:

CodedWords (a sole proprietorship / eenmanszaak established in the Netherlands)
Registered address: Korhoenstraat 124, Tilburg, Netherlands
KvK number: 75572214
Contact: timo@codedwords.com

2. Plexus is local-first

Plexus is a desktop application that runs on your own computer. Your code, your files, your repositories, your terminal sessions, your credentials, and the prompts and Output you exchange with AI Agents stay on your device; nothing in the App collects them or sends them to us. There are exactly three ways any of that can reach us, and you perform all three of them yourself.

The first is Feedback: writing to us and choosing to attach a picture of the Plexus window or a diagnostic log. That is a deliberate act, one submission at a time, and section 3a describes exactly what it carries.

The second, since version 0.21.0, is Settings sync (section 5b), and it carries your configuration rather than your work — no code, no file contents, no sessions, no transcripts, and nothing you said to an AI Agent in a session or it said back. One sentence that used to sit here has been withdrawn rather than softened. Until version 0.21.0 this policy said the prompts you write cannot be synchronised between your machines at all. Your prompt library (section 5c) is exactly that, for prompts you deliberately save under a name — it is off until you switch it on, and section 5c is the field-by-field account of it. What remains true, and is a different statement, is that nothing you typed into a session and nothing an Agent said back ever leaves your machine. Two things on the list above do travel, and they belong in this paragraph rather than in a subsection somebody has to reach. The first is the identity of each repository you added to Plexus: its host/owner/name and the address you would clone it from, so that another machine you sign in on can offer to set the same project up — never a path, and never anything inside the repository. The second is the standing instructions you typed into a setting for the review, fix and commit-message agents. Those are settings like any other and they travel as you wrote them: not a prompt from a session, but text you wrote, which is reason enough to say so plainly. Sync is off until you turn it on, it needs a Plexus account holding a paid plan or a seat, you can exclude any workspace or project from it, and it shows you every value it would send before the first byte leaves.

The third, also since version 0.21.0, is your prompt library (section 5c), and it is the one that touches this paragraph most directly: a prompt template is text you wrote for an AI Agent, and saving one to your account stores those words on our servers. It is off until you switch it on, it shows you every prompt in full before the first one leaves, and it never carries a prompt you typed into a session, an Agent's reply, or a template a project committed to its own repository. Section 5c is the field-by-field account of it.

Version 0.21.0 also brought something else you can deliberately give us, of a different kind again: an optional Plexus account (section 5a). An account by itself carries none of the above: it holds your name, your email address, and the names of any organizations you create — and, only if you buy a subscription, the billing details an invoice needs and a record of the plan itself (section 5a). It exists only if you make one, having one by itself unlocks nothing — Settings sync needs a plan or a seat as well — and signing in by itself uploads nothing and switches nothing on.

Version 0.21.0 brought one more thing, and it is the only one in this policy that runs the other way. An organization you belong to can share a workspace with you (section 5d): its name, its description and the addresses of the repositories that belong in it arrive on your machine from your organization rather than leaving it for us, and you can receive one without having asked, because sharing is somebody else's act. What that puts on our servers is not your work but a fact about you — that you are one of the people it was shared with, and how you came to be one. Nothing goes back the other way: not a path, not a checkout, not a session, not a branch, and not whether you cloned any repository it offered you.

The same organization can also manage a setting for you (section 5e), and this is the one thing in this policy that can lock part of your configuration: a value an administrator enforces is applied on your machine above your own, and the row is read-only there until they stop. A value they merely recommend is set once and is yours to change. Nothing about your own settings goes back to them or to us — not your value, not where you set it. The one thing that does go back, and only while an administrator is running a dry run of a setting, is a single yes or no from your machine: whether the value there differs from the one proposed. Section 5e is the field-by-field account, including how briefly that answer is kept.

Settings sync is the first feature of the App that a paid plan unlocks, so the older statement that nothing here is behind a paywall no longer holds and we are not going to soften it into one that reads as though it does. What is true instead, and what we have committed to in section 14 of the Terms, is narrower and more useful: nothing that already worked has moved behind the plan. Every session, worktree, git operation, review, agent and setting works exactly as it did before, on a machine that has never signed in and never paid us anything. A plan adds; it does not fence off.

Some data is stored locally on your machine so the App can work — for example, your settings, workspace and session state (in a local database), and any credentials you ask the App to store (kept in your operating system's secure keychain). This data does not leave your device except where you explicitly connect a third-party service (see section 5), explicitly send us feedback (see section 3a), sign in to a Plexus account (see section 5a), buy a subscription on it (see sections 5 and 5a), or switch on Settings sync (see section 5b). Sync is the only one of those five that copies part of that local data itself, which is why section 5b lists what it takes field by field and the App shows you the same list before it takes anything. One thing is derived from it without copying it: during an organization's dry run of a setting (section 5e), the App compares its value here with the one proposed and sends the comparison — a yes or a no — and not the value. The one routine exception is that the App periodically checks our release server for updates (see section 4); that check carries no usage data and none of Your Content.

Ten limited exceptions are described below. Two of them are automatic and carry none of your work: when you choose to connect a git provider we use a managed sign-in service (section 5), and Plexus sends anonymous usage analytics (section 3). Neither sends us your code, file contents, prompts, file paths, or repository names. The other eight are not automatic at all. Feedback you write and send us yourself (section 3a) carries whatever you type and, if you choose them, a picture of the App's own window and a diagnostic log that names repository paths and branch names; it happens only when you press Send, and the App shows you what is in it first. A Plexus account (section 5a) exists only if you create one, and holds what an account is made of — your name, your email address, your organizations, and the machines you have signed in from. Settings sync (section 5b) runs only if you switch it on, only while your account holds a paid plan or a seat, and only after you have been shown the whole of what it would send; it carries your settings, the names of your workspaces and projects, and each project's repository slug and clone address, and you can exclude any workspace or project from it. A subscription (sections 5 and 5a) exists only if you buy one, and adds what an invoice needs: the billing details you enter, the plan and its seats, and the invoices our invoicing provider raises for it. Your prompt library (section 5c) holds the templates you choose to save to your account, and nothing a project commits to its own repository. The workspaces your organization shares (section 5d) and the settings it manages (section 5e) run the other way — configuration an administrator wrote arrives on your machine — and the one thing that leaves for them is, during an organization's dry run of a setting, a yes or a no per setting saying whether it would change here. The prompts your organization publishes (section 5f) run the same way — a prompt template an administrator published arrives in your template list, badged with the organization's name — and nothing of yours leaves for them at all. None of the ten changes the local-first default, and none of them carries your code, your file contents, the prompts you exchange with an AI Agent in a session, or its Output.

3. Usage analytics

Plexus sends anonymous usage analytics so we can see how many people use the App, which parts of it they use, and where it breaks. This is part of how the App works and there is no setting to switch it off — because what it sends is anonymous: there is nothing in it that identifies you, and nothing that can be traced back to you, your machine, or your work. What keeps that true is set out below, and we hold ourselves to it. (Earlier versions of the App had a Share anonymous usage data setting. It has been removed, including on installs where it had previously been switched off.)

This section is about the analytics only. Feedback you send us is a separate channel with a separate legal basis, and the two never touch: a feedback submission carries no analytics identifier of any kind, and nothing in the analytics can be linked to a feedback item. See section 3a.

At most one message a day. The App contacts us once per calendar day and not again that day. There is no per-action, per-session or real-time reporting, and no timestamp finer than the date. It is a daily summary, not a log of what you did or when you did it.
What is collected. Your operating system and processor type (both coarse — e.g. macOS / Windows / Linux, Arm / Intel-AMD), the app version, and a random install identifier your copy of Plexus generates, which our server turns into a hash under a key that changes every day and never stores as it arrived. Alongside that, the message carries how much the App was used since the previous message — for example how many sessions were run, how many turns you exchanged with an agent, and how many times each feature or Git operation was used — plus a small set of coarse settings and environment facts: your colour theme, which AI model you have selected, whether a Git provider is connected, how many workspaces and projects you have as a range (such as "6-20") rather than an exact figure, your operating-system version, how Plexus was installed, your shell, and the version of the Claude CLI it is driving. We also count total downloads when you download the App.
What the analytics never collect: your code, file contents, prompts, Output, file paths, repository, project or branch names, commit or pull-request text, error messages, your IP address, or any account or device identifier. Nothing you type is ever part of it, and every value we do collect is either a number or one of a fixed set of options — never free text. (Some of those can appear in a diagnostic log you choose to attach to feedback — that is a different channel, described in section 3a, and it never rides on the analytics message.)
Why it cannot be tied to you. The usage counts are added into shared daily totals the moment they arrive and are never stored against your install, so no record of "what this install did" exists on our systems at any point. Separately, the daily hash lets us count how many distinct installs were active — and because the key changes every day, the same install looks like a different, unrelated value tomorrow. Those per-install rows are then deleted every night once they have been counted. What remains are aggregates such as "1,240 active installs on macOS running 0.18.0" and "18,300 sessions run in February" — nothing that could be linked back to an install, let alone to a person.
The install identifier expires. The random identifier stored on your device is replaced with a new one after a year, so it does not persist indefinitely. The identifier is sent to us over an encrypted connection and hashed on arrival; we never store or log it as it arrived.
All analytics data is stored within the European Union.
Legal basis: the data is anonymous within the meaning of Recital 26 GDPR — it does not relate to an identified or identifiable person — so it is not personal data and data-protection law does not apply to it. To the extent any of it were nonetheless treated as personal data, we rely on our legitimate interest in maintaining and improving the App (Article 6(1)(f) GDPR).
Switching it off completely. Plexus honours the DO_NOT_TRACK and PLEXUS_NO_TELEMETRY environment variables — set either one before launching and the App sends nothing at all. Development builds never send analytics.

3a. Feedback you send us

Plexus has a Feedback button. It is entirely optional, it does nothing until you press Send, and — unlike the analytics in section 3 — it is not anonymous: you are writing to us, and what you write can say anything you choose, including things that identify you.

What is always sent: the message you type, whether you marked it as a bug, an idea or something else, and a short list of technical facts about your copy of the App — its version, your operating system and its version, your processor type, how Plexus was installed, and the version of the Claude CLI it is driving. Those are the same coarse values the analytics use, and they carry no identifier.
What is sent only if you choose it, on that one submission:
- Your email address — blank unless you type it. We use it to reply to you and for nothing else; we do not add it to any mailing list. Leave it blank and we simply cannot reply.
- A screenshot — nothing is captured until you press Attach screenshot, and you can remove it again before sending. It is a picture of the Plexus window only, drawn by the App from its own interface. It cannot contain another application, another monitor, anything behind or beside the Plexus window, or your desktop — and because it is not an operating-system screen capture, Plexus never asks for screen-recording permission. It can, of course, contain whatever your own code and file names were on screen at the time, which is why you see the image before you send it.
- A diagnostic log — a technical trace of what the App was doing. Before it leaves your device, Plexus blanks out anything shaped like a credential and rewrites your home folder and username. It deliberately keeps repository paths, branch names, worktree folder names, session identifiers, timings and error text, because those are what make the log useful; it never contains file contents, your prompts, or an AI Agent's Output. You can read the exact text that will be uploaded before you send it.
What is never sent: your code or file contents, your prompts or an AI Agent's Output, the contents of any secret file, anything from your operating system's keychain, any git provider account you have connected, your Plexus account or any identifier from it (section 5a) — a report is byte-for-byte the same whether you are signed in or signed out, and if you want us to know who sent it you type your email address in the box like anyone else — and any identifier from the usage analytics in section 3: no install identifier and nothing derived from one.
You see it before you send it. The App shows the message, the screenshot and the log text in the same dialog as the Send button. If it is not on that screen, it is not uploaded.
Legal basis: your consent (Article 6(1)(a) GDPR), given by pressing Send on a submission the App has shown you, with the screenshot and the log as separate choices you make each time. You can withdraw it at any point by asking us to delete the submission (below).
Where it is stored and who sees it: in the European Union, on the same infrastructure as our other managed services. Only our operators can read it, through a sign-in-protected admin panel. We do not use it for advertising, we do not profile you with it, we do not feed it to an AI model, and we do not sell or share it.
How long we keep it: any screenshot or diagnostic log you attached is deleted after 90 days; the message itself, and the email address if you gave one, after 12 months. Both are enforced by an automated purge.
Deleting it. When a submission succeeds, Plexus shows you a reference code and keeps it in a list on your device. Email that code to timo@codedwords.com and we will delete the submission and anything attached to it. We only ever delete on a code — we never read a submission back to whoever sends one. If you gave an email address, that identifies your submissions too. If you sent a submission without an email address and no longer have the code, we have no way of finding it — which is the other side of not being asked who you are (Article 11(2) GDPR).

4. Update checks and our website

To let you know when a new version is available, Plexus periodically contacts our release server — the public plexus-releases repository hosted on GitHub — to download a small update manifest and, if you choose to update, the new release. Like any web request, this reveals your IP address and the current app version to GitHub as the host, but it carries no usage data and none of Your Content. This is a routine update check, not the analytics described in section 3.

When you download Plexus from our website, the download button routes through a lightweight redirect that increments an anonymous total-download counter and then forwards you to the file hosted on GitHub. This records standard request metadata (such as your IP address in transient server logs, processed in the EU) but no usage profile and none of Your Content. The counter itself holds nothing but a date, a platform, an app version and a running total — no account, no visitor identifier, and no per-download record of who asked for what.

When you visit our website, our hosting provider may process limited technical data needed to deliver the site securely and reliably (such as your IP address in server logs). The marketing and documentation website (runplexus.com) is a static site and sets no advertising cookies. It uses one analytics service, Google Analytics, and only if you accept it in the cookie banner — section 4b describes exactly what that does, and what happens if you say no.

The prices on the website's pricing page are read from our own server when the site is built, not when you open the page: the build asks for the current list of plans, and the page you receive already contains them. That request is made by our build system rather than by your browser, and it carries no personal data in either direction.

The newsletter is not currently offered. The website has no signup form today, and we collect no email address for a newsletter. When we do offer it, it will work as described in this section: it is optional, it is separate from the App, and it uses double opt-in: nothing is sent to you except one confirmation email until you click the link in it.

What we store. Your email address; whether it is still waiting for confirmation or confirmed; a short tag saying which form on the website you used (for example the blog or the home page); and when you signed up, when we sent the confirmation email and when you confirmed. That is all. We do not store your IP address or your browser's identification string with it. Your IP address is used only to stop the form being abused, in a short-lived counter that expires within the hour and is not linked to your email address.
Why, and on what basis. To send you the newsletter, and for nothing else. The legal basis is your consent (Article 6(1)(a) GDPR), which you give by clicking the confirmation link; the time of that click is our record of it. The newsletter list is not linked to a Plexus account, to the usage analytics in section 3 or to feedback in section 3a, and we do not sell or share it.
No tracking in our emails. Our emails contain no tracking pixels and no tracked links, so we do not record whether or when you open them or what you click.
How long we keep it. An address that is not confirmed within 14 days is deleted automatically, and the confirmation link stops working at the same time. A confirmed address is kept until you unsubscribe.
Unsubscribing. Every newsletter carries a link that unsubscribes you in one click. Unsubscribing deletes your address from the list; we keep no "do not email" copy of it. You can also write to timo@codedwords.com and we will delete it.
Who processes it for us. The list is stored on the same infrastructure as our other managed services, in the European Union. Only our operators can see it, through the same sign-in-protected admin panel as feedback, and they can export it to send the newsletter. Emails are delivered through Cloudflare's Email Service (Cloudflare, Inc.), which receives your email address and the message in order to deliver it. We have not yet established where Cloudflare processes a message it delivers, and we will state it here when we have, rather than assume an answer.

The account panel is a different website on a different domain (app.runplexus.com), and it does set cookies, because a site you sign in to has to. On that domain it sets a session cookie that keeps you signed in from one page to the next, a CSRF token that stops another site submitting its forms on your behalf, and — only if you ask to be remembered when signing in — a cookie that keeps you signed in for longer. They are set by that domain and readable only by it, they exist to keep you signed in and to protect the forms you submit, and there is no advertising, analytics, profiling or cross-site tracking cookie on it. That domain also hosts the download redirect described above, so if you are signed in to the panel your browser sends the session cookie with a download click too, as it would with any request to that domain. All that does is keep your own session record current (its last-activity time, and the IP address and browser identification string that session already carries); it writes nothing to the download counter, and the counter has no field that could hold it. Cookies that are strictly necessary to provide a service you explicitly asked for are exempt from the consent requirement in Article 5(3) of the ePrivacy Directive, which is why the panel shows no cookie banner. The only cookies on either domain that are not strictly necessary are the Google Analytics cookies on runplexus.com, and those are set only after you consent to them (section 4b); if we ever add another, we will update this policy and ask for your consent first.

The checkout page and the customer portal are neither of those domains. They are pages on our invoicing provider's own domain (moneybird.com), which we send you to with a one-hour link; whatever cookies they set are set by that provider under its cookie and privacy policy, not ours, and we neither see them nor control them (section 5).

4b. Analytics on our website

The website runplexus.com — not the App — can use Google Analytics 4 to tell us which pages are read, how visitors find them, and roughly where they are from. It runs only with your consent, which is why the site shows a cookie banner the first time you visit.

Before you choose, and if you choose Reject, nothing is loaded. The Google Analytics script is not requested, no Google Analytics cookie is set, and nothing about your visit is sent to Google. Reject is one click, on the same banner and as prominent as Accept, and the site works exactly the same either way.
If you choose Accept, your browser loads Google's script, which sets two first-party cookies (_ga and _ga_<id>) holding a random identifier, so that pages viewed in one visit and across visits can be counted together. They expire after 13 months. With each page view it sends Google the page address and title, the referring page, your browser, device type, screen size and language, and the time; it also records a few interactions on the page — scrolling to the bottom of it, clicking a link that leaves the site (such as a download), and starting or submitting a form — with the address of the link or page involved, never what you type into a form — and, inevitably for any web request, your IP address, which Google uses to estimate a country and city and then, according to Google, does not log or store for Google Analytics 4.
What we have switched off. We use Google Analytics for statistics only: Google signals, ad personalisation and every advertising signal are disabled in the page itself, so your visit is not linked to a Google account and not used for advertising by us. We do not send Google your name, email address or any account identifier, and the website has no account to link one to.
Who receives it. The service is provided to us by Google Ireland Limited (Gordon House, Barrow Street, Dublin 4, Ireland), acting as our processor under Google's data processing terms. Google may process the data in the United States; Google LLC is certified under the EU–U.S. Data Privacy Framework, which the European Commission has found to provide an adequate level of protection, and Google's standard contractual clauses also apply.
Legal basis. Your consent (Article 6(1)(a) GDPR, and Article 5(3) of the ePrivacy Directive for the cookies).
How long. We keep Google Analytics event data for 2 months, Google Analytics' shortest retention setting; after that only aggregated reports remain, which do not identify you.
Changing your mind. Cookie settings in the footer of every page reopens the banner. Choosing Reject there stops collection immediately and deletes the _ga cookies from your browser. We remember your choice — accept or reject — in your browser's local storage (not a cookie, and never sent to us), and ask again after 12 months. Clearing your browser's site data also clears it, and the banner will ask again.

5. Third-party services you connect

Plexus lets you connect third-party services that you choose, such as:

AI Providers (for example, Anthropic for Claude Code). When you run an AI Agent, your prompts and the relevant parts of Your Content are sent directly from your device to that AI Provider under that provider's own terms and privacy policy. We are not a party to, and do not control, that processing.
Git hosting providers — GitHub and Bitbucket — when you sign in to manage repositories or pull requests.
Plnnrly — when you connect a Plnnrly organization to work its projects inside the App (see Plnnrly below).

Managed connection service (OAuth broker). When you connect a git provider, Plexus uses a small service we operate in the European Union to complete sign-in. The provider returns a short-lived authorization code; the service exchanges it for an access token (and refreshes it) using our confidential app credentials, and the token is returned to your device and stored in your operating system's keychain. We do not receive or store your repositories, pull-request contents, or code — after sign-in your device talks to the provider directly. We process only the minimal technical data needed to complete the exchange (such as the authorization code and the provider's token responses), on the legal basis of performing the connection you asked us to make.

Permission checks on a connected provider. A provider can narrow what an already-issued token is allowed to do, and nothing tells the App when that happens — so while a git provider is connected, Plexus makes one small request to that provider to check whether the token it holds still carries the access the App needs. This runs shortly after the App starts, when the window regains focus, on a background timer that pauses while the Plexus window is hidden, after a run of refused provider requests, and after you sign in again. Each check goes directly from your device to GitHub or Bitbucket; it carries the access token already in your keychain and nothing else — no code, file contents, file paths, repository names, or usage data — and Plexus reads only whether the request was allowed and which permissions the provider names in reply. Nothing about it reaches us: the request does not pass through our servers, we are not told that it happened, and the result stays on your device (as with every provider call, a token close to expiring is refreshed first through the managed connection service described above). Repeat checks are throttled — once a provider has answered, Plexus waits six hours before asking it again, though a check that could not reach the provider, or a refusal you run into while working, can make it ask sooner. You can change that wait, or stop the checks entirely, with Check that provider connections still work and How often to check provider connections (hours) under Settings → Git; turned off, no such request is made at all. Disconnecting the provider stops it too.

Pull request review comments. When a session has a pull request, Plexus can show that pull request's review conversation in the Review tab. It is requested directly from GitHub or Bitbucket by your device, using the token in your keychain — only when you open the Review tab, when the App window regains focus, or when you press Refresh; the conversation itself is never fetched on a background schedule, and never through us. If you reply to a thread, post a new comment, or resolve one, the text you write and the action you take go straight from your device to that provider, where they are published on the pull request under your provider account and are then governed by that provider's own terms and privacy policy. The same applies when you choose to publish an inline note that was stored on your device: its text — including text an AI Agent drafted for you, which the published comment marks as such — is sent from your device to that provider and published on the pull request under your provider account, and the local copy is then deleted from your device. Nothing is published without you asking for it, note by note or as a batch you confirm, and nothing about it passes through us. The conversation that comes back — including other people's usernames and the comments they wrote — is kept in memory on your device only: it is not written to the local database and is not sent to us. Comment bodies are rendered with remote images and other remote media blocked, so opening a review does not cause your device to request anything from a third-party image host. If you choose to send review comments to an AI Agent, their text becomes part of the prompt sent to your AI Provider, as described above.

Your issue tracker in Plexus. Since version 0.21.0 a project or a workspace can have a GitHub repository, or a GitHub project (a board), attached as a tool, and Plexus can then show that repository's issues in an Issues tab and that project's boards in a Board tab, let you open, edit, comment on and create issues and move cards, and start a session from an issue. Everything is requested directly from GitHub by your device, using the token in your keychain — only for repositories and projects you attached yourself, only while such a tab (or the issue sidebar of a session started from an issue) is open, and on a timer that asks about once a minute for issues and once every two minutes for boards while the Plexus window is focused, less often while it is merely visible, and not at all while it is hidden; when several projects share one attached tool, they share one request. A request carries the token and the repository or project you attached, and asks for the issues or cards, one issue's text and comments, or the repository's labels, collaborators and milestones. What you change is sent to GitHub the same way: an edited title or text, a comment, a new issue, a changed label, assignee, milestone or state, or a card moved on a board goes from your device to GitHub under your own account, exactly as if you had made the change on github.com, and appears there under your name. What comes back — issue titles, text, comments, labels, and the usernames of authors and assignees — is kept in memory on your device only, for at most a few minutes. The one thing written to the local database is the link a session was started from: that issue's number, title and address, stored with the session and deleted with it. Issue text is rendered inside the App the way GitHub renders it, from a sanitised copy that loads nothing from the web — images and other remote media are left out — and reaches an AI Agent only when you leave Send the issue to the agent as the first prompt ticked, at which point it becomes part of the prompt sent to your AI Provider as described above. Working a board needs a GitHub permission (project) that a repository connection does not carry; the App asks you to reconnect GitHub only once you attach a project, and a connection without one is left as it is. Nothing about any of this reaches us: no request passes through our servers, we are not told that one happened, and a rate limit or a rejected token is shown in the tab and stays on your device. The usage report (section 3) counts only that a tool or a board was attached, an issue created or edited, a comment added or a card moved — never which repository, which project, which issue, or what was written. This is one of the seven things a paid plan unlocks (section 5a), and one of the two that store nothing with us; whether your plan includes it is answered by the same hourly request every signed-in copy of the App already makes, which carries no repository name. Detaching the tool, or closing the tab, stops the requests.

Plnnrly. You can connect one or more Plnnrly organizations under Settings → Integrations and attach a Plnnrly project to a project or a workspace, and Plexus can then show that project's work items, board and sprints in a Plnnrly tab, let you open, edit, comment on, create and move work items and start or complete sprints, and start a session from a work item. Every request goes directly from your device to the address of your own Plnnrly organization (for example acme.plnnrly.com, or the organization's own domain) — not through the managed connection service described above, and not through any other server of ours. You connect only by signing in through your browser — Plexus registers itself with your organization's own sign-in service and receives its sign-in directly from your organization, never through us; an organization whose Plnnrly does not offer that sign-in yet cannot be connected. The sign-in is stored only in your operating system's keychain, and Plexus renews it with your organization directly while you use it; the App's local database records only which organization addresses you connected, the name and identifier Plnnrly reports for your account where it reports one, and when you connected — none of which is sent to us. Disconnecting removes the sign-in from your keychain and, where your organization supports it, asks Plnnrly to revoke it. Apart from connecting and the project picker, which lists your organization's active projects so you can choose one, requests are made only for projects you attached yourself, only while a Plnnrly tab (or the work-item sidebar of a session started from one) is open, and on a timer that asks about once a minute while the Plexus window is focused, less often while it is merely visible, and not at all while it is hidden. What you change is sent to your Plnnrly organization the same way, under your own Plnnrly account, exactly as if you had made the change in Plnnrly. What comes back — work items, their descriptions and comments, labels, sprints, statuses and the names of your organization's members — is kept in memory on your device only, for at most a few minutes; the one thing written to the local database is the link a session was started from (the work item's key, title and address), stored with the session and deleted with it — and the attached project's organization address, identifier, title and the way it is organised (whether it runs in sprints), stored with the tool and deleted when you detach it. Descriptions and comments are rendered from a sanitised copy that loads nothing from the web — images and other remote media are left out — and reach an AI Agent only when you leave Send the issue to the agent as the first prompt ticked when starting a session, as described above. Nothing about any of this reaches us: we are not told that a request happened, and an error is shown in the tab and stays on your device. The usage report (section 3) gains two counts from it — that a Plnnrly organization was connected, and that a sprint was started or completed. Attaching a project, creating or editing a work item, adding a comment and moving a card are counted in the same counters as for GitHub, so the report cannot tell the two apart. None of them says which organization, which project, which work item, or what was written. Plnnrly connections are not part of Settings sync (section 5b). The Plnnrly tab is part of your issue tracker inside Plexus (section 5a), and whether your plan includes it is answered by the same hourly request every signed-in copy of the App already makes, which carries no Plnnrly address. Your use of Plnnrly itself is governed by your organization's agreement with Plnnrly and by Plnnrly's own terms and privacy policy.

Stacks & ordered merging. When you stack sessions on each other's branches, or merge pull requests from Plexus, Plexus keeps them consistent on your git provider: it pushes a branch it synced (with a lease, so it never overwrites someone else's push), changes a pull request's target branch, and writes a short list of the stack's pull requests at the end of each one's description. Since version 1.3.0, on GitHub it also groups a stack's open pull requests into one of GitHub's own stacked pull requests — creating, extending and dissolving that GitHub stack as your stack changes — unless you turn off Create stacks on GitHub; where GitHub shows the stack itself, the list in the descriptions is left out. Which GitHub stack a pull request belongs to arrives with the pull request details Plexus already reads, and if you stacked pull requests on GitHub yourself, Plexus reads that stack to nest the matching sessions. For the pull requests you merge — with Merge, Merge up to here, Merge stack or Merge in order — Plexus reads their checks and mergeability and, when you open the merge confirmation, the branch they merge into, whether that branch requires a merge queue and the repository's merge method; then it merges them, which on GitHub can mean asking GitHub to merge a stacked set in one step and checking back until GitHub reports the result. On Bitbucket it reads whether a pull request's branch requires Bitbucket's merge queue and whether the pull request is in it — Bitbucket does not let it add a pull request to that queue, so you do that on Bitbucket yourself — and, for a pull request other sessions are stacked on, asks Bitbucket to keep its branch after the merge. Every one of those requests goes directly from your device to GitHub or Bitbucket with the token in your keychain, only for the pull requests of sessions you stacked (in Plexus or on GitHub) or chose to merge, and appears on the provider under your own account. Nothing about it reaches us: no request passes through our servers, we are not told that one happened, and what is being merged — which pull request is waiting for what — and which GitHub stack a pull request belongs to are stored only in the local database on your device. The usage report (section 3) gains nothing from it beyond the count of pull requests opened that it already carries. This is the seventh thing a paid plan unlocks (section 5a), and with your issue tracker one of the two that store nothing with us.

Pull requests, submodules and Git LFS in the project Git tab. The project Git tab can list a repository's pull requests. The list is requested directly from GitHub or Bitbucket by your device, using the token in your keychain — while its Pull requests section is open, about once every two minutes while the Plexus window is focused, and when you press Refresh; never while the window is hidden, and never through us. Since version 1.3.0 the same list is also read, the same way, so that a session's row can show whether its pull request is waiting for a review: only for a project in which a session has an open pull request, when Plexus first shows that project, when the Plexus window regains focus, shortly after Plexus notices a change to one of that project's pull requests, and when you open a session's Stack panel — and never more than about once a minute for a project, besides opening the panel. This read is not part of a paid plan. What comes back — titles, branch names, check and review states, and authors' usernames — is kept in memory on your device only and is gone when you close the App. Authors are shown as initials drawn on your device: no avatar image is fetched from the provider. Checking out a pull request, updating a submodule, pulling Git LFS files and locking or unlocking an LFS file are ordinary git operations that contact the remotes configured in your repository, only when you ask for them, exactly as running the same git command yourself would. Nothing about any of this reaches us, and the usage report (section 3) gains nothing from it.

Commit author avatars (Gravatar). The project Git client can show avatars next to commits. To resolve an avatar, Plexus sends a one-way SHA-256 hash of a commit author's email address (taken from your local repository's history) directly from your device to Automattic's Gravatar service (gravatar.com), which is how Gravatar is designed to be queried; the email address itself is never sent, and we receive nothing. Results — including "no avatar exists" — are cached on your device so each author is looked up at most occasionally. You can turn this off with the git.avatars.gravatar setting (Settings → Git), in which case Plexus renders initials locally and makes no request. Gravatar's own processing is described in Automattic's privacy policy.

Automatic fetching from your git remotes. The project Git client periodically runs git fetch in the background so that branch ahead/behind counts and the commit graph stay current. These requests go directly from your device to the git remotes you configured yourself (for example your GitHub, Bitbucket or self-hosted server), using the credentials git already holds on your machine; nothing is sent to us or to any third party we control, and we receive no notice that a fetch happened. It only downloads — nothing in your repository is merged, checked out, deleted, or otherwise changed. Fetching pauses while the Plexus window is hidden, and you can turn it off globally or for a single project with the Fetch from remotes automatically setting (Settings → Git), or from the Pull button's menu in the project Git client.

Invoicing and payments (Moneybird). If you buy a subscription (section 5a), it is billed and invoiced through Moneybird B.V., an invoicing and payment provider based in the European Union. We give Moneybird what an invoice needs, and no more: your name or your organization's company name, the invoice address, the country, a VAT number and chamber-of-commerce number if you give one, the invoice email address, the plan and how many seats it is for, and a reference that identifies you as a customer at their end. We do not give them your code, your repositories, your file names, anything from the App, or anything from the analytics in section 3.

Your payment details go to Moneybird directly from you, not through us. The checkout page and the customer portal are pages on Moneybird's own domain, opened with a link valid for one hour; the card number, bank account or direct-debit mandate you set up there is entered on their page and handed to them. We never receive, see or store a card number, an IBAN or a mandate. The most we hold is the fact that a valid mandate exists — a yes or no, with nothing in it that could be used to charge anyone. Moneybird issues and stores your invoices and determines the VAT on them from the country, address and tax number in your billing details; we hold a copy of what each invoice says (its number, date, state and totals), never a payment instrument.

Moneybird processes part of this for us, on our instructions, and part of it under its own statutory bookkeeping and anti-money-laundering obligations — where it acts under those, it decides for itself what it has to keep and for how long, and its own privacy policy governs that processing. Whether that makes it our processor under Article 28 GDPR, an independent controller for the statutory part, or both at once is a question we are having answered properly rather than assumed, and we will state the answer here. We would rather leave a question open in writing than publish a tidier one we have not checked.

We encourage you to review the privacy policies of any service you connect. We are not responsible for how those third parties process your data.

5a. Your Plexus account

A Plexus account is optional. It exists only if you create one, and signing in by itself uploads nothing and switches nothing on — everything the App does on your own machine behaves exactly as it did before you signed in. Since version 0.21.0 seven things are conditional on a paid plan or a seat — Settings sync (section 5b), saving a prompt template to your account (section 5c), receiving the workspaces an organization shares (section 5d), receiving the settings it manages (section 5e), receiving the prompts it publishes (section 5f), your issue tracker inside Plexus (section 5), and Stacks & ordered merging, called stacked pull requests with a land queue before version 1.3.0 (section 5 — with the issue tracker, one of the two that run between your device and your git provider and store nothing with us). All seven are new: nothing that worked before any of them began requiring an account or a payment, and nothing that works today will (see section 14 of the Terms). An account is not a third-party service you connect (that is section 5) — it is an account with us, and this section is what we hold when you have one.

What an account stores.

You — the name and email address you give us, the date we confirmed that address, and your password stored only as a one-way hash, which means we cannot read it or recover it for you. Since version 1.0.0, also a profile picture, if you add one from the App: it is cropped to a 128 × 128 square on your own device before it is sent, so what we hold is that small square (at most 64 KB) and a content hash of it — never the original file, its name, or anything the original carried, such as where or when it was taken. It is shown to you, on the machines you sign in on, and to nobody else; you can replace or remove it at any time from the App, and it is deleted with the account.
Two-factor authentication, if you switch it on — the secret your authenticator app is set up with, stored encrypted, and your recovery codes, stored as one-way hashes inside that same encryption, so we cannot read a recovery code back to you either.
Your organizations — the name of each organization you create, the web address derived from that name, and the fact that you are its owner. Since version 0.21.0 it also holds the roles the organization is composed of: the five every organization is created with, any role you write yourself, the name and one-line description you give it, and which permissions each one allows or denies. Those are records about the organization, not about a person.
If other people join one, it holds which of those roles each member has been given, and that is a fact about a person. It is used for one thing — answering, on each request that member makes, whether they are allowed to do what they just asked to do — and the answer is worked out from the roles at the moment it is asked. We keep no history of what anybody did with a permission, no log of their requests, and nothing that could be assembled into one. The full set a member holds is readable by the people who may manage that organization's roles; everybody else in the organization sees the same one-word summary (owner, admin or member) that a membership carried before. When you open an organization in the App, the answer it receives also includes the list of permission names your own roles resolve to, so a screen can tell you what you may do — it is computed for that one request and is about you.
For an invitation you send, it holds the email address you addressed it to, the role it names, who sent it, and whether it is still pending or has been accepted, declined, revoked or expired. An email address you type into an invitation is someone else's personal data: we use it to deliver that one invitation and to let that person accept it, and for nothing else.
Since version 0.21.0 an organization can also hold the workspaces it shares and who is in each of them. The workspaces are records about the organization; who is in one is a fact about a person, written by whoever put them there. Section 5d is the field-by-field account of both, and of the much shorter list of what an administrator can reach on the machines that receive them — which is nothing.
The machines you have signed in from. Each one is a row in your Signed-in devices list holding the machine name you were shown on the consent screen before it was stored, which platform it is, which version of Plexus signed in, and when the sign-in was created, last used, and expires. The sign-in token itself is stored only as a one-way hash. That row deliberately records no IP address and no browser or device identification string — the name, the dates and the platform are what let you recognise a machine, and they are the only fields you can act on; anything more would build a location history of you as a side effect. You can sign any device out from the App or from the panel, and doing so ends that sign-in immediately.
Your browser session on the panel. Signing in on the web creates an ordinary web session, and — as on any site you sign in to — that session record carries your IP address and the identification string your browser sends, for as long as the session is valid. Expired sessions are deleted automatically.

What a signed-in App asks us, and how often. Now that one feature depends on a plan, a signed-in copy of Plexus has to know whether yours includes it, so it asks: one small request, when the App starts, and at most once an hour. It carries the sign-in token already in your keychain and nothing else — no code, no file names, no settings, no repository or project names, and nothing from the analytics in section 3 — and the answer is a short list of feature names, which the App keeps on your device so that a screen can tell you what is included without asking us again. Settings sync (section 5b) and your prompt library (section 5c) add one background check each, but only once you have switched them on: each asks whether anything has changed, no more often than Check for changes every (minutes) allows. Until you do, neither makes a request in either direction. The workspaces your organization shares (section 5d) add a third, and it is the one with no switch in front of it — there is nothing to turn on, because it is a list arriving rather than anything of yours leaving — so it runs on that same clock whenever you are signed in and your organization's plan reaches you. If it does not reach you, your machine does not ask at all: that is decided on your own device before any request is made. Like the others it carries the sign-in token already in your keychain and a number saying how much of the list you have already seen, and nothing else. The settings your organization manages (section 5e) add a fourth, on the same clock and under the same rule — no switch, decided on your device, silent unless an organization's plan reaches you — and it is the one of the five that can carry something back: while an administrator is running a dry run of a setting, one yes or no per setting under evaluation, and never a value. The prompts your organization publishes (section 5f) add a fifth, on that same clock and under that same rule, carrying the same token and a number saying how much of the library you have already seen, and nothing else. Apart from those five, the anonymous daily message in section 3, which carries nothing about your account, and the routine update check in section 4, that request is the only thing a signed-in App sends on its own.

What a subscription stores. If you buy a plan (section 14 of the Terms), the account it hangs off also holds what running and invoicing that plan needs — and nothing beyond it:

The plan — whether it is an individual plan or a per-seat organization plan, its state (for example pending, active or cancelled), when it started, when it renews or ends, and whether an invoice on it is currently overdue.
Seats, and who holds each one. For an organization plan: how many seats it pays for, and which member holds each seat. That last one is a fact about a person other than whoever pays — if you assign a seat to a colleague, we store that you did, against their membership. It is visible to the people who administer that organization, and removing them from the organization removes it.
What that record means has changed, and we would rather say so than leave the old reasoning standing. When seats were introduced we described this as low-impact because a seat changed nothing about what anybody could do. That was true of every feature in the App at the time, and it stopped being true in version 0.21.0: a seat now carries Settings sync (section 5b) to the member holding it, which makes it an access-control record rather than a billing detail. So the limits are the record's own. It is a single timestamp on a membership — that a seat was assigned, and when. It carries no history of what the member did with it, no usage, no log of anything they ran, and it is used for one thing: answering, for that person, which paid features their organization's plan reaches. It is not combined with the anonymous analytics in section 3, which have nowhere to put it.
Billing details — the name and invoice address the invoice is made out to, the country, an invoice email address, and, where you give them, a company name, a VAT number and a chamber-of-commerce number. These are the details printed on the invoice, and they are the ones passed to our invoicing provider (section 5).
A customer reference — the identifier that matches you, or your organization, to the corresponding record at that provider. It is a reference, not a payment detail: nobody can be charged with it.
What each invoice says — its number, date, due date, state and totals, so the account panel can show you your invoices without sending you elsewhere for the list. The invoice document itself is issued and stored by our invoicing provider.

No payment details are any part of this — no card number, no IBAN, no mandate; they are given to our invoicing provider directly and never to us (section 5). And nothing here rides on the anonymous analytics in section 3 or on a feedback submission in section 3a: a usage report and a feedback report from a paying account are identical to ones from an account that has never bought anything, and neither has a field that could hold a plan, a seat or an invoice.

Legal basis for the subscription: performance of a contract — providing and invoicing the plan you bought (Article 6(1)(b) GDPR). For the invoice data we must keep afterwards, the basis is different and is not ours to waive: compliance with a legal obligation (Article 6(1)(c) GDPR), because Dutch tax and bookkeeping law requires us to retain invoices. Section 6 says for how long.

What an account does not store. Nothing about your work. Your code, your file contents, your branch contents, the prompts you exchange with an AI Agent, its Output, your sessions, your transcripts and your hooks are not part of an account, are not uploaded when you sign in, and cannot be synchronised between your machines at all. Signing in uploads nothing: on a second computer it gives you your organizations, the workspaces they share with you, the settings they manage and the prompts they publish if you hold a seat (sections 5d, 5e and 5f), your device list and what your plan includes, and nothing else.

Your settings, workspaces and projects and your saved prompt templates are the two parts of the App that can now follow you, and only because you asked for them: that is Settings sync (section 5b) and your prompt library (section 5c). Each is off until you switch it on, each needs a paid plan or a seat to store anything new, and each has a field-by-field account below of what it takes and what it structurally cannot. Neither is implied by having an account.

A workspace your organization shares is a different thing again, and not a third part of this: it does not follow you from one of your machines to another, it arrives from your organization on each of them separately (section 5d). That is also why your own settings override on one stays on the machine you set it on.

Signing in changes nothing about the anonymous analytics in section 3 or the feedback in section 3a. Neither carries your account, your account identifier, or anything derived from either, and nothing we store about your account is or can be linked to them. That separation is deliberate and is not a setting.

Legal basis: performance of a contract — providing the account service you asked us for (Article 6(1)(b) GDPR). Where you switch on two-factor authentication, we also rely on our legitimate interest in keeping accounts secure (Article 6(1)(f) GDPR).
Where it is stored: in the European Union, on the same infrastructure as our other managed services.
What we do not do with it: we do not use it for advertising, we do not profile you with it, we do not feed it to an AI model, and we do not sell or share it.
How long we keep it: for as long as the account exists, except that an invitation you sent is deleted 90 days after it is finished with (section 6 says why) and a device sign-in expires on its own after a year unused. You can delete your account yourself from the account panel, once you have deleted any organization you own — an organization cannot be left without one. Deletion removes the account, its organization memberships, any seat assigned to them, every shared-workspace membership and join request that hung off those memberships (section 5d), every dry-run answer your devices reported (section 5e), every device sign-in, everything Settings sync holds for you including its retained versions (section 5b), and every prompt template we hold including its retained versions (section 5c), and it is not recoverable. One thing survives it: an invoice we have already issued, which the law obliges us to keep — section 6 says what that means and for how long. Independently of all this, a device sign-in expires on its own and is refused from that moment, whether or not you signed it out.

5b. Settings sync

Settings sync keeps your Plexus settings, workspaces and projects the same on every machine you sign in on. It arrived in version 0.21.0, it is off until you switch it on, and it needs a Plexus account together with a paid plan or a seat on one (section 14 of the Terms). It syncs your configuration and nothing you have made with it — a sentence worth keeping exactly as it is, and true only because the thing you have made with it lives in its own service with its own switch: your prompt library (section 5c). It goes by more than one name and they are one feature: the App says Settings sync where it tells you what your plan includes, and Cross-device under Settings → Sync, while version 0.21.0's release notes call it cross-device sync. This section covers it under whichever name you met it.

What it holds is yours, personally. Sync is attached to your account and never to an organization, even when an organization's plan is what pays for your seat. Nothing in it is shared with the people you work with or with the people who pay for your seat, and no screen in the App or in the account panel shows one person's synced settings to anybody else — nor is there an admin screen on our side that reads them; we did not build one. That is a property of how the feature is put together rather than a setting you have to find: every request it makes, and every record it writes, is addressed to one person's account, and there is no organization-wide address for any of it.

Nothing crosses before you have seen it. Turning sync on opens a screen listing every setting key and value, every workspace and project name, every repository slug and every clone address that would leave this computer — and, separately, what is being held back and why. You exclude any workspace or project on that screen; excluding a workspace excludes every project inside it. Only then does the first byte leave. What this machine sends…, in Settings → Sync, re-opens the same screen whenever you want it, and excluding something you had already synced removes it from your account on the next sync.

What crosses, if you turn it on.

Every setting you have changed from its default, key and value, for the 77 of this release's 92 settings classified as portable. That includes free text you typed into one: your AI code-review instructions, your Review-and-fix agent instructions and your AI commit message instructions travel as you wrote them.
Three settings that name a path inside your project — Where to create session folders, Files and folders to copy and Write ports to file. Every value of these is checked again at the moment it would leave, and one that is not a relative path inside the project is held back and named on that screen. An older version of Plexus accepted an absolute path in these fields, so this is checked on the way out rather than trusted from when it was saved; the effect is that none of them can carry a folder layout or a username off your machine.
Each workspace's name, description, position in your list, and whether it is the default one.
Each project's name, position, base branch, and which workspace it belongs to.
Each project's repository slugs — for every remote it has configured, the host/owner/name triple, lowercased: github.com/codedwords/plexus, and never a path on your disk.
Each project's clone address — the fetch URL of its origin remote, with any password removed before it leaves, and on http and https addresses the username removed with it. This is what lets another machine offer to clone the same repository instead of asking you to find it.
Workspace- and project-level overrides of those same portable settings, attached to the workspace or project by an identifier generated on your own machine — never by anything derived from a path, a repository or a row number.
Which of your machines made each change, and when. The machine is the one from your Signed-in devices list (section 5a); its name is copied onto the record rather than linked to it, for the reason given below.
Up to 20 previous versions of all of the above, each a full copy of what your account held at that point, kept so that you can restore one.

Nothing about an excluded workspace or project crosses — not its name, not its slug, not its existence.

What cannot cross. Not "is not sent today": nothing in the App serializes any of the following, and a machine receiving it discards it rather than storing it.

The 15 settings classified as belonging to this machine — the ones whose value is a fact about this computer: the path to your claude binary, your shell and its path, your port range, how many sessions are kept ready, your hook timeout, whether the base branch is fetched before a rebase, all three diagnostics settings, whether commit-author avatars are looked up on Gravatar, whether merging a pull request tears its session down unattended, and the two switches for sync itself (Sync this machine and Check for changes every (minutes), so that switching sync off on a laptop can never switch it off on the machine you are not sitting at). A machine setting stays machine-local at every level: putting a value on a workspace or a project never widens what may leave.
Everything in your operating system's keychain — your GitHub and Bitbucket tokens, your Plnnrly sign-ins, your Plexus account sign-in. Sync reads the keychain for its own sign-in token and for nothing else.
Every absolute path on your machine — where a repository is checked out, where a session's worktree lives, where the diagnostic log is written.
Every session, and everything on one: its name, its branch, its state, its activity, its reserved ports, its agent session id, its background agents.
Every pull request record, review comment, session summary, hook run and transcript, and every hook you defined, including the ones in a repository's own .plexus/hooks.json.
Your code. No file contents, no file names, no diffs, no commit messages, no branch contents.
Your install identifier from section 3, your usage counts, and the list of feedback you have sent.
Every setting override you made on a single session, at any key, at any time.
A workspace your organization shares with you, and everything attached to it — its name, its description, the repositories it carries, and your own settings overrides on it. None of that enters your personal sync account: an organization's workspace is delivered to each of your machines by the organization (section 5d), never copied from one of your machines to another, so its names and repository addresses stay out of a store that is yours alone. That is the reason an override you set on one stays on the machine you set it on, where an override on a workspace of your own travels.

When it contacts us, and when it does not. With sync switched on, Plexus asks our server whether anything changed when it starts, when its window regains focus, and a couple of seconds after you change a setting — never more often than Check for changes every (minutes) allows, which is 15 minutes by default and can be no less than 5. With sync switched off, the App makes no sync request on its own, in either direction — nothing on a timer, nothing at startup, nothing when you change a setting, not even the check for whether there is anything to read. One thing does reach us before sync is on, and it is the screen itself: opening it reads what your account already holds, so that it can show you which values differ between this machine and the ones you have signed in on before. That read sends nothing of yours, and the first thing that leaves this computer is what you approved on that screen.

Legal basis: performance of a contract — providing the sync service your plan or your seat entitles you to (Article 6(1)(b) GDPR).
Where it is stored: in the European Union, on the same infrastructure as our other managed services.
What we do not do with it: we do not use it for advertising, we do not profile you with it, we do not feed it to an AI model, and we do not sell or share it. It is joined to nothing else we hold: the anonymous analytics in section 3 and a feedback submission in section 3a carry no account identifier at all, so neither of them can be matched to what sync holds, in either direction.
How long we keep it: the current values, plus the last 20 versions, until you delete them. Switching sync off does not delete them and neither does cancelling a plan — see section 6, and the two paragraphs below.

Switching sync off and deleting what we hold are two different things, deliberately. Turning Sync this machine off stops this machine syncing and deletes nothing, because a switch on a laptop must not destroy the configuration your other machines are still using. Stop syncing and forget what we hold, in Settings → Sync, is the deletion: it removes both resources, every value and all 20 retained versions from your account. It asks you to confirm, it cannot be undone, and it leaves everything on your own device untouched. Deleting your Plexus account removes all of it too (section 5a). Cancelling a plan, on the other hand, deletes nothing — what we hold is kept so that resubscribing picks up where you left off rather than starting empty.

That button does not stop working when your plan does. A plan or a seat is what lets sync store anything, and once it lapses nothing new is stored — but the delete is deliberately not part of what a plan buys. Cancel, let it lapse, never pay us again: Stop syncing and forget what we hold still answers, and the App still shows it to you. A lapsed subscription does not make the data any less yours, and nothing we hold is ever conditional on paying us to get rid of it. Deleting your Plexus account removes all of it too, and writing to us at timo@codedwords.com works whatever the state of your plan.

Signing a device out does not delete what that device synced, and that is on purpose. Revoking a machine is a security action you take in a hurry, usually because you no longer have the machine, and it must not also destroy your settings and your restore points. So the record of which machine wrote a version is a copy of that machine's name, never a link to the sign-in: revoke the device and the history still reads "MacBook Pro", with everything it wrote intact. Deleting the data is the separate, confirmed act above, and it is the only thing that does it.

5c. Your prompt library

Prompt templates are prompts you have written and saved under a name, with the parts that change turned into fields you fill in. They arrived in version 0.21.0, and this is the first thing in Plexus that stores something you wrote for an AI Agent on our servers. We would rather open the section with that sentence than have you find it in a list.

It is off until you switch it on, and saving a template to your account needs a Plexus account together with a paid plan or a seat on one (section 14 of the Terms). Reading, running, copying, exporting and deleting the templates you already have need neither, and never will — see the last two paragraphs of this section.

A copy of everything stays on your computer, always. This is different from Settings sync in a way that matters here: the App keeps a complete local copy of your library and reads from that, not from us. Our copy is what carries it to your other machines; it is never the only copy. That is what makes the exports and deletions below work with no network, on a lapsed plan, and after you have stopped paying us.

What it holds is yours, personally. Your library is attached to your account and never to an organization, even when an organization's plan is what pays for your seat. Nothing in it is shared with the people you work with or with the people who pay for your seat, and no screen in the App or in the account panel shows one person's templates to anybody else — nor is there an admin screen on our side that reads them; we did not build one. Our own operational screens show counts and sizes and never a template's words or its name, and a test refuses to let that change. An organization has a library of its own (section 5f), and the two never touch: a template of yours reaches the organization's library only when you propose it there yourself, as a copy, and nothing an organization publishes is ever written into yours.

Nothing crosses before you have seen it. Turning it on opens a screen listing every template that would leave this computer — each one in full, the whole prompt, not a summary — alongside what is being held back and why. Only then does the first one leave. That screen re-opens from Settings → Prompts whenever you want it.

What crosses, if you turn it on.

The name of each template, as you typed it.
Its description, if you wrote one.
The body of the prompt, in full and exactly as you wrote it. This is text you composed for an AI Agent, and there is no way to store a prompt library without storing the prompts. Up to 64 KB per template, and up to 500 templates.
Its fields — each one's name, its label, its hint, whether it is needed, its default, and for a "choose one" field the list of choices. All of it as you typed it.
Which list it is filed under — just you, a workspace, or a project — and, for the latter two, the same machine-generated identifier Settings sync uses (section 5b). Never a path, never a repository name, never a row number.
Which of your machines made each change, and when. As in section 5b, the machine's name is copied onto the record rather than linked to the sign-in, so signing a device out never destroys what it wrote.
Up to 20 previous versions of each template, kept so a change can be undone.

What cannot cross.

Templates committed to a repository. A project can keep prompts in its own .plexus/templates/ folder, and those are read from your checkout and never sent to us — there is no field on the wire that could carry one. This is structural, not a setting.
The values you fill a template in with. Filling in a field and running the prompt happens entirely on your machine; what you typed into a field is never sent to us, and neither is the finished prompt.
Anything from a session. No transcript, no Output, no code, no file contents, no file paths. Save as template… lifts your own opening prompt out of a session and puts it in an editor for you to change and then save — what reaches us is what you saved, if you saved it.
Everything section 5b already lists as unable to cross. Nothing here widens that list.

When it contacts us, and when it does not. With it switched on, Plexus asks our server whether anything changed when it starts, and after you save a template — never more often than Check for changes every (minutes) allows, which is 15 minutes by default and can be no less than 5. With it switched off, the App makes no request about templates on its own, in either direction. Opening the screen described above reads what your account already holds, so it can show you what is there; that read sends nothing of yours.

Legal basis: performance of a contract — providing the service your plan or your seat entitles you to (Article 6(1)(b) GDPR).
Where it is stored: in the European Union, on the same infrastructure as our other managed services.
What we do not do with it: we do not read it, we do not use it for advertising, we do not profile you with it, we do not feed it to an AI model, and we do not sell or share it. It is joined to nothing else we hold: the anonymous analytics in section 3 and a feedback submission in section 3a carry no account identifier at all, so neither can be matched to what your library holds, in either direction. The analytics count how many templates an install has, in a bucket — 0, 1, 2–5, 6–20, 21+ — and can carry no name, no field name and no length of anything you wrote.
How long we keep it: the current version of each template, plus the last 20 versions of it, until you delete them. Switching it off does not delete them and neither does cancelling a plan — see section 6. A template you delete is removed straight away, and its retained versions go with it: a deletion takes the words, not just the entry.

Deleting works when nothing else does. Delete every template we hold, in Settings → Prompts, erases every template and every retained version from your account at once. It asks you to confirm, it cannot be undone, and — this is the part worth reading twice — it leaves the copies on your own computer exactly where they are. Your library keeps working after you press it; what changes is that we no longer have any of it. Deleting a single template from the list does the same thing for that one. Both work on a lapsed plan, on a cancelled one, and after you have stopped paying us: deleting is deliberately not part of what a plan buys, and nothing we hold is ever conditional on paying us to get rid of it. Deleting your Plexus account removes all of it too (section 5a), and writing to us at timo@codedwords.com works whatever the state of your plan.

If a plan ends, you keep every prompt you wrote. A plan or a seat is what lets us store a new one; once it lapses nothing new is stored. Everything already in your library goes on listing, running, copying and exporting on every machine that has it, because the copy on your disk is complete and the App reads from that. A plan that ends takes away the ability to write to your account and takes away nothing else.

5d. Workspaces your organization shares

A shared workspace is a workspace one person in an organization sets up so that everybody in it receives the same one — a name, a description, a rule about who may join, and a list of the repositories that belong in it. It arrived in version 0.21.0, it reaches the members of that organization who hold a seat on its plan (section 14 of the Terms), and it is the one thing in this policy that works in the other direction: the rest of these sections describe something of yours going to us, and this one describes an organization's configuration arriving on your machine — together with the record, on our servers, that you are one of the people it arrived for.

You can receive one without having asked for it. An organization can hand a workspace to everybody who joins it from then on, and an administrator can add you to one directly. So this is stated plainly rather than left to be discovered, and the App answers Why do I have this? on every shared workspace. Leave sits beside it and is never refused — not for want of a plan, a seat, a permission or a working connection.

What an administrator puts on our servers. All of it is typed by them, and none of it is taken from your machine:

Each workspace — its name, its description, its rule about who may join (open, request, or invite only), whether people joining the organization receive it automatically, and its position in the list.
Each repository attached to it — a name, one or more host/owner/name slugs, and optionally a clone address, a base branch and a subfolder. It is an address and a name: never a copy of the repository, and never anything inside one.
Who last changed the organization's catalogue, and when.

What we record about you, because a shared workspace cannot work without it. These are facts about a person, and often written by a different person:

Which of the organization's workspaces you are in, when you joined each one, and how — added automatically as a new member, joined yourself, added by somebody, added along with everybody else, or approved after you asked. Whoever added or approved you is recorded as a copy of their name rather than as a link to their account, so the answer still reads correctly after they leave the organization or delete their own.
A request to join, if you make one on a request-mode workspace — that you asked, when, whether it is waiting, taken back by you, approved, or not taken up, when it was decided, and the copied name of whoever decided. A request not taken up sets a date before which you cannot ask again (30 days unless we change it), and holding that date is the reason the record is kept rather than discarded. No reason is attached to it: the App does not record one and will not invent one.

Who can see those. Inside your organization: the people whose role lets them manage a workspace's membership — that is the roster they administer, and it is the same list they used to add you. Everybody else in the organization sees the workspaces they are allowed to see and nothing about who else is in them; a workspace set to invite only is not shown at all to somebody who is not in it. Outside your organization: nobody. Our own operator panel has no screen for any of it — the only screens that show an organization's workspaces and its rosters are in the account panel, reached by that organization's own people.

What never leaves your device for this. Asking your organization for its list carries the sign-in token already in your keychain and a number saying how much of the list you have already seen, and nothing else. In particular we are never told:

whether you cloned a repository the workspace offered you, or where you put it;
any path, checkout, worktree, session, branch, commit, terminal or hook;
any of your settings, including the ones you set on the shared workspace itself;
your code, your file contents, the prompts you exchange with an AI Agent, or its Output.

And nothing an administrator does reaches any of that either. Sharing a workspace with you gives an organization the ability to provide shared configuration and to stop providing it — nothing more. It grants no access to the machine the workspace appears on, and there is nothing for us to show them, because we do not hold it.

It is not part of Settings sync, deliberately. An organization's workspaces never enter your personal sync account (section 5b): each of your machines receives them from the organization directly, so the organization's names and repository addresses are never copied into a store that is yours alone, and turning sync off does not stop them arriving. The cost of that is stated rather than discovered: a settings override you set on a shared workspace stays on the machine you set it on, where an override on a workspace of your own would follow you.

When it contacts us, and when it does not. While you are signed in, Plexus asks whether your organization's list has changed when it starts, when its window regains focus, a couple of seconds after you change a setting, and on a timer for as long as the window is open — never more often than Check for changes every (minutes) allows, which is 15 minutes by default and can be no less than 5. It does not wait for Sync this machine, because nothing of yours is leaving. It stops entirely in three cases, each decided on your own device before any request is made: you are signed out, you belong to no organization, or no organization's plan reaches you. The moment a workspace becomes something on your machine rather than a row in a list is the moment you join one, and nothing is cloned to your disk until you press Clone and choose where it goes.

Legal basis: performance of a contract — providing the shared-workspace service to your organization and to you (Article 6(1)(b) GDPR). Where a record is about one member but written by another — who added you, who decided your request — we also rely on our legitimate interest, and the organization's, in a shared workspace being administrable at all (Article 6(1)(f) GDPR). Each of those records is the smallest one that answers who is in this, and how did they come to be: no history, no log of what anybody did with a workspace, and nothing that could be assembled into one.
Where it is stored: in the European Union, on the same infrastructure as our other managed services.
What we do not do with it: we do not use it for advertising, we do not profile you with it, we do not feed it to an AI model, and we do not sell or share it. It is joined to nothing else we hold: the anonymous analytics in section 3 and a feedback submission in section 3a carry no account identifier at all, so neither can be matched to which workspaces you are in, in either direction.
How long we keep it: see section 6, which sets out what leaving erases immediately, what a withdrawal erases, and the one record we keep on no clock of ours and would rather name than have you find.

Leaving erases how you came to have it, there and then. When you leave a workspace, or an administrator takes you out of one, the date you joined, the way you joined and the copied name of whoever added you are cleared in the same act. What remains is a marker saying that membership is over, so that your machines learn to drop the workspace instead of putting it back; it holds the pairing and a version number, and nothing anybody typed. Withdrawing a workspace does the same across the whole of it: its name, its description and the repositories attached to it are deleted at that moment, for everybody.

5e. Settings your organization manages

A managed setting is a setting value one person in an organization publishes so that every member holding a seat receives it — recommended, and set once on each member's machine as theirs to change; enforced, and applied on every machine above the member's own value with the row locked; or under evaluation, which changes nothing anywhere and only counts how many machines would change. It arrived in version 0.21.0, it reaches the members of that organization who hold a seat on its plan (section 14 of the Terms), and like section 5d it runs in the other direction: an organization's configuration arriving on your machine. Unlike section 5d, it is the one thing in this policy that can lock part of your configuration, and the one under which your machine sends something back — so both of those are stated here field by field.

You can receive one without having asked for it. A value an administrator publishes reaches every seat-holder's machine on its next check, whether or not their role grants any permission at all. The App names the organization on every managed row — Managed by Acme, with a lock, or Recommended by Acme — and lists everything an organization manages on this machine under Settings → Organizations → Managed settings. There is no Leave on a single setting; leaving the organization is what ends all of them, and it is never refused.

What an administrator puts on our servers. All of it is typed by them, and none of it is taken from your machine:

Each managed setting — which setting it is, the value, and its level (recommended, enforced, or under evaluation). Only a setting that Settings sync could carry can be managed: never one of the 15 that describe the machine (section 5b), and never a credential.
Who last changed the organization's list, and when — as a copy of the administrator's name rather than a link to their account, so it still reads correctly after they leave the organization or delete their own.

What we record about you, because a dry run cannot work without it. This is the whole of it, and it exists only while a setting is under evaluation:

One yes or no per setting under evaluation, per machine — whether the value your machine uses for that setting differs from the one proposed. It is computed on your machine and sent with the same check that fetches the organization's list. It carries no value: not the one you set, not the one you would change to, not which layer you set it at, and nothing about any other setting.
It is written against the machine that sent it — the row from your Signed-in devices list (section 5a) — and against your membership of the organization, deliberately as links rather than copies, so that signing that machine out or leaving the organization removes it with them. It is replaced each time your machine reports, and there is no history of earlier answers.

Who can see it. Nobody sees the answer from your machine. Inside your organization, the people whose role lets them view its managed settings — every member, by default — see counts: how many machines are reporting and how many would change. When fewer than five machines are on either side of that split, both numbers are withheld, because a total printed beside one hidden number would disclose the other by subtraction; the App and the account panel say fewer than 5 instead. Outside your organization: nobody. Our own operator panel has no screen for any of it — the only screens that show an organization's managed settings and its dry-run counts are in the App and the account panel, reached by that organization's own people.

your value for any setting, managed or not, nor which layer you set it at;
whether you changed a value the organization recommended, or what you changed it to;
the value of your own that an enforced setting shadows — it stays on your machine, shown to you beside the organization's, and returns when the organization stops managing the setting;
any path, checkout, worktree, session, branch, commit, terminal or hook;
your code, your file contents, the prompts you exchange with an AI Agent, or its Output.

And nothing an administrator does reaches any of that either. Managing a setting gives an organization the ability to provide a value, to insist on it, and to stop — nothing more. It grants no sight of the machine the value is applied on, and there is nothing for us to show them, because we do not hold it.

An enforced value keeps applying when we cannot be reached. The values your organization manages are held on your machine and read from there, never from a live connection, so an enforced setting keeps its last known value offline, on a plan that has lapsed and after a seat has been taken back — nothing unlocks for want of a connection. The organization's values are dropped from your machine in exactly one case: a successful check that says you are no longer in the organization, because you left or were removed. Your own values are untouched by any of it.

It is not part of Settings sync, deliberately. An organization's values never enter your personal sync account (section 5b): each of your machines receives them from the organization directly, an enforced value never enters your settings at all, and a recommended one is planted on each machine by the organization rather than carried between your machines. Turning sync off does not stop them arriving.

When it contacts us, and when it does not. While you are signed in, Plexus asks whether your organization's list has changed on the same check as section 5d — when it starts, when its window regains focus, a couple of seconds after you change a setting, and on a timer for as long as the window is open — never more often than Check for changes every (minutes) allows, which is 15 minutes by default and can be no less than 5. It does not wait for Sync this machine. It stops entirely in the same three cases, each decided on your own device before any request is made: you are signed out, you belong to no organization, or no organization's plan reaches you. The dry-run answers ride on that same check, only while a setting is under evaluation, and are never sent on a check of their own.

Legal basis: performance of a contract — providing the managed-settings service to your organization and to you (Article 6(1)(b) GDPR). For the dry-run answer, which is a record about your machine written for the organization's benefit, we also rely on our legitimate interest, and the organization's, in being able to measure a change before imposing it on everybody (Article 6(1)(f) GDPR) — and the record is the smallest that answers would this change here: one bit, per setting, replaced on each report, with no history and no value.
Where it is stored: in the European Union, on the same infrastructure as our other managed services.
What we do not do with it: we do not use it for advertising, we do not profile you with it, we do not feed it to an AI model, and we do not sell or share it. It is joined to nothing else we hold: the anonymous analytics in section 3 and a feedback submission in section 3a carry no account identifier at all, so neither can be matched to a dry-run answer or to which settings your organization manages for you, in either direction.
How long we keep it: see section 6. The short version: a dry-run answer lives exactly as long as the evaluation, a managed value until the organization withdraws it, and both go when you leave the organization.

5f. Prompts your organization publishes

An organization prompt is a prompt template one person in an organization publishes so that every member holding a seat receives it in their own template list — a name, a description, a prompt written for an AI Agent with the parts that change turned into fields, delivered as a numbered revision that the organization can replace or roll back for everybody at once. It arrived in version 0.21.0, it reaches the members of that organization who hold a seat on its plan and whose role lets them use it (section 14 of the Terms), and like sections 5d and 5e it runs in the other direction: an organization's text arriving on your machine. It is the first thing in this policy by which words somebody else wrote for an AI Agent arrive in the box you send to yours, so this section says what those words can and cannot do there. It is also the counterpart of section 5c: that one is your library, this one is the organization's, and the two never touch.

You can receive one without having asked for it. A revision an administrator publishes reaches every seat-holder's machine on its next check, provided their role grants Use prompts — which every role Plexus ships does. The App badges every organization prompt with the organization's name — Org · Acme — in the list, in the New Session picker and under Insert prompt; lists everything an organization has published to this machine under Settings → Organizations → Published prompts; and never presses return on one: a rendered prompt is typed into the terminal and left for you to read and send, exactly as with your own. There is no Leave on a single prompt; leaving the organization is what ends all of them, and it is never refused.

What an administrator puts on our servers. All of it is typed by them — or by a member who proposes a template of their own to the organization, as a copy, by that member's own act — and none of it is taken from your machine:

Each template's revisions — the name, the description, the body of the prompt in full (up to 64 KB), its fields (each one's name, label, hint, whether it is needed, its default, and for a "choose one" field the list of choices), and the revision's number. A revision is never edited once it exists; up to 20 superseded revisions of a template are kept so a roll back has somewhere to go.
Which revision is current and which is the draft, and when the current one was published.
Who proposed each revision, who published the current one, and who last changed the organization's library, and when — each as a copy of that person's name rather than a link to their account, so it still reads correctly after they leave the organization or delete their own. No user identifier is ever placed on the wire for this: the App receives a name, and only a name.

What we record about you. Nothing. Receiving an organization's prompts writes no record about you on our servers: unlike a shared workspace there is no membership of a prompt to hold, and unlike a managed setting there is no dry run. What exists is the organization's library and, beside each revision, the copied names above.

Who can see it. Inside your organization: every member whose role lets them use the library sees the current revision of each published template, and the people whose role lets them propose see the library's history — every retained revision, with the copied name of who proposed it and who published the current one. Outside your organization: nobody. An organization's administrators see their own organization's library in the account panel, and only theirs. Our own operator panel has no screen for any of it: as with your own library (section 5c), our operational screens show counts and sizes and never a template's words or its name, and the same test that refuses that for your library refuses it for an organization's.

which of the organization's prompts you ran, how often, or in which session;
what you typed into a prompt's fields, or the finished prompt — filling in and running happen entirely on your machine;
anything in your own library (section 5c) — an organization's prompts never enter it, and a template of yours reaches the organization only when you propose it there yourself;
any path, checkout, worktree, session, branch, commit, terminal or hook;
your code, your file contents, the prompts you exchange with an AI Agent, or its Output.

And nothing an administrator does reaches any of that either. Publishing a prompt gives an organization the ability to provide a piece of text, to replace it, to roll it back and to withdraw it — nothing more. It grants no sight of the machine the prompt is rendered on, and there is nothing for us to show them, because we do not hold it.

What a published prompt cannot do on your machine. A rendered prompt is typed into Claude Code's input, where a line beginning with ! runs a shell command, a line beginning with / runs a slash command, and @path attaches a file. We refuse to store, publish or roll back to a revision whose text begins with ! or / or names a file as @path (an email address passes), and the App removes those from an organization's prompt as it types it, on your machine, whatever our servers answered. Your own templates and the ones a repository commits keep all three, because you chose that content.

What arrived stays when we cannot be reached. The prompts your organization publishes are held on your machine and listed and rendered from there, never from a live connection, so every one already on the machine keeps working offline, on a plan that has lapsed and after a seat has been taken back — what a lapse ends is the arrival of the next revision. An organization's prompts are dropped from your machine in two cases only, both a definite answer from the organization rather than a failed one: a successful check that says you are no longer in the organization, or one that says your role may no longer use its prompts. Your own templates are untouched by any of it.

It is not part of Settings sync or of your prompt library, deliberately. An organization's prompts never enter your personal account (sections 5b and 5c): each of your machines receives them from the organization directly, they are never in the preview of what this machine sends, and turning sync off does not stop them arriving.

When it contacts us, and when it does not. While you are signed in, Plexus asks whether your organization's library has changed on the same check as sections 5d and 5e — when it starts, when its window regains focus, a couple of seconds after you change a setting, and on a timer for as long as the window is open — never more often than Check for changes every (minutes) allows, which is 15 minutes by default and can be no less than 5. It does not wait for Sync this machine. It stops entirely in the same three cases, each decided on your own device before any request is made: you are signed out, you belong to no organization, or no organization's plan reaches you.

Legal basis: performance of a contract — providing the organization prompt library service to your organization and to you (Article 6(1)(b) GDPR). Where a record names a person — who proposed or published a revision — it is a copied name kept for the organization's own administrators, and we also rely on our legitimate interest, and the organization's, in a shared library being administrable at all (Article 6(1)(f) GDPR): a name beside a revision, and no log of what anybody did with it.
Where it is stored: in the European Union, on the same infrastructure as our other managed services.
What we do not do with it: we do not read it, we do not use it for advertising, we do not profile you with it, we do not feed it to an AI model, and we do not sell or share it. It is joined to nothing else we hold: the anonymous analytics in section 3 and a feedback submission in section 3a carry no account identifier at all, so neither can be matched to what an organization's library holds or to which organization's prompts you receive, in either direction. As with your own library, the analytics can carry no name, no field name and no length of anything in it.
How long we keep it: on your organization's clock, not on one of ours — see section 6. The short version: a template's revisions are kept while the template exists, the oldest superseded ones beyond 20 are pruned when a new one is proposed, and deleting the template deletes its revisions at that moment.

6. How long we keep data

Data stored locally on your device remains until you delete it or uninstall the App. For the analytics described in section 3, the usage counts are never stored per install at all — they are added into shared daily totals on arrival — and the per-install rows used to count active installs are deleted every night, as soon as the day they belong to has been counted. What is left are aggregate totals per day, which hold no per-install value and which we keep for up to 400 days. We do not retain provider tokens — they live only in your keychain.

Feedback you send us (section 3a) is kept on its own clock, because it is the one thing here that is not anonymous: a screenshot or diagnostic log you attached is deleted 90 days after we receive it, and the message and any email address you gave after 12 months. A submission you ask us to delete is removed sooner.

If you accept analytics on our website (section 4b), Google Analytics keeps the event data for 2 months; the _ga cookies in your browser expire after 13 months, or at once if you choose Reject under Cookie settings.

If we offer the newsletter (section 4a), a signup that is not confirmed is deleted after 14 days; a confirmed one is kept until you unsubscribe, and unsubscribing deletes it.

A Plexus account (section 5a) is kept for as long as you keep the account, and deleted when you delete the account. There is no period after which we keep it against your wishes.

Settings sync (section 5b) is kept until you delete it, and not on any clock of ours. What we hold is the current value of each key plus the last 20 versions; the twenty-first version pushes the first one out, so the history is a rolling window and not an archive. Two things end it, and both are yours to press: Stop syncing and forget what we hold deletes every value and every version at once, and deleting your account takes all of it with the account. Switching sync off on one machine deletes nothing, and neither does cancelling a plan — section 5b gives the reason for the first and names the one case where the button is refused. One small leftover is worth naming rather than discovering: when you delete a setting, or exclude a project you had already synced, we keep a marker saying that key is gone — the key's name and nothing else — so your other machines learn to delete it too instead of putting it back. A marker is cleared once it is both more than 30 days old and more than 500 versions behind, and it holds no value, no name you typed and no path.

Two parts of it go sooner, on their own clock. An invitation you sent is deleted 90 days after it is finished with — accepted, declined, revoked, or run out — because the address on it belongs to somebody who is not our user, and in the declined case to somebody with no relationship to us at all. There is no reason to hold it once the invitation it was for is over, so we do not. And a device sign-in expires on its own after a year of not being used, whether or not you sign it out. Neither needs you to ask.

Workspaces your organization shares (section 5d) are kept on your organization's clock rather than on one of ours. A workspace's name, its description and the repositories attached to it are held until an administrator changes them or withdraws the workspace, and a withdrawal deletes them at that moment. Your membership of one is held while you are in it, and leaving or being removed erases in the same act how and by whom you came to have it. Two leftovers are worth naming rather than leaving you to discover them. The marker that remains after a departure — the one that teaches your other machines to drop the workspace instead of putting it back — is not on an automatic clock today: it is designed to be cleared once it is both more than 30 days old and more than 500 catalogue versions behind, and when that prune is running this paragraph will say so. And a request to join is not deleted when it is answered, because it is the record the date you may ask again is computed from. All three — memberships, markers and requests — hang off your membership of that organization, so they go when you leave the organization, when the organization is deleted, and when you delete your Plexus account.

Settings your organization manages (section 5e) are kept on your organization's clock too. A managed setting's value and level are held until an administrator changes them or withdraws the setting, and a withdrawal deletes the value at that moment. What remains after a withdrawal is a marker holding the setting's name and a version number — nothing anybody typed — so that your machines learn to drop the value instead of putting it back; the list of settings is a fixed catalogue of about sixty, so those markers are bounded and are not on a clock: publishing the same setting again reuses the marker. A dry-run answer is kept only while the setting it belongs to is under evaluation: it is deleted the moment that setting is published as a recommendation, enforced, or withdrawn, it is deleted when the machine that sent it is signed out, and it is deleted when you leave the organization or are removed from it, when the organization is deleted, and when you delete your Plexus account. Your own machine keeps its copy of the organization's values only until a check tells it you are no longer a member.

Prompts your organization publishes (section 5f) are kept on your organization's clock as well. A template's revisions — name, description, body and fields — are held while the template exists: each is immutable, the last 20 superseded revisions are kept beside the current one and the draft so that a roll back has somewhere to go, and older ones are pruned when a new revision is proposed. Deleting a template deletes its revisions at that moment — a deletion takes the words, not just the entry. What remains after a deletion is a marker holding the template's identifier and a version number — nothing anybody typed — so that your machines learn to drop the prompt instead of putting it back; that marker is not on an automatic clock today, and when a prune of it is running this paragraph will say so. The copied names beside a revision live and die with the revision. Everything hangs off the organization, so it all goes when the organization is deleted. Your own machine keeps its copy of the organization's prompts until a check tells it you are no longer a member, or that your role may no longer use them.

Invoices and payment records are the one exception, and the exception is the law's, not ours. Once an invoice has been issued, Dutch law requires us to keep it and the records behind it — article 52 of the Algemene wet inzake rijksbelastingen (tax administration) and article 2:10 of the Burgerlijk Wetboek (books and records) — for seven years counted from the end of the calendar year the record relates to. That period is set by statute; we cannot shorten it, and it is not a preference we could offer you a switch for. Two consequences we would rather state than let you discover:

It survives deleting your account. Deleting an account removes the account, its memberships, its seats, its device sign-ins and everything Settings sync held for it (sections 5a and 5b), but an invoice already issued is kept for the remainder of that seven-year period. What is retained is the invoice record and the billing details printed on it — who it was made out to, at what address, with which VAT number, for what and for how much. It is kept because the law requires it, not because we want it, and we do not use it for anything else.
It is minimised to what the law needs. That invoice record is all of it. The rest of the account — your login, your organization's member list, who held which seat, your invitations, your device sign-ins and everything Settings sync held — is not part of it and goes when the account goes. Where a retained invoice names you, that is because an invoice has to name who it was issued to; there is nothing we could strip from it without destroying the record we are required to keep.

We do not keep a payment instrument at any point, before or after — there is none to keep (section 5).

7. Your rights

Under the GDPR you have the right to access, rectify, erase, restrict, or object to the processing of your personal data, and the right to data portability, where these rights apply. Because Plexus is local-first, most data is under your direct control on your own device. For any personal data we process, you can exercise your rights by contacting us at timo@codedwords.com.

For feedback you have sent us, the practical route is the reference code described in section 3a. Where you sent a submission without an email address and no longer hold its code, we cannot tell which submission is yours, and Article 11(2) GDPR applies.

For analytics on our website (section 4b), withdrawing consent is Cookie settings in the footer of any page, one click, and it takes effect immediately; it does not affect what was collected before you withdrew. Because the identifier in the _ga cookie is random and we hold nothing that ties it to you, we usually cannot find your data in Google Analytics from your name or email address — write to us anyway if you want us to try.

For the newsletter (section 4a), once it is offered, the unsubscribe link in every newsletter is the erasure, and you press it yourself; write to us for anything else, such as a copy of what we hold.

For a Plexus account, most of it does not need us at all: the account panel shows you what we hold about the account, lets you correct your name and email address there, and makes erasure a button you press yourself — deleting the account deletes it (section 5a). Write to us at the address above for anything that does not cover, such as a copy of your data.

For Settings sync it needs us even less, because the App is where all of it lives. What this machine sends… shows you what would leave and what is being held back; the History button beside each of the two things it syncs opens that resource's version history — every retained version, when it was written and which of your machines wrote it; and the values themselves are the ones already on your own disk, in the App's own settings screens, readable without us. Stop syncing and forget what we hold is the erasure, and you press it yourself (section 5b). You do not have to delete your account to exercise it, you do not have to ask us, and you do not have to still be paying us — the delete is the one part of sync that keeps answering after a plan lapses, on purpose.

For a workspace your organization shares (section 5d), the part that is about you is your membership of it, and Leave is how you end it: it is in the App beside the workspace, it is never refused, and it erases how and by whom you came to have it. What the organization holds about its own workspaces and its rosters is administered by that organization's own people in the account panel, so a correction there is theirs to make; write to us at the address above if that route does not answer you, or for a copy of what we hold about your memberships.

For a setting your organization manages (section 5e), the only record about you is the yes-or-no answer your machine gives during a dry run, and it erases itself: it is gone the moment the evaluation ends, and gone the moment you sign that machine out or leave the organization. The values themselves are the organization's, administered by its own people in the App or the account panel; Settings → Organizations → Managed settings in the App shows you everything an organization manages on your machine, and the value of your own beneath an enforced one is on your own disk, readable without us.

For a prompt your organization publishes (section 5f), there is no record about you to correct or erase: receiving one writes nothing about you on our servers, and what leaves your machine for it is the sign-in token and a number. The prompts themselves are the organization's, administered by its own people in the App or the account panel — a correction there is theirs to make, and a template you proposed to the organization is, once proposed, a copy the organization holds. Settings → Organizations → Published prompts in the App shows you everything an organization has published to your machine. Write to us at the address above for a copy of the name we hold beside a revision you proposed or published, or if the organization's own route does not answer you.

One thing that button cannot erase, and we would rather say so than let you find out. Deleting the account removes the account, its organization memberships, any seat assigned to them and every device sign-in. It does not remove an invoice we have already issued: we are required to keep those, so we rely on Article 17(3)(b) GDPR — processing necessary for compliance with a legal obligation — for the seven-year period described in section 6, and for nothing beyond it. Erasure of everything else still happens immediately, and the button still works; it is the invoice alone that outlives the account, and only for as long as the law says.

You also have the right to lodge a complaint with a supervisory authority — in the Netherlands, the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl).