blog

Does Claude Code run locally or in the cloud? What leaves your machine, and what a stolen login gets

Claude Code runs in your terminal, and Clawdline keeps it there while your phone watches. What the relay carries, what our side can see field by field, and what a key nobody else holds costs you.

Claude Code runs on your machine: a program in your terminal, using your shell, your files and your own assistant account. No part of the work is hosted anywhere.

It gets interesting when you want to watch that session from elsewhere. Something has to reach the machine, and what that something is decides what a stolen login is worth.

The question is not where the window is: a hosted runner holds the plaintext

If a service can draw your transcript, it holds your transcript. Something has to hold the text in order to draw it. So follow one prompt from your keyboard to the screen, and mark every point where it exists in the clear.

A hosted runner is good at something. A hosted agent works with your laptop shut, needs no pairing step, and survives you dropping your phone in a river. Those conveniences are one decision seen from the front: your repository is checked out on a machine you do not administer, and your prompts pass through a service that can display them — and therefore read them. Password reset works because somebody else can reach the data.

If what you want is a machine awake at three in the morning, buy the machine that is awake. Another post compares the remotes with each project’s own documentation open.

Clawdline made the other trade: there is no cloud runner here to move anything to. Your sessions run in your shell, on your machine, under your own assistant accounts — the Cloud guide puts it in one line, nothing runs in Cloud. The optional half exists so a phone can reach the machine already doing the work; the console shows sessions you started yourself.

The real limit is the same sentence: if the machine is asleep, there is nothing to reach. A command sent to a machine that is not connected fails immediately and says so.

The relay carries sealed envelopes, and this is every field it can see

Being local is no comfort if what you type crosses somebody else’s server in readable form on the way to your phone. So Clawdline seals every payload before it leaves the machine, and the relay only handles envelopes.

plaintext

Your machine

Claude Code and Codex run here, in your shell, under your own accounts. Prompts, answers and code exist in the clear — and only here.

sealed

The relay

Moves envelopes. Knows which channel, when, and how many bytes. Holds no key that opens one, and cannot compose one.

plaintext

Your phone

Decrypts because it holds a key — given to it when a device that already had one approved the handover.

Plaintext exists at the two ends and nowhere in between. Which is the whole claim: somebody who becomes you gets the middle, and the middle has nothing in it.

The key that opens them is made on your first machine, and our side never sees it. A second device gets it by scanning a pairing code on a device that already holds one. No copy is kept for emergencies: nobody here can read it and we keep one in case you need it cannot both be true, and the encryption document writes that contract out.

The security page publishes the whole list to hold against the protocol. At a glance:

Where What our side can see
On every envelope Version, channel, sequence number, timestamp, class, key id, nonce, sending device, signature — and that the sealed payload is there and how many bytes it is
Around the connection When a machine or a viewer was connected, and how much moved in each direction
In the control plane, before any envelope exists Your account and subscription state; your machines by name, platform and last seen; your devices with their capabilities and public keys; and the usage counts we bill and rate-limit from
Never Everything inside the sealed payload: prompts, answers, transcripts, your code and file paths, handoff documents and attachments, schedule definitions and task instructions, and which paths a task has claimed

The row that usually goes missing is the third one. An account exists before any envelope does, so a list that stops at the wire is not the whole list.

Somebody with your login gets a viewer that cannot read anything

An attacker holding your login session can attach a new viewer device to the account. They cannot make it decrypt a single session: the content key arrives only through that pairing approval, and our servers cannot compose one either. That is not a policy anybody promises to keep; it is a key that was never held.

Commands travel the same road. Every instruction from a viewer is signed by that device’s key, and your machine checks it against its own list of paired devices. A stolen account is not a shell on your machine.

The local server binds 127.0.0.1 and nothing else, so a café network has no interface to find it on. Seeing your sessions and typing into them are separate switches, both off in a fresh install.

What it costs: a recovery code, a pairing step, and metadata that is real

Recovery is the price, the exact mirror of that password reset. If nothing on the server can decrypt your content, nothing on the server can restore it, and no support-desk goodwill changes that. The answer is a recovery code you keep yourself, and our security page lists that code, the device roster and the encrypted history vault as being built rather than shipped.

Pairing is the second cost, one more thing to do the day you buy a phone. Revocation has an edge of its own: press revoke and routing stops at the next entitlement refresh, normally inside a minute, up to 24 hours if our control plane is unreachable. A device that already held the key can still read what it recorded before you revoked it.

Metadata is real: the relay knows when you connected and roughly how much you sent. Anyone claiming none at all is describing a system that cannot route.

Ask any tool the recovery question, including this one

Ask what happens if you lose every device — of whatever you already run, us included. If support can restore your history, somebody other than you can read it. The smaller version, for anything that puts your sessions on a phone: can it show a session without being able to type into one?

The local daemon and web console are open source, free and complete on their own, and plenty of people never turn Cloud on. Cloud enrolment is still a preview and nothing here can be bought yet; the pricing page says that properly, and the Cloud guide separates what is present today from what is still being built. To see the local half alone, install Clawdline and leave Cloud off.

That is the end of this series. The next one starts where one task becomes five becomes twenty-five.

Common questions

Does Claude Code run locally or in the cloud?
Locally. It is a program in your terminal, using your shell, your files and your own assistant account, and no part of the work is hosted anywhere. The question only gets interesting when you want to see that session from a phone, because something then has to reach the machine. With Clawdline that something is a relay and not a runner: your sessions keep running on your machine, and the optional Cloud half exists so a phone can reach the machine that is already doing the work. It has nowhere to do the work itself. The honest cost of that is stated in the same breath — if the machine is asleep there is nothing to reach, and a command sent to a machine that is not connected fails immediately and says so, rather than being queued to run later when you have stopped thinking about it.
What data leaves my machine if I let my phone see my Claude Code sessions?
Two halves, and most answers only give the first. On the wire it is the metadata a router needs in order to route: envelope fields, connection times and byte counts — not prompts, answers, transcripts, code, file paths, attachments or schedule text, all of which are sealed before they leave your machine. The other half is not on the wire at all, because an account exists before any envelope does: the control plane holds your account and subscription state, your machines by name and last seen, your devices with their capabilities and public keys, and the usage counts we bill from. Clawdline publishes both lists field by field on its security page, which is worth reading rather than summarising — a list you can hold against the protocol is a different kind of claim from an adjective.
What happens if somebody steals my login, or if I lose every device?
Those two questions have the same answer, and it is the honest test of any end-to-end claim. Somebody who steals your login session can add a viewer device to the account; they cannot make it able to read anything, because a content key only arrives when a device that already holds one approves the new device, and our servers cannot compose one either. Commands work the same way: each one is signed by the sending device's own key and checked by your machine against its own local list, so a stolen account is not a shell on your machine. The price of that is the second question. Nothing on the server can decrypt your content, so nothing on the server can restore it; recovery runs through a code you keep, and Clawdline's own security page lists that recovery code, the device roster and the encrypted history vault as being built rather than shipped. What survives losing every device is the work itself, because the source of truth was always your machine.