DOCS / HELP

Privacy

Birch runs on your computer. Your code, your repositories and Birch’s database stay there. There’s no Birch account to sign in to, and the app has no analytics. This page lists everything that leaves your machine, and when.

What leaves your machine

What	When	Where it goes
The update check	Shortly after launch, then about every six hours	Birch’s update feed
A problem report	Only when you click Send report (or answer `y` to `birch report --send`)	Birch’s private upload service
Git and your accounts	In the background while Birch is open, and when you fetch, push or sync	Your own remotes and accounts
AI features	When you use them	Anthropic with your own key, or your own agent CLI

The update check

Birch checks updates.getbirchcode.dev for a new version about five seconds after launch and then about every six hours. Every copy from Birch’s own downloads checks, including the Portable zips; only a build you compile and run yourself skips it. The check downloads a short list of releases, and the request includes:

your Birch version and the app’s package name,
your operating system and processor type (for example osx and arm64),
your release channel, stable or beta,
the name and version of the update library Birch uses.

It carries no account, device or user identifier. The feed is hosted on Cloudflare, which processes your IP address to deliver it, like any download. Details: Updates & channels.

Your own accounts

Git talks to your remotes. While Birch is open, it fetches and syncs pull requests, tasks and comments in the background with the accounts you connect (GitHub, GitLab, Azure DevOps, Jira, Linear, YouTrack), using your own tokens, and it posts to a Microsoft Teams webhook only if you set one. Anthropic API features use your key, and agent workspaces run your own agent CLI under its own account — see AI in Birch. None of this goes to Birch’s developer.

Problem reports

You decide what’s sent

A problem report is never sent automatically. Birch prepares it on your computer and lists every item it would send, with its size. Preview shows an item as it would be uploaded — the first 64 KB of it; Show in Finder… (Show in Explorer… on Windows) in the preview, or Show files under the list, opens the folder with the whole of it. Your description’s Preview shows it as typed, then the cleaned copy that goes into the issue tracker (below). You can untick any item except your description and the app details. Nothing leaves your machine until you click Send report.

Save report… writes the same file to disk instead, so you can keep it or look inside.
After Birch closes unexpectedly, or doesn’t quit normally, it only asks the next time you open it whether you’d like to send a report. To stop it asking, untick Offer to send a report after Birch closes unexpectedly in Settings → General → About & diagnostics.
From a terminal, birch report prepares the same report and lists every item; it sends only with --send, and only after you answer y at its prompt — never from a script or without a terminal to ask in.
Each report gets a random Report ID, like BR-7F3A-92CD, made for that report alone. It isn’t derived from your device or account.
The copy Birch prepares on your computer — sent or not — is deleted once it’s a day old, the next time Birch starts or prepares a report.

How to send one: Report a problem.

What a report contains

Item	What’s in it	Included
Your description	Exactly what you typed, up to 5,000 characters	Always
App and system details	Birch version and channel; which download it is (for example `osx-arm64`), whether it’s signed or a debug build, and the commit it was built from; operating system and version; processor type; .NET and UI framework versions; display language; the kind of folder Birch is installed in (for example Applications), never the path; how the report was started (by you, after a crash, or from the startup error window); when it was made (UTC); the version of Birch’s clean-up rules; and, after a crash, its signature: the error type, the signal, a fingerprint of the top stack frames and how many times it happened	Always
Setup summary	Counts as ranges (for example 6–20): repositories, worktrees, agent workspaces, open and Inbox pull requests, assigned tasks and Claude profiles; which kinds of account are connected, their status and whether they’re self-hosted; your on/off settings and choices; the AI models you picked (anything that isn’t a standard model name is sent as `custom`); whether a Teams webhook, custom editor or custom agent command is set, never what it is; the kind of shell you use (for example `zsh`, otherwise `other`); the size of Birch’s database, as a range; whether the `birch` CLI is installed. No names, paths or addresses.	Ticked
Birch logs, last 3 days	Birch’s own messages and those of the `birch` CLI, error types and where in Birch they happened, with personal details replaced or removed (how). Times are in UTC.	Ticked — unless Birch can’t read its database, as from the startup error window or the `birch` CLI: then unticked, and cut to the newest 2,000 lines per file (why)
Older logs (4–7 days)	The same, cleaned the same way	Unticked
Logs from before this version	Logs written before you updated to a Birch that can send reports. They’re cleaned by pattern matching only, so preview them before including them. Shown only during the first week after the update.	Unticked
Crash details from Birch	The error type and stack trace Birch recorded when it closed unexpectedly, for up to 10 crashes	Ticked, after a crash or if Birch crashed in the last 7 days
macOS crash reports for Birch	Up to 5 reports macOS wrote when Birch quit unexpectedly, rebuilt with device and session identifiers removed (how)	Ticked, on macOS, after a crash or if there are any from the last 7 days
Startup error	The error shown when Birch couldn’t start, with folder paths replaced	Ticked, when sent from that error window

