Credentials management
All credentials managed by Speedwave are stored within your user data directory (~/.speedwave/ by default). Within this directory, tokens/<project>/<service>/ holds configuration and authentication files for individual services (such as Slack or GitHub), created only when an active service requires them.
Isolated credential scoping per worker
Section titled “Isolated credential scoping per worker”Each MCP worker container communicates with a specific external integration (such as Slack, GitHub, or SharePoint) and mounts only its own service directory under /tokens in read-only mode. A worker has no access to credentials belonging to other integrations. In the event of a compromised worker, exposure is strictly confined to that single service. Credential files are created with 0o600 permissions inside 0o700 parent directories owned exclusively by your user account.
The container executing Claude Code contains no service credentials. Inbound requests from Claude flow through the central MCP hub (which also holds zero credentials) over internal HTTP endpoints to the target worker. Environment variables resembling tokens, passwords, or secret keys are blocked from the Claude container and hub environments. This strict decoupling of the reasoning engine from raw credentials is the core guarantee of the Isolation model.
Outbound proxy requests require a project-specific caller token passed in the x-speedwave-proxy-auth header, preventing unauthorized containers on the same network from routing requests through the proxy. A SHA-256 digest of configuration and token files populates the SPW_CONFIG_DIGEST environment variable, enabling automatic container recreation upon credential rotation without logging secret values. See LLM providers and Token and credential paths for location details.
IDE Bridge authentication
Section titled “IDE Bridge authentication”Connecting Claude Code to your local code editor requires secure communication between the container and host. The IDE Bridge lock file stores an ephemeral UUID v4 authentication token regenerated upon each Desktop application launch, mounted into the container in read-only mode.
Terminal output sanitization
Section titled “Terminal output sanitization”The CLI includes an automatic output sanitizer to prevent credential leaks. Every output stream (stdout, stderr, runtime logs, and panic messages) passes through a sanitization filter identical to the diagnostics exporter, automatically masking Bearer tokens, private keys, and API secrets with ***REDACTED*** before display.
For instructions on configuring specific services, see the Integrations catalog.