Workers

Trust model

A worker is not a sandbox. Read this page before you share one.

Every run executes as the machine's account#

Runs on a worker, local or docker, the owner's or a teammate's, execute as the account that started the worker, with no sandbox. Anyone who runs on a worker can read everything that account can, including other members' sign-ins on it.

Share a machine set aside for the work, such as a Mac mini your team builds on. A shared worker is a machine its owner trusts every member with.

Personal until shared#

A worker starts personal: only the runs its owner starts go to it. Its owner can share it with the organization on workbenches.dev, and then every member's runs can go to it. The owner can make it personal again.

	On a worker
Who runs	The owner, and every member of the organization once the owner shares it.
As whom	The machine's account, local or docker, with no sandbox.
Home of a local run	The starting member's directory; an empty one for a run started with an organization API key.
Credentials	The connection the run asks for, else the member's connection for its runner when the Workbench's model routes allow its provider, else the provider keys workbenches.dev sends with the run. An allowed connection that is not signed in fails with an error naming `wb connect --worker`, never falling back to the organization's keys.
The account's own logins	Never used: runner sign-ins, `gh`, git configuration, and Docker settings of the account stay out of every run.
Docker	Every run reaches the daemon of the account's current Docker context, resolved when the worker starts. A docker run mounts the starting member's sign-ins as the runner's credential root.
Claude Code on macOS	The member's login is kept in the account's keychain, in an entry of the member's own, so a docker run on a Mac needs an API key or a `claude setup-token` token.
OpenCode's ChatGPT subscription	Signs in with its device code, since the browser callback cannot reach the worker.
Repositories	Cloned only from GitHub or the worker's own API, following no redirect, with the run's own token.
Runner versions	A local run is refused when the machine's runner is older than the engine supports.

Every member of the organization may read its workers and their logs. A worker's owner, or an owner or admin of the organization, can remove it.

What a member signs in with stays on the worker#

When you connect a runner on someone else's worker, wb connect --worker says so first:

mini is Ada Lovelace's machine. Anyone who runs there can read what you sign in with.

Your CLI login key never leaves your machine. The sign-in itself is stored in your member directory on the worker, where anyone who runs there can read it.

What a run is given#

Credentials and environment values are held in the worker's memory only, never written to disk or logged.
The repository token is the exception: as for a hosted run, it sits in the checkout's origin remote so the agent can push, and workbenches.dev revokes it when the run ends. A repository run without a run token gets no token: the worker never falls back to gh auth token or any other credential of the account.
Docker configuration. A docker run's Docker client gets its own directory, $WORKBENCH_HOME/worker/docker/<run id>/, whose config.json holds only the run's private image pull credential, or nothing, with the file 0600 in a 0700 directory. It is removed when the run ends, or at the next start after a crash. The account's DOCKER_HOST, DOCKER_CONTEXT, and DOCKER_CONFIG never reach a run.
Engine-owned variables. A Workbench that declares a variable the engine owns is refused, and a value the server sends under such a name, such as BUN_OPTIONS or NODE_OPTIONS, is dropped.
Packages are downloaded only from the API origin the worker registered with, without following redirects, and up to 64 MiB.

Because the run token lives in memory, an outcome is not uploaded when the worker process restarts during a run; the log says so. A follow-up after a restart runs with the starting member's environment again, without the original start's environment values.

Runs stay out of your own work#

Worker runs are ordinary detached engine sessions in the worker's own engine home, $WORKBENCH_HOME/worker. They never appear among the account's personal runs, projects, or Studio.

Logs never carry secrets#

Log lines carry names, IDs, states, and a short task excerpt. They never contain credentials, environment values, or task output. Lines sent to workbenches.dev are scrubbed again of every credential shape and of the values the worker's live runs were given.