Your information.

What this notice covers#

In shortThe website, the waitlist, email with us, what the open-source engine keeps on your machine, and Cloud accounts.

This notice covers getarbor.dev, its two signup lists (the Arbor Cloud waitlist and the list for fix pull requests) and email you send us. It also explains what the open-source Arbor CLI and MCP bridge keep on your own machine.

The “Cloud accounts” part of this notice describes what Cloud collects when you sign in and use it.

Visiting the website#

In shortAmazon Web Services (AWS) serves the pages. We load nothing from other sites, set no cookies and give you no visitor ID.

AWS hosts the site, in its Tokyo region. Like any web host, it receives your IP address, browser details and each page you request.

Pages load no third-party scripts, fonts, images or videos. Fonts and logos come from getarbor.dev itself. Links to GitHub, npm and other sites load nothing until you click them.

Our code sets no cookies on these pages and gives you no visitor ID. We use no analytics service, advertising or session replay, and no error-tracking script runs in your browser.

Docs search runs in your browser. The sample explorer shows a recorded example bundled with the site; it doesn't read your files or connect to GitHub.

What your browser stores#

In shortOnly your light or dark theme choice, and it never leaves your browser.

If you click the theme toggle, we save light or dark under arbor-theme in local storage. That is the only thing the public pages store in your browser, and it never leaves it. Clearing this site's data removes it.

Until September 23, 2026, this site also set a random visitor ID under arbor_visitor_id in local storage and used it to count page views, as described under The earlier Cloud and website. The site no longer sets or reads it. If your browser still has the ID, clearing this site's data removes it.

Joining the waitlist#

In shortYour email, when you joined, which link brought you and which list you joined, used only to email you about that list.

The form sends your email address. It also sends the page that linked you here, if your browser shares it, and the utm_source tag from the link you followed, if there is one. We use those two to see which links bring people to the waitlist.

There are two lists. The Cloud waitlist form sends nothing more. The form for fix pull requests, which Arbor is building to move code off retiring AI models, also sends the name of that list. The signup endpoint accepts no other list.

We store your address in lowercase with the time you joined and the lists you joined. The linking page is cut to 600 characters and the tag to 200. Before the fix pull request list was added, the signup endpoint also accepted a free-text use-case note of up to 1,000 characters. If one was sent with your signup, it stays with your entry.

We use your address only to email you about the lists you joined: Cloud access, fix pull requests, or both. Each address is stored once. If you join the other list later, we add that list to your entry and keep the linking page and tag from your first signup. If it's already on the list you chose, we change nothing and send no second email, and the form says you're already on the list, so anyone who types your address can learn that it's there.

To slow repeated attempts, the server instance that handles your signup keeps a keyed hash of your IP address in its memory and allows 10 attempts a minute. The key is random, made when that instance starts, and never stored. Your IP address is never written to our database.

If saving fails, our log records only that it failed, not what you typed.

To leave a list, email support@getarbor.dev from the address you joined with and say which one. We take your address off that list and keep it on the other; once it's on neither, we delete your entry. If you don't say which, we delete it.

Emails between us#

In shortAt most one confirmation for each list you join, and our replies to what you send us.

Confirmation emails go out through Resend from updates@getarbor.dev. We send one when you first join a list, never for a repeat signup. It has no confirmation link and asks nothing of you.

If the email can't be sent, your signup stays saved.

When you write to support@getarbor.dev, we receive your address and your message, and use them to reply. Please don't send passwords, tokens or private source code.

Services behind the website#

In shortAWS, our database host, Resend and Sentry, with exactly what each one receives.

AWS runs the website and receives every request to it, including what you submit to the waitlist.

Our database hosting provider runs the PostgreSQL database that stores the waitlist. The website connects to it over an encrypted connection.

Resend receives your address and the confirmation message to deliver.

Sentry receives error reports from the website's server. Request bodies are never captured, and cookies and authorization headers are removed first, so the address you type into the waitlist isn't sent. Error reports can still carry the page address and browser details. Performance traces sample 1 in 10 requests and can record your IP address.

Our security policy can also ask your browser to send Sentry a short report when it blocks something on a page. That is switched off today. If we switch it on, the report will name the page, the page you came from and what was blocked, and because your browser sends it straight to Sentry, Sentry will also see your IP address and browser details.

The Arbor CLI and MCP bridge#

In shortThey send nothing to us: no telemetry, no crash reports, no update checks, no uploaded code.

The open-source engine runs on your computer and needs no account. The CLI and MCP bridge send no telemetry, crash reports or update checks, and nothing in them uploads your code. They run git only for local commands and never fetch, pull or push.

