daemon
└─
Your machine. Runs the agent, owns the session, holds the keys.
How it works
Three parts, and a hard rule: nothing sits between your devices and your daemon. There is no relay server, because there are no servers at all. The pieces below are the entire system.
Three parts
The daemon
The daemon runs on your computer, the one where your code already lives. It launches your agent (Claude, Gemini, or a shell), keeps each terminal session alive in a pseudo-terminal, and serves the encrypted channel. All session state lives here: scrollback, cursor position, a mid-render TUI, everything. The daemon is the single source of truth for what is running. Your API keys and your agent config stay here too, because the daemon launches the agents you already configured rather than carrying their secrets anywhere.
Your devices
A device is a phone, tablet, or browser. Each one is paired once and holds its own device token. All the display and input code lives on the device: it renders the terminal, draws the TUI, captures your keystrokes, and sends them on. What it does not do is store the session. Close the device, lose it, throw it in a drawer, and the session it was showing carries on without it, because the device was only ever a window.
The encrypted link
Devices talk to the daemon directly over an end-to-end encrypted channel. No cloud, no relay, no third party. The transport underneath might be your LAN, a VPN, or a tunnel, but only the two endpoints can read the data. The link is the part that makes the other two safe to use from anywhere: because it is encrypted end to end, it does not matter what the traffic crosses to get from the device to the daemon.
device
└─
Your phone or browser. Renders and types. Stores nothing but its own token.
link
└─
End-to-end encrypted, directly between the two. Untrusted transport, trusted endpoints.
The flow, start to finish
- You start the daemon.
It opens a local listener and prints a pairing QR and a typeable code.
- A device pairs.
It scans the QR or types the code, runs a key exchange, and gets a device token.
- You open a session.
The daemon spawns the agent in a pseudo-terminal and streams its output, encrypted, to the device.
- You type.
Keystrokes go back the same way, encrypted. The agent thinks it is talking to a normal terminal, because it is.
- You walk away.
The session keeps running on the daemon whether or not any device is watching, ready for whenever you reattach.
Why there is no relay
No relay
This is the load-bearing design choice. Most tools that promise coding from your phone route your session through their servers, which means their servers are in a position to read it. codeout does not have servers. Your devices and your daemon are the only computers involved, so there is no third party that could read your session even if it wanted to.
A tunnel, when you use one, is not an exception to this. A tunnel forwards encrypted bytes; it is not a relay that terminates your session and re-sends it. It cannot read what it carries. The distinction matters: a relay sees plaintext, a tunnel sees ciphertext, and codeout is built so the only thing in the middle is ever the latter. The details of that encryption are on the Security and encryption page.
The trust boundary
Draw a line around your daemon host and your paired devices. That is the trust boundary, and it is small on purpose. Everything inside it you already control. Everything outside it, including any network, VPN, or tunnel the traffic crosses, is treated as hostile and learns nothing but authenticated ciphertext. Securing codeout is therefore mostly about securing those two kinds of thing you already own, rather than trusting a service you do not.