Access keys
There is one way in — a key. The main one (API_KEY from .env or from the app's config.json) opens the whole machine. Alongside it live named keys: they are issued and revoked from any client's settings, and they can be narrower than the main one.
What can be narrowed
| Field | Meaning |
|---|---|
| Access | "as the owner" or "look only" |
| Scope | a list of projects, a sandbox directory, or "no restriction" — as a choice, not as emptiness |
| Permission mode | the agent's permission mode, nailed to the key |
| Tools | the agent's tool set: all, no shell, read files only |
| Terminal | whether to give this key a shell at all |
| Own Claude directory | its own memory, tasks and settings — or shared with the owner |
| Claude subscription | whose account to work with: the owner's, its own, or through the guest's machine |
| Expiry | when the key stops letting anyone in; empty — never |
| Quotas | a disk cap and a share of the processor |
A key remembers when it was last used — that mark shows which issued keys have been dead for ages and are due to be revoked.
The sandbox
The third kind of scope is a directory the key runs on its own: it sees everything inside, creates new folders right from "New chat", and never steps outside. A list of projects can't do that: a project that doesn't exist yet can't be in any list.
The directory is chosen by walking the tree rather than typed as a string: a path outside the machine's working roots won't be accepted by the server, and instead of the promised sandbox you would get a silently empty key.
This is how you show a colleague one directory without handing over the remote to the whole computer. The guest needs one key — their own; the main one stays with the owner and is needed only to issue the guest's.
The scope is not everything
The scope says what the key can see. Permissions say what it can do inside what it sees, and without them the scope stays a boundary of the interface: an agent with Bash in an allowed project reads the whole machine.
That is why a key has a separate tool set. It lives as a name, not as a list: add a tool to the set and every issued key learns about it at once. A list saved back then would silently let through every new Claude Code tool.
A guest's turn runs as their own user
The scope and the tool set are a boundary of the interface: Bash in an allowed project is still a shell onto the whole machine. The real boundary is drawn by the system itself, and on Linux Clauder draws it: a key with a scope has its own machine user, and the agent's reply runs as that user.
- For whom. A key with a scope, "look only" or a sandbox. A named key with no scope and full access is the same owner from another device, and there is nobody to demote it from.
- Where. Linux where the server runs as root — that is, the docker build. In the app on Windows and macOS there is no such separation at all: there everything stays the key's scope, and the server doesn't pretend otherwise.
- What it gives. Access to other people's files is refused by the kernel rather than by the interface: a guest with a shell won't read what their user wasn't given.
What a guest key does not give
A terminal is not given to a guest at all — not even with full access to their own projects: from a shell the whole machine is visible, not the key's scope. That is decided by the server, not by the client.
How to hand a key over
Nobody carries 64 characters by hand. Every issued key has a "Code and link" button:
- a QR in the same format as the connection code — the app scans it;
- a browser link
<web UI>/?token=<key>— the guest is in without typing anything.
The address in both is of the server where the key was issued, so the handover doesn't let a key be carried to someone else's server.
The link is the key
Give it only to the person the key was issued for. Went to the wrong place — revoke the key and issue a new one; that is one button and needs no restart.
A read-only link to one chat
You can show a colleague how the work went without a key: "Share a link" in the chat menu, on the web and on Android. A link of the form <web UI>/share/<token> opens this chat and nothing else.
- It is not a key. The link doesn't go through the common key check and opens only its own page: no other server endpoint can be reached with it. It is not in the list of keys.
- By default — the conversation only: message text, answers to the model's questions and images. Tool calls, command output and the model's thinking are cut off by the server — they carry paths, pieces of code and whatever the commands printed. They can be shown only with a checkbox when issuing the link. The guest never sees the directory, branch or model, in any mode.
- The chat is live. The guest's page picks up new records by itself; earlier messages load with a button.
- Lifetime — an hour, a day (the default) or a week; there is no link that never expires. Revoking takes effect at once: on the next refresh the guest sees the link is gone.
- Who can share — the machine's owner and a named key without a scope. A guest with a key for a couple of projects cannot. An incognito chat can't be shared either: it leaves no trace, and a link would be one.
The link points at your machine's address, and the guest has to reach it: at home — over the local network, from outside — through your own https address or a one-click tunnel. A running tunnel comes first in the address choice.
A key lives on its own server
The app on a work computer, a container in docker and a VM on the internet have different databases. A key issued in the app window "doesn't fit" another server — it has to be created there, signing in with that server's main key. Project scopes are about that server's directories too.
How a key is passed
In any of three ways: Authorization: Bearer, the X-Api-Key header, or ?token= in the address. The last one is needed for SSE and images, where there is no way to set a header.
A key shorter than eight characters counts as switched off.