# Is remote control of coding agents secure? Who can read your code > Driving Claude Code or Codex from your phone sends code and chats through someone's server. Official relays, SSH/VPN, chat bots and E2E relays compared. Canonical: https://botbus.io/en/blog/end-to-end-encrypted-remote-coding-agent Published: 2026-10-30 ## The short answer When you control a coding agent from your phone, who can read your code depends on the leg between the computer and the phone. Official relays (Claude Code Remote Control, Codex in the ChatGPT app) are documented as transport-encrypted, so the relay operator can process plaintext. SSH and WireGuard-based VPNs are end-to-end, but you run the entry point and manage the keys. Chat bots on Telegram and similar platforms pass your messages through the chat provider in a form the bot can read. End-to-end encrypted third-party relays such as Happy or BotBus give the relay only ciphertext, but metadata is still visible. Nothing here is "perfectly secure". The real question is who you are willing to trust. Below is what each approach exposes, and to whom. Everything said about other products was checked against their official documentation on October 30, 2026; their docs are the source of truth if anything has changed. ## Two data flows, not one Most arguments about this topic mix up two separate paths: 1. **Computer to model provider.** Claude Code sends your conversation to Anthropic, Codex sends it to OpenAI, and if you point an agent at another provider or a proxy, it goes there. This exists whenever you use a hosted model, phone or no phone. 2. **Computer to phone.** This is the leg that remote control adds: task status, conversation, approval prompts and screenshots travel to the phone, and your commands travel back. That leg is what this post is about. If you already use Anthropic's models and then use Anthropic's Remote Control, the extra exposure is small, because the same company already receives the conversation. The case worth thinking about is when the second leg hands your content to a *new* party in readable form: a third-party relay without end-to-end encryption, or a chat platform. ## Option 1: the vendor's own relay **Claude Code Remote Control.** The docs say the local session only makes outbound HTTPS requests and never opens inbound ports. All traffic goes through the Anthropic API over TLS, using several short-lived credentials that are each scoped to one purpose. The docs also say that while Remote Control is connected, the session transcript (your messages, Claude's replies, tool activity) is stored on Anthropic's servers to keep devices in sync and reconnect after drops, under the Data usage policy. Organizations with Zero Data Retention or the HIPAA configuration can't enable it. Team and Enterprise admins can require Trusted Devices, where each device enrolls separately and sign-ins older than 18 hours need a biometric or passkey step-up. **Codex remote connections.** OpenAI's docs describe a "secure relay layer" that keeps trusted machines reachable from your authorized ChatGPT devices without exposing them directly to the internet, while repository files and shell commands stay on the connected host. As of the check date, the docs don't say whether that relay is end-to-end encrypted or list what it syncs and stores. **Good fit:** people who already use that vendor's models and are comfortable with its data policy. The strengths are real: a mature account system, admin controls, and one company accountable for the whole path. The limits: the relay operator can technically handle plaintext, each relay only covers its own agent, and Remote Control doesn't work if you run Claude Code with an API key, Bedrock, or a gateway. ## Option 2: SSH or a VPN The do-it-yourself route: run the agent in `tmux` and SSH in from your phone. SSH is end-to-end, so nobody in the middle can read the session. To reach a home machine from outside, most people add a WireGuard mesh like Tailscale. Tailscale says its coordination server only exchanges public keys and policy, private keys never leave the device, and its DERP relays only forward already-encrypted packets they cannot decrypt. **Good fit:** people who are at home in a terminal and willing to maintain the entry point. Shortest data path, and it works with any agent. **The cost:** you own the security of that tunnel. An SSH port on the open internet needs key-only login and brute-force protection. Your phone also holds a private key that opens a full shell on your computer, which is far more power than "approve this command" if the phone is lost. And there are no push notifications. That isn't a security issue, but it's the usual reason people give up on this setup. ## Option 3: chat bots Driving an agent through a Telegram, Discord or Slack bot means no new app to install. Claude Code has an official version of this: Channels, a research preview that lets plugins push Telegram, Discord or iMessage messages into a running local session. Keep in mind that the chat platform carries the messages. Telegram's FAQ says regular cloud chats use server-client encryption and only Secret Chats are end-to-end, and its Secret Chat description covers chats between two devices. The FAQ also notes that bots can see the messages you send them. So the prompts you send, and the commands and file paths the bot sends back, pass through the platform in a form it can process. The Channels docs raise another point: if a channel relays permission prompts, *anyone who can reply through that channel* can approve or deny tool use, so only allowlist people you trust with that. The iMessage channel needs Full Disk Access for your terminal so it can read the local Messages database. **Good fit:** mostly notifications plus the occasional short instruction, for people fine with the content passing through a chat provider. ## Option 4: an end-to-end encrypted third-party relay Most third-party remote tools need a relay, because your computer and phone are rarely on the same network. The question is whether that relay can read what it forwards. With end-to-end encryption, content is encrypted on the device before it leaves, and the relay only moves ciphertext. Happy's docs, for example, say messages between your devices are end-to-end encrypted, and they include a self-hosting guide. BotBus is in this group too. Here is what it does, as described in our [security page](https://botbus.io/en/docs/security): - **The key changes hands on your computer screen.** When you pair, the computer generates a one-time X25519 key pair and puts the public key in the QR code on screen. The phone scans it, generates a 256-bit group key locally, seals it to that public key, and sends it back through the relay. The relay never sees the public key, so it can't open the envelope or impersonate your computer. That's also why there's no 6-digit pairing code: six digits can't carry a key. - **Content is sealed with AES-256-GCM.** Task titles and status, project paths, uncommitted changes, full conversations, images and files you send, screenshots the agent shares back, approval details and your answers, every command from the phone (including which kind of command it is), computer and phone names, and notification text are all encrypted on-device. Each ciphertext is bound to its position, so if the relay moves task A's data under task B, decryption fails. - **Push notifications are ciphertext too.** Apple's push service gets a fixed generic line plus an encrypted blob; the iPhone decrypts it locally and shows the real title and text. - **Remote access is encrypted.** Viewing and controlling your Mac's screen, and opening files and terminals on the computer (Mac, Linux and Windows all have files and terminal), use a separate derived key for every frame and input. The viewer page ships inside the app rather than being loaded from the server. - **You can check it yourself.** The computer's pairing window and the phone's settings each show an 8-character key fingerprint. If they match, both devices hold the same key. **What it doesn't protect, also listed on the security page:** - **Metadata.** The relay sees pairing and device IDs, whether each computer is online, task IDs (with a source prefix that shows which agent they came from) and update times, command IDs and times, notification categories, the size of each ciphertext, and connecting IP addresses. - **Dev previews.** When you share a local web page from your computer to your phone with `botbus`, the browser has to fetch the page's resources directly, so the server proxies them. Previews are outside end-to-end encryption and only reachable while you're sharing. - **The model provider leg.** BotBus encrypts computer-to-phone traffic. What your agent sends to OpenAI, Anthropic or anyone else is unaffected. - **Unlocked devices.** Anyone holding your unlocked computer or phone sees what BotBus shows. - **The worst the relay can do** is withhold messages, delay them, or replay an older state you've already seen. It can't forge or read content. **Good fit:** people who don't want to run their own SSH entry point but also don't want a new party handling their conversations in plaintext. It also helps if you use several agents: BotBus covers Codex, Claude Code, Hermes, Pi, OpenClaw, OpenCode and DeepSeek Harness, and ACP agents can be [connected too](https://botbus.io/en/docs/connect-agent). The trade-off is that you still trust the app installed on your own devices, and you accept the metadata above being visible to the relay. ## Questions to ask any remote-control tool 1. **Where is the key generated, and how does it reach the phone?** If it passes through the server, or a new device can get it with just an account login, the server can decrypt in principle. 2. **What metadata does the server see?** A tool that publishes the list is easier to trust than one that just says "secure". 3. **Which features are outside the encryption?** Web previews, push notifications and file downloads are common exceptions. 4. **What happens on timeout or error: allow or deny?** An approval channel that fails open is a risk regardless of encryption. In turns started from the phone, BotBus treats timeouts and interruptions as a denial. 5. **What if the phone is lost?** Can you remove one device, and can you rotate the key? In BotBus, removing a phone in the computer's settings revokes its credentials immediately; to get a brand-new key, unpair on the phone and scan again. ## FAQ ### Is Claude Code Remote Control end-to-end encrypted? As of October 30, 2026, the docs say traffic goes through the Anthropic API over TLS with short-lived credentials, and the transcript is stored on Anthropic's servers while connected. They don't describe it as end-to-end encrypted. If your model is Anthropic's anyway, the extra exposure is limited. ### Is Tailscale plus SSH safer than any relay? On "can anyone in the middle read it", it's in the same tier as an end-to-end encrypted relay, since WireGuard and SSH are both end-to-end. The differences are elsewhere: you maintain the entry point yourself, and the SSH key on your phone can log into the whole machine, which makes a lost phone more serious than losing an app that can view tasks and answer approvals. ### Does end-to-end encryption mean the server knows nothing? No. It can't read content, but it sees what it needs to route data: device IDs, online status, task IDs and update times, data sizes, and connecting IPs. BotBus lists all of this on its [security page](https://botbus.io/en/docs/security). ### Why aren't BotBus dev previews end-to-end encrypted? A browser loading a web page requests all its resources directly, so the server has to proxy them to your computer. Screen control, files and terminals are a different mechanism and are encrypted. ### Where do I get BotBus? There are desktop versions for Mac, Linux and Windows, and apps for iPhone, Apple Watch and Android, all in the [download section](https://botbus.io/en/#download).