Where the session runs

The new-chat form starts not with a folder but with the question "Where to run it". And so it should: directories, models and commands differ from machine to machine, and a session stays where it was started — its transcript lies on that same machine. Switching this later means starting a different chat in a different place.

The options

Where	What it means
Same place as Clauder	the way it always was: the server's directories, the transcript next to ~/.claude, the work outlives a closed browser
This machine	a folder on your own disk, handed to the browser tab
A worker	another machine that comes to the server for work by itself
The phone	a server brought up right on the Android device

In the web UI the first three stand as chips in the new-chat form. On Android the line is called "Where" and lists machines — there a machine is a server profile, and there are four slots: the home server, a spare, one more and the phone itself.

A folder on your own disk

The tab asks you for a directory (File System Access), and the agent works with the files right inside it — nothing to install. The browser remembers the folder you handed over between visits, so you don't have to pick it again every time.

Such a folder used to allow reading and editing files only; now commands run there too, so a chat with a browser folder behaves like an ordinary project rather than a stripped-down one.

Not available everywhere

File System Access exists in Chrome, Edge and other Chromium browsers. In Safari and Firefox there will be no "this machine" chip — the server and workers remain.

Another machine through the bridge

A worker is a program on your machine that comes to the server for work. It helps when the agent doesn't live where the project does: say claude sits on a VM kept for isolation while the code is on your laptop.

What stays where:

• on the agent's side — the session, the transcript, the spend, claude itself;
• on your machine — the files, the commands and the project's terminal.

You lend your machine to someone else's Clauder from the "Bridge worker" card on the "Connection" tab: the address of that server, an access key and the name to introduce yourself by. This used to mean editing environment variables by hand.

Whose subscription is spent is decided not by the guest but by the key: an access key has a "Claude subscription" setting — work as the owner, with your own account, or through the guest's machine when their token must not leave their computer. More in Access keys.

A server on the phone itself

The Android app can bring a Clauder server up right on the phone — then the session runs there, with no home machine at all.

• With root the app calls su itself. No Termux and no permissions needed, and this is the only way to give the agent a real Android rather than an imitation of one.
• Without root — through the Termux command service. You need Termux itself, the permission granted and allow-external-apps enabled; refusals are named by their cause, not by a generic "didn't work".

Bringing it up takes up to a minute, and you can see which stage it is on: what to start it with → launching → waiting for an answer. A chat started on the phone never moves away by itself: when the phone server goes quiet that is its normal state, not a failure, and moving the session to the home machine would mean running it somewhere you didn't ask for.

Termux from Google Play won't do

The googleplay.* build accepts no commands from outside at all: it has no com.termux.RUN_COMMAND service. You need Termux from F-Droid or from the GitHub releases.

More about the client — Android.

What the agent sees

The model knows where it is working: it is told the machine's name, its system and the available roots. So it doesn't try to fix paths "the way they are on the server" when the files are on your laptop.