> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloudthinker.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Self-hosted sandboxes
> Run a chat or Automation on a machine you control, set what the agent can reach, and choose whether it uses your workspace connections
A self-hosted sandbox runs the agent on a machine you control — your laptop, a server, or a CI runner — instead of CloudThinker Cloud. You pick where each chat and each Automation runs, name one folder for the agent to work in, and decide whether the run may use your workspace connections through the CloudThinker managed sandbox. The app and the CLI call a self-hosted sandbox a **Worker**.
**Beta** — Workers are in beta and ship with the [CloudThinker CLI](/guide/cli/overview), which is in early access. Command names and flags may change before general availability.
## Why a Worker
* **Reach a private machine.** The agent edits files and runs commands where your code and tools already live, without exposing them to the cloud.
* **Keep credentials in the cloud.** A connection command runs in the CloudThinker managed sandbox with its credential injected there. A credential never leaves the cloud onto a Worker.
* **Share one machine, or keep it personal.** Only you can see and use a personal Worker. A shared Worker is visible to every authorized member of the workspace.
* **Use your folder's rules and Skills.** The agent reads the instruction files and the Skills that you keep in the folder.
* **Route Automations too.** A scheduled Automation can run on a Worker every time it fires.
* **Fall back to nothing.** When a Worker is unavailable, the run reports the error. It does not silently move to the cloud.
## Choose where a chat runs
You pick where a chat runs in the composer, before the first message. After the first message, the choice is fixed for that conversation.
Open the **+** menu beside the chat prompt box. The **Run in** row appears when there is a choice — a Worker, a Desktop folder, or a load retry.
Select **Run in**, then choose **CloudThinker Cloud** or a Worker by name.
**Success state:** a chip appears in the toolbar with the Worker's name. Its tooltip says what runs where.
Send your first message. The conversation is now bound to that Worker.
**Success state:** the chip shows a lock and becomes read-only. A fork or a Room thread inherits where it runs. The conversation list marks the conversation with the Worker's name.
When the only choice is CloudThinker Cloud, the **Run in** row does not appear, and the chat runs in the cloud.
The composer remembers your last choice for the workspace. A new chat starts on that Worker until you pick another place.
## Set up a Worker
You can also add a Worker from the **Sandboxes** page, which shows the same commands. You register and run a Worker from the CLI. Install and log in first — see [CLI](/guide/cli/overview).
```bash theme={null}
cloudthinker worker outpost create "my-laptop" --shared
```
Omit `--shared` for a personal Worker. This stores the Worker's credential on this machine. List what the workspace has with `cloudthinker worker outpost ls`.
```bash theme={null}
cloudthinker worker start --outpost "my-laptop" --workdir ~/projects/app
```
File tools are confined to `--workdir`. Shell commands start there, under your own OS account. The process serves work over outward HTTPS until you interrupt it.
```bash theme={null}
cloudthinker worker status --outpost "my-laptop"
```
**Success state:** the status reads available. Registration alone is not enough — the Worker first passes server-driven file, shell, cancel, and artifact checks before the workspace can select it. In the setup dialog, select **Start a chat** to open a new chat on this Worker. A failed check shows its reason in the same dialog.
## What a Worker can access
The two ways the agent touches your machine have different reach. Know both before you serve a folder.
| The agent does this | Where it can reach |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------- |
| Read, write, edit, or list files with a file tool | Only inside `--workdir`. A path outside the folder, or a `..` that climbs out, is rejected. |
| Run a shell command | The whole machine, as your OS account. `--workdir` is only the starting directory. |
The file boundary is enforced on the machine itself, not only in the cloud. The Worker opens `--workdir` as a directory handle, so even a symlink cannot point a file tool outside the folder.
A shell command has no such boundary. CloudThinker adds no container, sandbox, or reduced privileges on your machine, so the command can do anything your account can — read `~/.ssh`, write outside the folder, or reach the network.
A shell command on a Worker runs with your OS account's full access to the machine, not only `--workdir`. Serve a folder from an account whose reach you accept. On a machine that holds sensitive files, keep the agent in Manual mode and use [Approval](/guide/approval) for shell actions.
A shell command sees a reduced environment by default: only `PATH`, `HOME`, `LANG`, `TERM`, `USER`, and `TMPDIR`. CloudThinker strips its own launcher variables. Pass one variable with `--env NAME=VALUE`, repeat the flag for more, or pass your whole shell with `--inherit-env`.
## Command reference
Every command starts with `cloudthinker worker`. Set `CLOUDTHINKER_OUTPOST_ID` to omit `--outpost` on repeat calls.
| Command | What it does |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| `outpost create "" [--shared]` | Register an outpost and store its credential on this machine. |
| `outpost ls` | List the outposts the workspace can run work on. |
| `outpost archive ""` | Retire an outpost so no more work routes to it. You can also remove a Worker on the **Sandboxes** page. |
| `start --outpost "" --workdir ` | Serve one folder until you interrupt it. |
| `status --outpost ""` | Show the outpost's availability as the workspace sees it. |
| `service install --outpost "" --workdir ` | Register a background service (see [Keep a Worker running](#keep-a-worker-running)). |
These flags tune `worker start`:
| Flag | Default | What it does |
| ---------------------- | ----------- | ------------------------------------------------------------------- |
| `--outpost ` | — | The outpost to serve. Reads `CLOUDTHINKER_OUTPOST_ID` when omitted. |
| `--workdir ` | — | The one folder file tools are confined to; shell starts here. |
| `--concurrency <1-32>` | 4 | How many assignments the Worker serves at once. |
| `--name