The optional visualizer, started by arbor viz or arbor bridge --viz, is a separate app. It can download fonts from Google when it starts.

What the engine hands to a coding agent, through MCP tools or the hooks that arbor hook claude installs, goes to that agent and its model provider under their own policies.

arbor bridge, which your MCP client starts, opens WebSocket servers on 127.0.0.1, ports 7433 and 8081. arbor viz opens the same two, and arbor serve opens one on port 7432 by default. They listen only on your own machine, and they send nothing to us.

The arbor serve --headless mode listens on every network interface with no sign-in. Anyone who can reach that port can query your graph, so use it only on a network you trust.

Installing downloads Arbor from GitHub, npm or crates.io. Those services see your IP address and apply their own policies.

Our GitHub Actions run Arbor inside your own CI. On pull requests they post the report as a comment by default, using your workflow's GitHub token. The report goes to your repository, not to us.

What .arbor/ keeps#

In shortYour code graph and, if you use receipts, your prompts, in a folder inside your project that Arbor keeps out of git.

Running arbor setup creates a .arbor/ folder in your project. It holds config.json with your languages and ignore patterns, the graph in graph.json and graph.bin, a note of the commit and Arbor version that built it, and a per-file cache.

The graph records names, file paths, line numbers, the names each symbol calls, signatures and doc comments. A signature can be the first line of a definition, so a one-line function may be stored whole. Longer function bodies are not stored.

If you use receipts, .arbor/receipts/ keeps one file for each agent turn that changes files: the first 2,000 characters of your prompt, what changed and what the change reaches. Each receipt is also shown in Claude Code.

To build receipts, Arbor snapshots your working tree into your repository's .git folder, including untracked files that aren't gitignored. Arbor never deletes these snapshots. Git can remove them in its routine cleanup (git gc) once they are about two weeks old. Nothing is pushed.

Since version 3.0.4, Arbor gives .arbor/ its own .gitignore, so git leaves your graph and your prompts out. Version 3.0.3 doesn't: with it, add .arbor/ to your .gitignore yourself, or running git add -A and committing will include them. Anything from .arbor/ that was already committed stays in your repository until you remove it with git rm -r --cached .arbor.

When this part applies#

In shortThis part applies once you sign in to Cloud, and describes it as it runs.

This part applies once you sign in to Cloud. It describes Cloud as it runs today. If that changes, we'll update it and the date at the top.

Cloud builds its graph with the same open-source engine, v3.0.5, on our servers. A run starts when a workspace member asks for one, or when a pull request in a repository with checks turned on gets a new commit.

Signing in with GitHub#

In shortTwo scopes, read:user and user:email. We keep your GitHub ID, username, avatar and public email.

You sign in with GitHub. We ask for two scopes, read:user and user:email. They let us read your profile and email addresses, not your repositories.

GitHub shares your public profile and, if your email is private, your list of email addresses.

The website keeps your numeric GitHub ID, username, display name, avatar and one email address (your public one, or your primary one if none is public), with your GitHub sign-in token, in an encrypted session cookie. The token isn't exposed to the page. The cookie expires 30 days after you last use Cloud, or when you sign out.

When you sign in, the website passes the token to our API, which reads your GitHub profile with it and doesn't store it. If that hand-off fails, the website tries again later with the same token.

Our API stores your GitHub ID, username, avatar URL, when you first signed in, and the email on your public GitHub profile if you show one. It doesn't store your display name or a private email. Your username and avatar update at each sign-in. The email is kept when GitHub returns none, so if you hide it on GitHub, ask us to delete our copy.

The sign-in token is never used to read your code. Repository access goes through the GitHub App.

Repository access#

In shortThrough Arbor's GitHub App, with a fresh read-only token for one repository that lives in memory for under an hour.

To connect a repository, you or an organization owner install Arbor's GitHub App and select it. GitHub shows the permissions on its install screen.

From the installation we store its ID, the account it belongs to, the GitHub ID of whoever installed it, and each selected repository's ID, owner, name, default branch and whether it's private.

Each time Cloud reads a repository, it asks GitHub for a fresh token limited to that one repository, with read-only access to contents, metadata and pull requests. The token stays in memory, and GitHub expires it within an hour. We don't write it to a database, a file or our logs.

With checks on for a repository, Cloud writes its “Arbor impact” check with a separate token limited to checks on that one repository. It can create and update its own check runs and nothing else.

Before each run, and each time someone opens a report, we ask GitHub whether that person can still read the repository. If not, the report stays closed to them.

Removing a repository from the App disconnects it from your workspaces. Uninstalling the App stops our access. Neither deletes existing reports; they stay closed until they expire.

