DevBrain

Privacy Policy

Effective: October 6, 2026

This policy explains what DevBrain ("we", "us") collects when you use the DevBrain website at getdevbrain.com, the DevBrain macOS application, the command-line tool and agent plugins, and the DevBrain GitHub App (together, the "Service"), why we collect it, who sees it, and what you can do about it. It is written to be read. If anything here is unclear, ask us at team@getdevbrain.com.

DevBrain is operated by a sole proprietorship trading as DevBrain. The legal name and address of the operator are available on request at team@getdevbrain.com.

1. The short version

DevBrain coordinates coding-agent sessions across a team. To do that it stores metadata about your work: who is active, which files were touched, task and pull-request records, and, where a team turns running context on, redacted pieces of coding-agent conversations and the running summaries built from them (section 2). It does not copy your repository's files. When running context is on, it keeps the prompts you write and your agent's replies for 30 days, and these can include code or command output written into the conversation. By default it does not write to your GitHub repositories; a team admin can turn on four specific writes per repository, described in section 6. Some content is sent to a third-party AI provider to produce reviews, summaries and other results; the provider processes it under its commercial API terms, which don't allow it to train on it, and DevBrain itself keeps only what this policy lists (section 5).

2. What we collect

Account information. When you sign in with GitHub, our sign-in provider receives your GitHub login, display name, avatar and the email address on your GitHub account, and keeps them in your sign-in record. DevBrain itself stores your GitHub login with each team you belong to, so teammates can see who is who, and the date and version of the Terms you accepted by signing in. We do not display your avatar. We may use your email address to contact you about the Service: replies to your support requests, notices about the beta or changes to these documents, and occasional product updates. Every product-update email includes a way to opt out, and opting out never affects notices you need to receive about your account.

