CLIAnywhere encrypts terminal sessions end-to-end. The session key is negotiated directly between your computer and the app with SPAKE2, a password-authenticated key exchange, and all application data is encrypted with AES-256-GCM before it leaves your device. When traffic passes through our relay, the relay only ever sees ciphertext.
From keystroke on your phone to shell on your PC, in order.
You type into the app on iOS, Android, or the Web App.
Password-authenticated key exchange between your devices.
A shared key known only to your computer and the app.
Every keystroke and byte encrypted before it leaves the device.
DTLS direct link, or WSS through the encrypted relay.
The daemon decrypts and runs the session on your computer.
Connections are established over DTLS for direct peer-to-peer links, or WSS when traffic falls back to the relay — a secure transport either way. Which one is used depends purely on whether your devices can reach each other directly on the current network; the choice is automatic and invisible to you.
Both transports are outbound connections from your computer, which is why no port forwarding or public IP address is needed. That design is covered in more detail in remote access without port forwarding.
Before any terminal data flows, your computer and the app negotiate the session key with SPAKE2, a password-authenticated key exchange. The password used in that exchange is the Security Code: it is generated and stored locally on your PC, never uploaded anywhere, and you are asked for it whenever you connect.
Because the code lives only on the machine it protects, it works as a second layer on top of your account. An attacker who obtained your account credentials would still be asked for the Security Code when connecting to your PC — account access alone is not enough.
All application data is encrypted with AES-256-GCM before it leaves your device — authenticated encryption for every keystroke and byte of output. The same applies to the file browser and to localhost and LAN traffic: terminal content, files, and web requests all ride the same encrypted payload channel.
The "authenticated" part matters as much as the "encrypted" part: GCM ties an authentication tag to each payload, so tampering with data in transit is detected rather than silently passed through.
When a direct path is not available, traffic passes through our relay. The relay's job is forwarding — and that is all it can do. Since application data is encrypted with AES-256-GCM before it leaves your device, and the session key was negotiated directly between your devices, the relay only ever forwards ciphertext.
Your keystrokes, terminal output, and files are readable by your devices alone.
The account layer is deliberately thin. Signing in is required to see your devices — it is how your phone finds your PCs — but it does not grant access to a session. Each PC adds its own locally generated Security Code on top, asked for at connect time.
One account can link multiple computers, and each of them keeps its own independent Security Code. For how the pieces fit together day to day, see how CLIAnywhere works.
A security page should state its boundaries as clearly as its guarantees.
Every row below is the complete claim — nothing stronger is implied.
| Direct P2P transport | Yes — DTLS |
|---|---|
| Relay fallback transport | Yes — WSS |
| Key exchange | SPAKE2 (password-authenticated) |
| Payload encryption | AES-256-GCM, applied before data leaves the device |
| Security Code storage | Generated and stored locally on each PC, never uploaded |
| Relay visibility | Ciphertext only — forwarding, nothing else |
| Account layer | Sign-in required to see devices; per-PC Security Code on top |
| Port forwarding / public IP required | No |
| Open-source daemon | Yes |
| Hosts | Windows, macOS, Linux |
| Clients | iOS, Android, Web App |
| Account model | One account, multiple PCs, per-PC local Security Code |
Short, direct answers to the questions people ask most.
The daemon that implements all of this is open source — verify first if you want to.