Analyzing a pull request#

In shortA temporary shallow copy, analyzed in a separate process and deleted when the run ends. OSV sees package names, not code.

When a member starts a run, or a pull request in a repository with checks on gets a new commit, we read the pull request from GitHub and pin its exact base and head commits. From GitHub's comparison we keep only the changed file paths and line ranges, not the diff text. Pull requests too large for GitHub's comparison are refused.

We then make a shallow copy of the repository at the head commit, from github.com, in a temporary folder on our API server. Git hooks and submodules are switched off, and no build scripts or package installs run. Checkouts over our size limits are refused. Within them, source files beyond the number we analyze, or larger than we parse, are skipped, and the report says its graph is partial.

A separate worker process builds the graph and is stopped if it runs too long. When the run ends, the folder is deleted. If the server itself is killed mid-run, leftover folders older than 20 minutes are deleted before the next run.

To check dependencies for known vulnerabilities, we send package names, versions and ecosystems from Cargo.lock and npm lockfiles to the public OSV database at api.osv.dev, then fetch each matching advisory from OSV by its ID. This happens for private repositories too, including private packages on the public npm registry.

When a pull request changes one of those lockfiles, we also fetch that lockfile as it was at the pull request's base commit, from github.com into the same temporary copy, to tell which advisories the pull request brought in. Nothing else from the base commit is read.

Packages the lockfile records as coming from git, a local path or another registry are not sent. An npm entry that doesn't record where it came from is sent, so the name of a private package can reach OSV.

Cloud sends no code, report or repository details to an AI model.

Reports and run records#

In shortReports hold no source code or diff text and last at most 90 days. A record of each run stays.

A report holds no source code or diff text. It holds the repository name, pull request number, branch names and commit IDs, and the changed file paths with a risk result for each.

It also holds details derived from your code. It lists up to 300 of the repository's most connected symbols by name, file and kind, with the links between them. It shows call paths from the change to entry points, dependency findings from OSV, and the engine version.

Each report is stored once in our database. How long it's kept is fixed when the run is accepted and counts from when the report is saved. It is never more than 90 days. After that nobody can open it, and a cleanup job deletes it shortly afterwards, with its shared views and review assignments.

Only current members of the workspace can open a report, and only while GitHub confirms they can read the repository.

We keep a record of every run after its report is gone: repository name, pull request number, commit IDs, status, plan, times and who asked for it. It is how we count usage, and it has no set expiry yet.

Workspaces and invitations#

In shortInvitations go to a GitHub username, never by email, and every membership change is logged.

Each new account gets a workspace called My workspace. We store workspace names, the owner, each member's role (owner, admin, member or viewer) and personal settings such as theme, density, saved views and preferred tool.

To invite someone, you enter their GitHub username. We look it up through GitHub's public API and store their numeric ID and username, your ID and the role. They don't need an Arbor account yet.

We send no invitation email. The invitation waits in the person's Arbor inbox until they sign in with that GitHub account, and it expires after 7 days. We keep accepted, declined, expired and revoked invitations as history.

Members can see each other's GitHub username, ID and role, and the workspace's recent invitations.

Every membership change is logged: who did what to whom, by GitHub ID, with the roles involved. The log is append-only, and it stays after members leave or delete their accounts.

Shared report views and review assignments record who made them. They are deleted with the report.

Payments#

In shortRazorpay takes the payment and we never see your full card number.

You pay in Razorpay's checkout window, which Razorpay runs on top of our page with its own script. Razorpay handles what you enter there under its own privacy policy.

We send Razorpay the plan and our own reference number, not your name, email or GitHub details.

We never see your full card number, and we don't store card, bank or UPI details. When we confirm a payment, Razorpay's records can include the contact details and payment method you gave Razorpay; we keep none of them.

We keep what Razorpay confirms: subscription, invoice and payment IDs, the plan, amount and currency, the billing period and payment time, and any refund or dispute. We also record the GitHub ID of whoever started or stopped the subscription. These records stay after account deletion.

Services and logs#

In shortGitHub, our API host, our database host, OSV, Razorpay and Sentry, and what our own logs record.

GitHub handles sign-in, repository access and invitation lookups. Our API runs on Amazon Web Services (AWS), in its Tokyo region. Our database hosting provider stores accounts, workspaces, run records and reports. OSV receives package names and versions. Razorpay handles payments.

Sentry receives crash reports from our API when we switch it on. Before sending, we strip your email and IP address, known token formats, cookies and request bodies.

Our API logs each sign-in with your GitHub username and ID. When a client sends too many requests, the log records its GitHub ID, or its IP address if it isn't signed in. Known token and key formats are redacted from logs, and analysis workers never log repository contents.

