Privacy policy

brev is a single program you run on your own machine. It has no server-side component and no account: there is nothing to sign up for, and HyperClank operates no service that brev talks to. Everything brev does — capturing your mail, indexing it, searching it, showing it, sending what you write — happens on your computer against files on your disk.

The consequence is that HyperClank collects nothing about you through brev, because there is no path by which anything could reach us. We do not receive your mail, your addresses, your attachments, your search queries, your credentials, or any record that you ran the program at all.

Three locations, all of them yours, all of them ordinary files you can read, copy, back up or delete without brev running. The paths below are the Linux ones.

• The archive — ~/.local/share/brev/archive/<your address>/, one directory per account, holding mail.sqlite3 and an attachments/ store addressed by content hash. This is the mail itself: headers, bodies, addresses, labels and attachments, in a documented SQLite schema. brev's client only ever opens these files read-only.
• The sidecar — ~/.local/share/brev/state/overlay.sqlite3, everything brev records that is not mail: your read markers and stars, the current server state of each message (seen, flagged, labels, mailbox membership, trash), queued changes waiting to reach the server, drafts and the outbox, cached OAuth tokens, and small pieces of interface state.
• The configuration — ~/.config/brev/config.toml, your account list and how each one authenticates. Depending on the option you chose this file may hold an app password, an OAuth client id and client secret, or a refresh token; brev writes it chmod 600. It can instead name an environment variable or a command, so that a password manager or secret store holds the secret and brev never writes it down.

brev does not encrypt these files itself today; they are protected by your operating system's file permissions, and by full-disk encryption if you use it.

Only the mail providers you configure, and Google's OAuth endpoints when you authenticate a Gmail account that way. That is the complete list of outbound connections brev makes: the IMAP and SMTP servers named in your configuration, the Gmail API, accounts.google.com and oauth2.googleapis.com.

There is no telemetry, no analytics, no crash reporting, no licence check and no update check. brev does not contact HyperClank, and it contacts no third party of any kind that you did not configure as a mail account.

Opening an attachment or a link from inside brev hands the file or the URL to your desktop's own handler (xdg-open), which is the same thing that happens when you double-click a file. What that program then does is between you and it.

If you connect a Gmail account with OAuth, brev requests exactly one scope: https://www.googleapis.com/auth/gmail.modify. It is the narrowest single scope that covers everything a mail client has to do — reading your messages, sending mail you write, and changing labels, flags and trash state — and it does not grant permanent deletion.

brev uses that access to do three things, all of them visible to you in the client: capture your messages into the archive on your disk, apply the changes you make (archive, trash, mark as spam, star, mark read, move) back to your Gmail account, and send the mail you compose. Nothing else.

The tokens Google issues — a refresh token and the short-lived access tokens brev exchanges it for — are cached in the sidecar database on your machine and are used only to authenticate to Google. They are never transmitted anywhere else. You can revoke brev's access at any time from your Google account's third-party access page; revoking stops brev from syncing that account and leaves the mail already archived on your disk untouched. brev account rm removes the account's configuration entry and its cached token, and never deletes archived mail.

Limited Use

brev's use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

Those requirements, in Google's own words, are:

• “Limit your use of data to providing or improving user-facing features that are prominent in the requesting application's user interface”
• “Transfers of data are not allowed, except: To provide or improve your appropriate access or user-facing features that are visible and prominent in the requesting application's user interface and only with the user's consent; For security purposes (for example, investigating abuse); To comply with applicable laws; or, As part of a merger, acquisition, or sale of assets of the developer after obtaining explicit prior consent from the user.”
• “Don't allow humans to read the data, unless: You first obtained the user's affirmative agreement to view specific messages, files, or other data, with the limited exception of use cases approved by Google under additional terms applicable to the Nest Device Access program; It is necessary for security purposes (for example, investigating a bug or abuse); It is necessary to comply with applicable law; or The data (including derivations) is aggregated and used for internal operations in accordance with applicable privacy and other jurisdictional legal requirements.”

brev satisfies these by construction rather than by policy: the data never leaves your computer, so there is nobody to transfer it to and no human at HyperClank who could read it. brev transfers no Google user data to anyone, sells no data, serves no advertising, and uses no data for credit or lending purposes.

brev embeds no model and calls no model vendor. Its agent features run the command-line agent you already have — the ones named in the documentation are claude -p and codex exec — from a command template you write in config.toml. When you invoke an agent verb, brev starts that program on your machine and writes the selected message to its standard input.

If the program you configured sends what it is given to a vendor's service, then that message reaches that vendor, under your agreement with them and not ours. brev itself opens no network connection for it and knows nothing about where it goes. If you configure no agent, no message is ever handed to one.

Delete the directories named above and the data is gone; there is no copy anywhere else and no request to make of us. Because HyperClank holds none of it, a deletion or access request has nothing to act on — the files are already in your hands.

brev.software carries no third-party analytics, no advertising and no tracking scripts, and sets no tracking cookies. The web server keeps ordinary request logs, which include the requesting IP address, and they are used for operating and securing the site. If you email us, we keep the message so we can answer it.

If this policy changes, the date at the top changes with it, and a change that affects what brev does with your data ships alongside the version of brev that makes it. Every statement above describes brev as it is released today, not as it is planned.