How credentials are handled

Every credential Speedwave stores lives under one data directory on your machine, ~/.speedwave/ by default. Inside it, a tokens/<project>/<service>/ folder holds the credential files for one service, such as Slack or GitHub, created only when that service actually needs credential files.

One worker, one set of credentials

Each MCP worker, the isolated container that talks to a service like Slack, GitHub, or SharePoint, mounts only its own service’s token folder, read-only, at /tokens. A worker never sees another service’s credentials, so if one is compromised, the blast radius is that one service’s tokens, nothing more. Files are 0o600 and their parent directories 0o700, owned by you.

The container Claude itself runs in holds no service tokens at all. Requests pass from Claude through a hub with zero tokens of its own, over HTTP, to the worker that holds the credential. Environment variables named like a token, key, or secret are blocked from reaching the Claude container or the hub, so a credential can only ever reach a worker as a file mount, never as something the model reads from its own environment. That split is the core of Speedwave’s isolation model.

Note

LLM provider API keys follow the same pattern but land on the proxy container instead of a worker: tokens/<project>/llm/<provider_id>_api_key, mounted read-only. The proxy’s config only ever holds a placeholder env name like SPW_KEY_<ID>, never the key itself, and resolves that name to a file read at request time, so the key never becomes a container environment variable. The Anthropic API key is the one deliberate exception and stays on the Claude container, since Claude Code needs it directly.

Every proxy call also carries a per-project caller token in the x-speedwave-proxy-auth header, stopping another container on the same project network from relaying calls through it. A SHA-256 digest over the proxy’s config and token files drives its SPW_CONFIG_DIGEST variable, so rotating a provider key recreates the container automatically, without logging the key. See LLM providers and token paths for where these files live.

The IDE Bridge token

Pairing Claude Code with your local editor needs a path from the container back to your machine. The IDE Bridge lock file holds a UUID v4 auth token, regenerated on every Desktop start, and Speedwave mounts it into the container read-only.

What you see in the terminal

The CLI never prints a raw secret, even by accident. Every line it writes, stdout, stderr, a log line, or a panic message, passes through the same sanitizer that scrubs the diagnostics export: Bearer tokens and API keys come out as ***REDACTED*** before they reach your screen.

Set up the services Speedwave can reach through workers on the integrations page.