Cloud sends no email of its own.

In your browser#

In shortA sign-in cookie, plus run and install state in session storage. Receipt files you open stay in your browser.

Signing in sets an encrypted session cookie, plus cookies that protect the sign-in step.

When you start a run, session storage keeps its request ID, repository ID, pull request number and commits, filed under your GitHub ID and workspace ID, so a reload can recover it. When you leave for GitHub to install the App, it keeps the repository name, your GitHub ID and the workspace ID for up to an hour.

Receipt files you open in Cloud are read in your browser and kept in its local storage under arbor-receipts-v1. They are not uploaded. “Remove from this browser” clears them.

The sign-in screen also remembers your theme and whether you paused its animation, in local storage.

If you install Cloud as an app, its offline cache holds only a generic offline page.

Export and deletion#

In shortEmail us to get a copy or delete your account. Some records keep your GitHub ID afterwards, and we list them.

Email support@getarbor.dev to get a copy of your account data or to delete your account. Include your GitHub username. We need to confirm the request comes from that GitHub account before we act.

Deleting removes your account record, memberships, settings and repository access. Invitations waiting for you are revoked. You leave other workspaces, and your queued runs there are canceled. Workspaces that only you belong to are archived, and their reports stay until they expire.

We can't delete an account that owns a workspace with other members, or that owns a paid subscription we haven't confirmed as stopped. Remove the other members or stop renewal first.

Some records keep your numeric GitHub ID after deletion: the trial record, so deleting can't restart a trial; run records; invitation history; the membership log; shared views and reviews you made; payment records; your archived workspaces; and a note of each deletion attempt. Where a record names you, such as an invitation or a repository under your personal GitHub account, it also keeps your GitHub username.

Deleting your Arbor account changes nothing on GitHub. To revoke sign-in or uninstall the App, use the Applications page in your GitHub settings.

Deletion doesn't reach copies our providers may hold in logs or backups. Those expire on the providers' own schedules.

How long we keep things#

In shortWaitlist entries until you ask, code copies until the run ends, reports up to 90 days.

Waitlist entries have no set expiry. They stay until you ask us to remove them.

Rate-limit hashes stop counting after a minute and are cleared from memory by a later signup attempt, or when that server instance stops. Your theme choice stays in your browser until you clear this site's data.

Repository tokens live only in memory and expire within an hour. Code copies are deleted when the run ends. Reports expire within 90 days. The sign-in cookie expires 30 days after you last use Cloud. Account, workspace, trial, App installation and repository, run, invitation, membership-log, deletion-log and payment records have no set expiry yet.

Our own server logs on AWS are deleted after 30 days. Logs held by Resend and Sentry follow those services' settings.

Your choices and rights#

In shortAsk for a copy, a correction or deletion, from the address or GitHub account in question.

To leave a list, email support@getarbor.dev from the address you joined with and say which one. We take your address off that list, and delete your entry once it's on neither list or if you don't say which. If someone added your address without asking, write from that address and we'll remove it.

You can also ask for a copy of what we hold about you, or ask us to correct or delete it. For the waitlist, write from the address in question. Include your GitHub username with a Cloud request. We need to confirm a request is yours before we act on it.

Depending on where you live, you may also have the right to object to or restrict a use of your information, or to complain to a data protection authority. You don't need to contact us first, but if you do, we'll try to help.

The earlier Cloud and website#

In shortThe first Cloud closed on September 23, 2026. Closing it didn't delete its data; ask us about yours.

The earlier Cloud was a GitHub App that posted change-analysis comments on pull requests. It has been closed since September 23, 2026. Closing it didn't delete its data.

That data can include your GitHub account details and plan, App installations and repositories, analyses, and payment records if you paid. Email support@getarbor.dev to ask what we hold or to have it deleted.

Where AI summaries were switched on, the earlier Cloud sent facts from each analysis, such as file and function names and counts, to Groq to write a short summary for its comment. It did not send source code.

If you installed the earlier App, it stays installed until you remove it in your GitHub settings.

Until September 23, 2026, the website also counted page views, except from browsers that sent Do Not Track. Each record holds a keyed hash of the visitor ID rather than the ID itself, the page, the referring site's hostname, the page title, window size, browser, device type, country and the time. It holds no IP address. Stopping the counter didn't delete those records. To have yours deleted, email support@getarbor.dev with the arbor_visitor_id value from your browser, if it's still there.

Changes to this notice#

In shortThe date at the top marks this version.

The date at the top marks this version. When what we collect changes, we update this page and that date.