The setup summary comes from Birch’s database, so a report sent from the startup error window or the birch CLI doesn’t include it. Every report also carries a manifest: the list of items and files, their sizes and checksums, and how many values were replaced and lines removed in each.

What a report never contains

Birch never collects these for a report. Only your description could carry them, if you type them into it yourself:

your code or file contents,
your prompts or agent chats,
commit messages,
Birch’s database, AI review reports and suggestions, Claude profiles or Claude usage data,
your Teams webhook address, your custom commands or the path to your shell,
any device or install identifier,
the key that maps placeholders back to real names.

Removed wherever Birch finds them

These can turn up inside log messages and error details, so Birch replaces or removes them wherever it finds them (how) — but no clean-up is perfect; see What this can’t promise:

your user name, computer name and network domain,
email addresses,
the addresses and logins of your accounts,
passwords, tokens and keys.

How personal details are removed

On your computer, Birch keeps a second, structured copy of its logs (7 days), so a report can be built from Birch’s own messages rather than from raw text. From it:

Birch’s own words are kept. Its log messages are fixed sentences written into Birch. The values inside them — a path, a branch, a server — are checked one by one, and anything that could identify you becomes a placeholder: ‹home›, ‹repo-1›, ‹branch-2›, ‹host-1›, ‹issue-3›. A value Birch can’t classify becomes ‹text, 24 chars›. Placeholders are numbered afresh for each report.
Birch knows what to look for. It first gathers the names that matter on your computer: your user and computer name, your home folder, the paths, names, remotes and branches of your repositories and workspaces, your git name and email, your SSH host aliases, and the servers and logins of your connected accounts. It then replaces every spelling of them it finds. Where Birch can’t open its database — the startup error window and the birch CLI — it uses the copy of that list it saved on your computer the last time it ran (scrub-literals.json, never sent), or, without one, only what it can find on your computer.
Command output is dropped. Output from git and other tools is removed. For known errors Birch keeps a short code, such as could-not-resolve-host, and counts the lines it removed. Server responses are reduced to their length.
Patterns catch the rest. Tokens and keys, email and IP addresses, web addresses, host names, folder paths and issue keys are replaced wherever they appear.
macOS crash reports are rebuilt, not copied. Birch keeps only what’s needed to find the bug — what crashed and where, the macOS version and the Mac’s model family — and drops the device identifier, boot and sleep session IDs, your user ID, process IDs and anything it doesn’t recognise. Names of third-party libraries are replaced.

Then a safety net:

Birch checks the cleaned result again for anything that still looks like your user name, a home folder, an email address, a server, or one of the paths, repository or account names it gathered. A line that fails the check is removed.
If too many of an item’s lines had to be removed (more than 2%), the item is unticked so you can preview it first. An item that can’t be cleaned safely is not included at all.
What you preview is what’s sent: Birch builds the report file once and uploads exactly those bytes.

What this can’t promise

A report is de-identified: Birch removes every personal detail it can find, but it can’t guarantee to catch everything — a project name written into a sentence, say, or an unusual value inside a third-party library’s error message. A report sent from the startup error window or the birch CLI can’t read Birch’s database, so it may know fewer of your names — none newer than Birch’s last run, or none at all — and a branch or folder name that appears on its own, outside a path, may be left in. That’s why its logs are cleaned by stricter rules, cut to the newest 2,000 lines and left unticked: preview them before you tick them, or look in the folder birch report prints before you add --logs. Your description is sent exactly as you typed it: the dialog warns you if it seems to contain a password or token, and Replace with placeholders takes paths and known names out of it.

