Workers and host bridges

Every service Claude talks to, Slack, GitHub, SharePoint, your local Office files, runs behind its own worker: a small container built for one job, holding only the credentials that job needs. Claude never calls a service directly. Instead it goes through the Tool Gateway, which forwards each request to the right worker and holds zero tokens itself. A bug in one worker exposes only that worker’s service. Some workers get no credentials or network access at all, because their job never needs them.

One worker, one job, one set of credentials

Each worker mounts only its own service’s tokens, read-only, at /tokens. How credentials are handled covers where those files live and how they get there. A worker that needs none, such as the built-in office worker, has an empty credential set and no /tokens mount at all.

The office worker shows how far this isolation goes. It reads, writes, and converts Word, Excel, PowerPoint, and PDF files, a job that touches untrusted formats and is a classic target for malicious documents. It has no service credentials. It attaches only to a dedicated internal network with no gateway route, so even a fully exploited parser cannot reach the internet.

Its only connection to your machine is the project workspace, mounted read-write. Every path it touches is checked against that mount, and output lands in a dedicated folder rather than overwriting whatever it finds.

Host bridges: the narrow path back to your machine

Some features need the reverse connection, a service reaching your machine instead of Claude reaching a service. Speedwave calls this a host bridge. Pairing Claude Code with your local editor is the built-in example, handled by the IDE bridge. On macOS it binds to loopback, 127.0.0.1. On Windows it binds to the WSL adapter IP instead, because WSL2’s mirrored networking mode breaks loopback reachability from containers. Either way the bridge is host-only: never reachable from your LAN.

The bridge writes its connection details to a lock file mounted into the container read-only. Claude Code reads the port and a session auth token from that file, so the bridge never exposes anything on the network. The token is fresh per session, checked in constant time, and never logged. The lock file and its parent directory are owner-only, so another account on the same machine cannot read it.

Note

One gap remains: a process already running as you could read that same file. This matches the usual assumption that anything running as your user is already inside the trust boundary.

Per-service workers and narrow host bridges are why turning on more integrations doesn’t widen what a single compromised piece can reach.