Profile. Your display name and profile picture (your GitHub avatar's address, or a picture you upload, which is reachable by anyone who has its address) are kept until you change them or delete your account.

Device tokens. Each Mac you use the Service from receives a token that identifies it. We store a hash of the token, never the token itself, along with the label given to the device and when it was last used.

Repository metadata. Through the GitHub App, for repositories your team links, we receive repository names, branch names, pull-request details: number, title, author, review state, mergeability, draft status, checks, and the list of changed file paths; and pushes to the default branch, including merges (the first line of the latest commit's message, who pushed, the files changed and the commit id). We do not store source files. Two features read file contents from GitHub without storing them: pull-request reviews fetch the pull request's diff (section 5), and, if a team enables it, the revert action reads the files it needs to build a revert pull request. One feature keeps text from your repository: the Brain feature reads the Markdown notes in a repository's .brain folder and keeps their text (up to about 12,000 characters per note) in the team's memory index, so your agents can search them. Those are notes your team writes about the repository, not source files.

Activity and presence. From the plugin running in your coding agent we receive: that a session started and ended, the repository and branch it is on, the file paths it writes to or edits (files it only reads are never reported as activity; running context, below, can name files the agent read), commits and branch checkouts made through the command-line tool, the tool in use (for example Claude Code, Cursor, or Codex), a short status phrase, claims your agent makes on paths, and the timestamps of these events. This is the signal that powers collision warnings and the team's live view. File contents the agent reads and ordinary tool output are not sent (running context, below, says exactly what is). Each time you send your agent a prompt of about 40 characters or more, the plugin removes anything that looks like a secret, then sends up to the first 500 characters to the Service in the body of a request as a search query, so your agent can be handed the team's relevant history. We do not store that fragment. If you run an out-of-date plugin that still sends it in the request address, it may appear in our hosting provider's server logs for the window in section 7; keeping the plugin updated avoids that.

Things you or your agents write into the Service. Task titles and details, decisions, broadcasts, handoffs, notes, and the free-text parts of any of these. Please do not put secrets, credentials, or personal data about other people into them.

Running context (the successor to session journals). A team admin sets it per repository. Both first-run setup choices turn it on, an admin can turn it off on the Rules page, and while it is on it applies to everyone working in that repository. When it is on, the plugin sends the Service small pieces ("slices") of your coding-agent session while you work: after a turn once about 12,000 characters of new conversation have built up (or 500 after 30 minutes), just before the agent compacts its context, when the session ends, and, at the start of your next session, whatever an earlier session that crashed had not yet sent. A slice holds your own prompts, the agent's replies, the names of the tools it used with a short label of what each touched (a file path, a web address, a search pattern or query, or the first 120 characters of a shell command), including files the agent only read, and the final reports subagents hand back to the main agent (up to 6,000 characters each, with any code blocks removed first). Other tool output, the contents of files the agent read, its hidden reasoning, and strings that look like secrets are removed on your Mac before anything is sent, and the Service removes secret-shaped strings again on arrival. Each slice is kept for 30 days and then deleted, and never leaves the team it belongs to. Every few minutes the Service sends a batch of new slices, together with the current summary of the piece of work they belong to, to the AI provider (section 5), which returns an updated running summary: the goal, where it stands, what was decided, what did not work, and what is next. We keep those summaries ("threads") and the one-line notes your agent records with the note tool as team memory, labelled with the author's GitHub login. Your teammates and their coding agents can see thread summaries and notes, and searches of team memory, by teammates in the Console and by their agents, can return short passages of raw slices (up to about 50 words per search hit) for the 30 days a slice exists. An older plugin that still sends a single end-of-session excerpt is handled the same way: the excerpt is stored as one slice under these rules.

Pull-request reviews. When the Service reviews a pull request, it fetches the pull request's diff from GitHub and sends it to the AI provider (section 5) to produce a review. We store the resulting verdict, summary and notes, not the diff.

Spec documents (optional). If you drop a document into the Specs feature, we store its text (converted from PDF, Markdown, HTML, or pasted text) so it can be broken into tasks, and we send that text, or the PDF itself for conversion, to the AI provider.

Usage and technical data. Our hosting provider keeps server logs (IP address, user agent, request path, timestamps, error details) for security and debugging. To limit abuse, a few actions (signing in, invite links, downloads, the website's email and support forms, and requests with a bad token) count requests per IP address; those counters are kept in our database for at most a day. The Service records operational error events, such as a failed GitHub webhook, in its own database, and sends error reports (the error, its stack trace, the page or request it happened on, the app version, your browser or app's version string (user agent) and language, and your account and team identifiers, never your name or email) to an error tracking provider (section 5).

Website analytics. On the public pages of the website (the home page, how it works, FAQ, support, start, terms and privacy pages) we count page views with our hosting provider's web analytics (Vercel Web Analytics). It uses no cookies and does not identify you: each view records the page address (without anything after a ? or #), the referring site, an approximate location (country, region and city), and your browser, operating system and device type. Visits are told apart by a hash of the request that the provider discards after 24 hours. Nothing is counted inside the app, the Console, sign-in, or invite pages. We do not use advertising trackers.

Apple Reminders sync (optional). If your team sets up the Reminders sync on a Mac, the DevBrain app reads the shared Apple Reminders list you choose and sends each reminder's title, notes, priority, due date, and whether it is checked off, so each one becomes a task. Mentions and tags written into a title (such as "@name" or "#tag") become the task's assignee and tags. Only that list is read.

Billing (paid plans only). If your team subscribes to a paid plan, payment is taken by our payment provider (section 5). You type your card details and billing email into the provider's checkout page; they go to the provider, not to us, and we never see or store your card number. We store the provider's customer and subscription identifiers for your team, the plan, its status, and the dates of the trial and billing month, and we report your team's extra seats and extra AI actions to the provider so it can invoice them. Teams the free beta covers are never asked for payment details.

Email addresses you give us on the website. If you leave an email address to hear about the beta, we store it with the date and the page it came from, and will use it only to contact you about DevBrain, including product updates, from which you can opt out at any time.

Support requests. If you ask a question, report a bug or request a feature on the website or in the app, we store what you wrote, your email address and name if you gave one, the date, and, from the app, the app version, update channel, team name, the outcome of the last setup run, the Console page you sent it from and the app's user-agent string, so we can answer without asking for them. We email the request to ourselves and a confirmation to you through our email provider (section 5), and we use it only to answer you and to fix what you reported.

3. What we do not collect

  • Copies of your repository's files (code quoted in a running-context conversation is the exception described in section 2). The other exceptions are a pull-request diff in transit to the AI provider and files read transiently to build a revert pull request, neither of which is stored, and two kinds of text you choose to give us: the Markdown notes in a repository's .brain folder and the spec documents you upload.
  • Command output from your agent sessions, except what is written into a running-context conversation (section 2). A subagent's final report is kept with its code blocks removed; a short line it quotes in prose may remain.
  • Readable copies of API keys or tokens.
  • Anything from repositories your team has not linked.
  • Card numbers or other payment card details. Those go to our payment provider (section 5), never to us.

4. Why we use it (legal bases)

We use the information above to provide the Service you asked for (running the coordination layer, showing your team its live state, briefing your agents), to keep it secure and working, to communicate with you about it, and to understand how it is used so we can improve it. Where the law requires a legal basis, ours is performance of our agreement with you (the Terms of Use), our legitimate interests in running and securing the Service, and, for marketing email, your consent, which can be withdrawn. Running context is a feature your team admin controls for each repository (section 2) and can turn off at any time (section 9).

5. Who we share it with

We do not sell your information, and we do not share it with other teams. Every record is scoped to one team.

We share information with these service providers, only as needed to run the Service:

  • AI provider: Anthropic (the Claude API). Receives pull-request diffs; redacted running-context slices and the current summaries; spec text and PDFs; the repository's file list, .brain note text, the task board and recently merged pull-request titles (to judge specs and place tasks); the team activity used to write the daily standup (sessions and the files they touched, tasks, pull requests, pushes to the default branch, decisions, broadcasts, handoffs, DevBrain's own actions, running summaries and GitHub logins); task braindumps; open tasks (titles, details and tags) with the repository's folder list, to predict which files a task will touch; and merged pull requests (title, author, branch, changed files, what teammates were working on in that branch and the review summary) with open tasks, to match work to tasks; and, for a branch left unmerged with no open pull request, its name, changed file paths and the first line of its commit messages, to describe what it holds; older plugins' end-of-session excerpts are sent the same way as slices. It uses them to generate reviews, running summaries, digests, task extractions and matches. The AI provider processes this under its commercial API terms, which don't allow it to train on it, and may keep it for a limited period as those terms allow. DevBrain itself keeps only what this policy lists.
  • GitHub. The GitHub App exchanges repository metadata and, where a write rule is enabled, performs the actions in section 6. App and update downloads are served from GitHub, which sees the downloader's IP address. GitHub's own privacy statement applies to your GitHub account.
  • Hosting and infrastructure. Vercel (application hosting, server logs, and cookie-free page-view counts on the public website) and Supabase (database, sign-in, and realtime). These providers process data on our behalf under their standard terms.
  • Email delivery: Resend. Sends the confirmation and our replies for support requests; receives your address, name if given, and the text of your request to do so.
  • Payments: Stripe. For teams on a paid plan: takes card payments and sends invoices. It receives what you enter at checkout (card details and billing email), your team's name, and the counts of extra seats and extra AI actions we report for invoicing. Stripe's own privacy policy applies to the payment details you give it.
  • Error tracking: Sentry. Receives error reports as described in section 2, so we can find and fix what broke.
  • Apple. The macOS app is distributed as a signed and notarised download. Apple may receive notarisation and crash information under its own policies.

We may also disclose information if required by law, to protect the rights, safety, or property of users or the public, or as part of a merger, acquisition, or sale of the Service, in which case this policy will continue to apply to the transferred data until it is updated.

6. Writing to your repositories

DevBrain reads repository metadata through its GitHub App. Writing is off by default and is enabled per repository by a team admin, one setting at a time. There are exactly four kinds of write, and no other code path in DevBrain writes to GitHub:

  • Update a pull-request branch: bring an open pull request up to date with its base branch.
  • Merge a pull request: only one that DevBrain's AI review of its latest commit marked "looks good", that is conflict-free, and that a member of your team opened from the repository itself (never a fork or an outside contributor). Depending on the setting the admin chose, a team member presses Merge in DevBrain, or DevBrain merges it automatically without a person reading it first. Your repository's own branch protection is still the final gate; if its requirements are not met, GitHub refuses the merge.
  • Open a revert pull request: a new branch and pull request that you then review.
  • Resolve brain-only conflicts: when an open pull request conflicts with its base only inside .brain/ notes, merge the base into that pull request's own branch, keeping both sides' lines. Conflicts in code are never touched.

Nothing pushes to a default branch, nothing commits outside a pull request's own branch, and every write is recorded as an event your team can see.

7. Where your data is kept, and for how long

Data is stored on servers operated by our hosting and database providers in the United States. If you use the Service from elsewhere, your data is transferred to and processed there.

  • Presence and activity: a session shows as active for 30 minutes after its last signal, is then closed, and remains as history for as long as the repository is linked. Activity records are not purged on a schedule today.
  • Claims: last 24 hours by default and at most 72; an expired or released claim remains as a record.
  • Completed tasks: deleted 72 hours after completion. Handoffs: deleted 72 hours after they are picked up, or 7 days after they are left if nobody picks them up.
  • Legacy journal excerpts (older plugins): stored as a running-context slice and covered by the line below; anything still in the old processing queue is deleted when processed, after 24 hours of failed attempts, and in any case within 7 days.
  • Running context (the successor to session journals): the redacted session slices the plugin sends while you work are deleted after 30 days, while the rolling work summaries (threads) built from them and one-line notes are kept as team memory like journals. Slices are also removed from the search index when they are deleted.
  • Journals, decisions, broadcasts, and pull-request review results: kept as team memory until the repository is deleted from DevBrain or the team is deleted. Unlinking a repository alone keeps them (section 9).
  • Repository metadata and pull-request records: kept while the repository is linked. Unlinking marks the repository inactive and stops updates; deleting it removes them, leaving one line in your team's feed that says it was deleted and by whom.
  • Spec documents and the tasks extracted from them, the team memory index (including .brain notes), and standup digests: kept until you delete the spec, delete the repository from DevBrain, or delete the team. There is no scheduled purge for them.
  • Account information: kept while you have an account.
  • Server logs: kept by our hosting provider for a short rolling window, never more than 30 days.
  • Website email sign-ups: until you ask us to remove you.
  • Billing records: the plan, status and provider identifiers are kept while the team exists; invoices and payment records are kept by the payment provider as tax and accounting law requires.
  • Apple Reminders tasks: like any other task (deleted 72 hours after completion).
  • Rate-limit counters (IP addresses): at most one day.
  • Webhook delivery records (a fingerprint of each GitHub event, used to refuse duplicates): 30 days.
  • Alert logs (operational alerts about your team, such as a failed sync): kept until the team is deleted.
  • Support requests: until answered and no longer needed to fix what you reported, or until you ask us to remove them.
  • Error reports: kept by the error tracking provider for 90 days.
  • Teams on the free beta that have not subscribed to a paid plan 30 days after the beta ends: deleted with all their data.
  • Deleted teams: When a team is deleted we keep only a minimal record that it was deleted (its id and the time), with no team content. The record of a GitHub App installation stays until the app is uninstalled from GitHub.
  • Backups: our database provider takes a daily backup of the whole database for disaster recovery and keeps each one for 7 days. We do not keep separate backups of our own. Deleted data may persist in a provider backup for up to 7 days and is never restored selectively.

8. Security

Device tokens are stored only as hashes. Every record is scoped to one team and access is checked on every request. Data is encrypted in transit and at rest by our providers. Access to production data is limited to the people who operate the Service and is used only to run and support it. No system is perfectly secure; if we learn of a breach affecting your data we will tell you without undue delay and, where required, notify the relevant authorities.

If you find a security issue, please email team@getdevbrain.com with "security" in the subject line before disclosing it publicly.

9. Your controls and rights

At any time you can, from the app, the Console, or the website's Account page:

  • revoke any device token;
  • unlink a repository, which stops all new data flow for it immediately and keeps its history until you delete the repository from DevBrain;
  • delete a repository from DevBrain, which removes every record for it apart from one line in the team's feed noting the deletion;
  • leave a team, or, as its owner, delete the team, which removes all of its data;
  • delete your account from the website's Account page, which removes your memberships, device tokens and sessions and deletes any team you were the only member of; support requests you sent keep their text without the link to your account. Content you added to teams that still exist (activity history, notes, decisions, summaries, and running-context slices until they expire) stays with that team, labelled with your GitHub login; email us to have it removed or anonymised;
  • turn running context off for a repository (team admins), which stops slices and notes being collected for it from that moment; slices already stored still age out after 30 days, and threads and notes already written stay as team memory unless the repository or team is deleted;
  • disable any write rule (team admins).

You can also ask us for a copy of the personal data we hold about you, to correct it, or to delete it, by emailing team@getdevbrain.com. We will act on a verified request within 30 days. Deleting a team removes its coordination data, memory, and repository records. Some records may be kept where the law requires it or where we need them to resolve a dispute.

If you are in the European Economic Area, the United Kingdom, or another jurisdiction with data-protection law, you have the rights that law gives you, including to access, correct, delete, restrict, or object to processing, to data portability, to withdraw consent, and to complain to your supervisory authority. Where we rely on consent, withdrawing it does not affect processing before the withdrawal. If you are a California resident, you have the rights under the CCPA/CPRA to know, delete, and correct your personal information and not to be discriminated against for exercising them; we do not sell or share personal information for cross-context behavioural advertising.

10. Children

The Service is not directed at children and we do not knowingly collect information from anyone under 18 (or the age of majority where they live). If you believe we have, tell us and we will delete it.

11. Cookies

The website and app use only first-party cookies: the ones our sign-in provider needs to keep you signed in, a handful that remember your active team, your last repository, where to return after sign-in, a one-time notice, which app build you use, and a five-minute marker that a recent sign-in check succeeded, and, for two minutes after you create a device token, the token itself so the app can show it to you once. It is never stored on our servers in readable form. We do not use advertising or cross-site tracking cookies, and our website analytics use no cookies at all (section 2). The website, the app and the Console also keep a few display preferences in your browser's local storage (such as the theme, your notification settings, and whether you have seen the beta pop-up); they never leave your device.

12. Changes to this policy

We may update this policy as the Service changes. If a change is material, we will give notice through the app, the website, or by email where we have one, at least 14 days before it takes effect. The effective date at the top tells you when it last changed.

13. Contact

team@getdevbrain.com