01How it works
The server delivers the mail, it doesn’t read it
Encryption and decryption happen only on your computer, phone and watch. The server never gets the key, so it can’t read the content. It isn’t that we promise not to look; we can’t.
Why a server at all
Your computer and phone are usually on different networks: you’re out, and the computer is at home or at the office. The one place both can reach is a server on the internet. We call it the Relay, and it runs on Cloudflare.
The Relay does three things: it passes changes on your computer to your phone, queues your phone’s commands for the computer, and keeps the latest state while the computer is offline. None of that requires knowing what’s inside the data, only which computer and task it belongs to and when it was updated. So that’s all we let it know.
How the key gets to your phone
Your set of devices (computer, phone, watch) shares one random 256-bit key, the group key. The hard part is handing it to a new device without the server in the middle getting a copy. Our answer is your computer’s screen: you point your phone at it, and the server has no way into that channel.
First pairing
- The computer creates a one-time key pairWhen you choose “Pair a Phone…”, BotBus generates a single-use X25519 key pair. The private key stays in the computer’s keychain; the public key goes into the QR code on screen.
- The phone scans it and creates the group keyThe phone generates the group key locally and seals it into a “key envelope” using the public key from the QR code. Only the computer’s one-time private key can open it.
- The envelope travels through the serverThe server delivers it, but it has never seen the public key in the QR code, so it can’t compute the shared secret needed to open the envelope.
- The computer opens it and deletes the one-time keyThe computer stores the group key in its keychain and immediately deletes the one-time private key. From then on, everything between your devices is encrypted with the group key.
- The server can’t impersonate your computer. That would mean swapping the public key, and the public key only ever appears on your computer’s screen. After pairing, the phone also checks that the computer the server says it paired with is the one named in the QR code, and discards the pairing if they differ.
- Adding another phone: the invite QR code shown by an already-paired computer carries the group key directly.
- Adding another computer: an already-paired phone scans the new computer’s QR code and seals the existing group key in an envelope, as above.
- Apple Watch: syncs from the paired iPhone over WatchConnectivity, which the system encrypts. It doesn’t go through the server.
- You can’t pair by typing a 6-digit code. Six digits can’t hold a key, so you either scan the QR code or paste the link from “Copy Pairing Link” on your computer into your phone. That’s on purpose: pairing has to happen in front of your computer.
The pairing QR code and pairing link are the key itself. Only scan them with your own phone and only paste them into your own phone; don’t screenshot them or send them in a chat. A pairing code expires after 5 minutes and works once.
What’s encrypted, and what the server can see
Encrypted: unreadable to the server
- Task titles, status and latest output
- Project names and paths, uncommitted git changes
- Full conversation history
- Messages, images and files you send
- Screenshots, files and videos your agents share back
- Approval requests (the command to run, the files to change) and your answers
- Every command your phone sends: new task, follow-up, approve, interrupt. Even which kind of command it is.
- Computer and phone names
- Notification titles and text
- Remote-control screens, clicks and keystrokes
Visible to the server (needed to relay)
- The pairing ID and each device’s ID
- Whether a computer is online, and when it was last seen
- Task IDs and update times. IDs carry a source prefix (such as
codex:), which reveals which agent a task comes from - Command IDs and when they were sent
- The notification category: needs approval, needs a reply, done, failed
- The size of each piece of ciphertext
- The IP address your devices connect from (as with any online service)
That’s enough for the server to deliver data to the right place and keep the most recent tasks, but not enough to piece together what you’re doing. Here’s one follow-up command on each side:
{
"id": "6b1c2d3e-…",
"createdAt": "2026-09-17T08:06:00Z",
"kind": "followUp",
"followUp": {
"taskId": "codex:01a0ab79-…",
"prompt": "Also switch the button to the theme color"
}
}{
"id": "6b1c2d3e-…",
"agentId": "hV3nQ7pLxK2mR8sTfW4bZQ",
"createdAt": "2026-09-17T08:06:00Z",
"sealed": "AQQ021RNmIp90_5yD0EsY4kuQD9…"
}The cryptography
| Purpose | Algorithm |
|---|---|
| Encrypting content | AES-256-GCM, with a fresh random nonce for every piece of ciphertext |
| Key exchange during pairing | X25519, with a new one-time key pair each time you pair |
| Deriving sub-keys | HKDF-SHA256 |
- Only public, well-studied standard algorithms, using each platform’s built-in implementation (CryptoKit on Apple devices). We don’t invent our own cryptography.
- The same content encrypts differently every time. The server can’t guess what you sent by comparing ciphertext, or even tell whether two messages are the same.
- It can’t be altered or moved. GCM has built-in integrity checks, so changing a single byte makes it undecryptable. Each piece of ciphertext is also bound to its place: which computer, which task, which command. If the server moves task A’s ciphertext under task B, or forwards a command meant for one computer to another, decryption fails. After decrypting, devices also check that the IDs and timestamps inside match the ones outside.
- Different jobs, different keys. Separate sub-keys for content, notifications and remote control are derived from the group key. The iPhone system extension that displays notifications only ever gets the notification key.
- Files are ciphertext too. Images, files and videos are uploaded as encrypted bytes. To the server they are all just unknown binary data; it can’t even see the file type. Attachment IDs are computed with a key that exists only on your computer, so the server can’t take a known image, compute its ID, and check whether you’ve uploaded it.
Notifications
Push notifications go through Apple’s push service (APNs). All the server hands Apple is a fixed phrase, such as “A task is waiting for your approval”, plus a piece of ciphertext.
When your iPhone receives it, it decrypts the ciphertext on the device with the notification key and swaps in the real computer name, task title and text before showing it to you. So both Apple and our server only ever see that fixed phrase. On Apple Watch, notifications stay on the fixed phrase; when you open the app, content is decrypted on the watch as usual.
Remote control
Remote control lets you see your computer’s screen from your phone, click and type, possibly including a password. It’s the most sensitive path, so it gets the most protection:
- Every frame, click and keystroke is encrypted, with a separate remote-control key.
- The page that shows the screen ships inside the app instead of loading from the server. The server gets no chance to slip in code that could carry the key away.
- Every input carries its target and a timestamp. If the server replays an old input, or turns “type text” into “click”, the computer rejects it.
- A computer without a group key doesn’t turn on remote control at all.
What the server stores, and for how long
| Data | Stored as | Kept for |
|---|---|---|
| Latest state of tasks, computers and projects | Ciphertext | While paired; cleared after 30 days with no device connecting |
| Commands waiting for the computer | Ciphertext | 10 minutes |
| Conversations you open | Ciphertext | Served to your phone for 5 minutes |
| Images, files and videos | Ciphertext | 7 days |
| Device credentials | Only a hash, never the original | While paired |
Even if the server’s storage leaked in full, all anyone would get is the ciphertext in this table and the metadata listed above. The original task records on your computer are kept by each agent and never live on the server. The iPhone app also uses Firebase Analytics to record a fixed set of pairing and usage events, without task content, project paths or pairing codes; see the Privacy Policy.
02What you can do
Check it yourself
Encryption needs no setup; it’s on as soon as you pair. Here’s what you can confirm with your own eyes, and the limits we want you to know about up front.
Check the key fingerprint
The fingerprint is a short digest of the group key: 8 hexadecimal characters. If two devices show the same fingerprint, they hold the same key and nobody swapped it in between.
- On your computerBotBus menu → “Pair Another Phone…”. The pairing window shows “End-to-end encrypted · Key fingerprint” followed by 8 characters.
- On your phoneSettings → Connection → End-to-end encrypted. The same characters appear on the right.
The fingerprint is computed from the key and can’t be turned back into it, so it’s fine to show it to someone.
What encryption can’t protect
- Someone holding your unlocked deviceThe key lives in the system keychain, protected by your device’s lock. But anyone with your unlocked computer or phone can see everything BotBus shows, just as they could read your messaging apps.
- Your agent’s own model providerWhat we encrypt is the path between your computer and your phone. Agents like Codex and Claude Code send your conversations to their own model providers (for example OpenAI or Anthropic) anyway. The model request is made by the agent on your computer. The Relay cannot read its plaintext, but BotBus encryption does not cover that request. Before starting a task from your phone or watch, the app asks you to verify the actual provider and explicitly agree; see AI services and permission.
- Developer previewsWhen you use
botbusto share a local web page from your computer to your phone, the browser has to request the page’s resources directly, so the server has to proxy them. Previews aren’t end-to-end encrypted, and are reachable only while you’re sharing. Remote control is different: it is encrypted. - MetadataThe server can see the IDs, times, online status and data sizes listed above. Any relay service needs these; we’ve kept them to the minimum needed to deliver data.
- The old key on a removed phoneWhen you remove a phone in your computer’s settings, its credentials are revoked at once and the server stops giving it any data. The group key it received earlier isn’t replaced automatically, though. For a completely new key, choose “Unpair” in your phone’s settings and scan again; a new pairing creates a brand-new group key.
- The worst the server can dois not deliver, deliver late, or show you an older state you’ve already seen. It can’t forge content, and it can’t read it.
End-to-end encryption means you don’t have to trust the server. What you do trust is the BotBus app on your own devices. The Mac app is notarized by Apple and published on this website; the phone app is distributed through Apple’s channels.
FAQ
Can you see my code or conversations?
No. The server only holds ciphertext, and the key only lives on your devices. Our engineers, Cloudflare, or anyone who gets hold of the server’s data would see a string of gibberish like the one above.
What if someone demands your data?
All we could hand over is ciphertext and the metadata listed above. We don’t have the key, so we can’t decrypt anything first.
What if I lose my phone?
In BotBus settings on your computer, go to Paired Devices and remove that phone; it and its watch disconnect immediately. If it’s the only phone in the group, you’ll see “Dissolve Pairing” instead, which starts the whole group over with a new key. Your task history is on your computer and isn’t affected.
Can I recover a lost key?
We don’t have your key, so we can’t recover it for you. You don’t need to, though: scanning a new pairing QR code creates a new key, and since your tasks live on your computer, they sync back after you pair again.
Does it slow the app down?
Not noticeably. AES-GCM is accelerated in hardware, and encrypting costs far less than the network transfer itself. The one difference is that videos in a conversation have to download and decrypt in full before they play, instead of streaming.