Because placeholders keep a report’s details linked together, and your description is sent as you typed it, a report still counts as personal data under laws such as the GDPR, and it is handled that way. That’s why you can preview every item, and untick any of them, before you send.

Where a report goes

The report file is uploaded over HTTPS to Birch’s private upload service at reports.getbirchcode.dev, which runs on Cloudflare, and is stored in private Cloudflare storage, readable only with Birch’s developer’s Cloudflare credentials.
A short summary is copied into Birch’s private issue tracker on GitHub, so the problem can be tracked:
- the Report ID, and the longer ID the report file is stored under;
- the app and system details listed above, including your display language and the kind of folder Birch is installed in;
- when the report was made and received, and its size;
- every item, with whether you included it, its size, and how many values were replaced and lines removed in it;
- if Birch crashed, the crash signature: the error type, the signal, a fingerprint of the top stack frames and how many times it happened;
- a cleaned copy of your description — at most 1,000 characters, with the same kind of placeholders as the logs.
Logs, crash reports and your description as typed are never copied there.
To investigate, Birch’s developer downloads the report file to their own computer and reads it there.

Reports are never given to AI tools. Birch’s developer doesn’t paste, upload or open a report — the file or anything in it: logs, crash reports, your description, or the summary in the issue tracker — in Anthropic’s Claude or any other AI tool.

None of this is ever made public. Reports are used only to find and fix problems in Birch: never sold, never used for advertising or profiling, and never used to train AI models.

How long it’s kept

What	How long
The report file	About 90 days at most, then deleted automatically — sooner, with the issue, if the problem is fixed first
The issue in the tracker (the summary and app details)	Until the problem is fixed, then deleted
Copies Birch’s developer downloads to investigate	Deleted when the problem is fixed
The copy Birch prepares on your computer, sent or not	Deleted once it’s a day old, the next time Birch starts or prepares a report

You can have a report deleted sooner — see Contact.

Your IP address

Any upload shows your IP address to the server that receives it. Cloudflare, which runs the upload service, processes it to deliver your report, and may keep it briefly in its own security and traffic logs, under its privacy policy. Birch doesn’t store or log it. To stop one network from flooding the service, the service turns it into a one-way code that changes every day and keeps that code for about two days. The service’s own logs record only the Report ID, the report’s size and type, the Birch version and how long the upload took — never your IP address or request headers.

Who handles reports

Company	What it does	Privacy policy
Cloudflare	Runs the upload service and stores report files	Cloudflare Privacy Policy
GitHub	Hosts the private issue tracker that holds the summaries	GitHub General Privacy Statement

No one else receives reports, and no AI service does (above). Both are US companies and may process reports in the United States, under their own data-transfer safeguards. (Birch’s own AI features are a separate matter: they use your Anthropic key or your agent CLI, on your account, and never touch a problem report — see AI in Birch.)

Contact

Birch is made by Birch Innovation (Frederiksberg, Denmark), which is responsible for the problem reports you send — the data controller, in the GDPR’s terms. “Birch’s developer” on this page means Birch Innovation.

To have a report deleted, email [email protected] with its Report ID (it looks like BR-7F3A-92CD). The report file, the issue that tracks it and any copies Birch’s developer downloaded are deleted, and you get a reply when it’s done. If you’ve lost the ID, say roughly when you sent the report and from which Birch version. Questions about this page go to the same address.

Birch processes a report because you chose to send it — that is, with your consent — and you can withdraw that consent at any time by asking for the report to be deleted. Under the GDPR and similar laws you can also ask what is held about a report you sent, and complain to your data protection authority.

This website

This documentation site is separate from the app, and the Birch app contains none of this:

It uses Microsoft Clarity, which records how visitors use these pages — session recordings and heatmaps of clicks, scrolling and mouse movement — and Clarity may set cookies to recognise a returning browser. Microsoft processes this under the Microsoft Privacy Statement. A content blocker that blocks clarity.ms turns it off.
Its fonts load from Google Fonts, so Google sees your IP address when your browser fetches them.
It’s hosted on Cloudflare.