SecurityCheck and its rules
Before Speedwave starts a container, it renders the compose file and hands it to SecurityCheck. SecurityCheck parses that YAML, checks it against a fixed set of rules, and checks your host filesystem state. If anything fails, the containers do not start.
This gate enforces the boundaries described on the isolation page: it stops Speedwave from starting whenever the rendered compose or your host state does not match them.
Fail-closed, no exceptions
Section titled “Fail-closed, no exceptions”A single rule violation blocks startup, with no override. speedwave check and speedwave enforce this from the CLI; Desktop shows a blocking overlay instead. See the CLI commands reference for the full command set.
speedwave check alone only reports violations. The normal start paths also fix incorrect permissions first. Ownership problems are never auto-fixed, since that needs root, so you get remediation steps instead. A YAML parse failure stops it with one parse error.
What it checks
Section titled “What it checks”The rules below cover the same credential boundaries described in how credentials are handled. Every rule runs, and you get every violation in one list.
| Group | What it covers |
|---|---|
| Container hardening | All Linux capabilities dropped, privilege escalation blocked, claude/mcp-hub/proxy read-only with a non-executable /tmp |
| Tokens and secrets | claude and mcp-hub block credential-like env vars beyond a small allowed set; claude cannot carry external LLM provider keys |
| Network | Ports bind to 127.0.0.1 only, claude never mounts the container engine’s socket, built-in MCP workers expose no ports |
| Container identity | Containers run as the fixed non-root user |
| Proxy mounts | The per-project proxy container’s volume mounts match an exact, pinned profile |
| Plugins | No privileged mode, no host network, manifest present, volume mounts matching an exact allowed set |
| SharePoint and Slack | Each integration follows its own volume profile: correct paths, modes, and no extra mounts |
| Host filesystem (Unix only) | Directories and files under ~/.speedwave/ have expected permissions and ownership |
The host filesystem check is a no-op on Windows. It reads file metadata without following symlinks, so a planted symlink is skipped.
What happens on a violation
Section titled “What happens on a violation”For each violation you see the container, the failed rule, a message, and a remediation, from the CLI or Desktop’s blocking overlay. A separate OS prerequisite check (WSL2 on Windows) blocks startup the same way.
What it does not cover
Section titled “What it does not cover”SecurityCheck validates the rendered compose YAML and host filesystem state under ~/.speedwave/. It skips Desktop’s own host-process commands, such as outbound URL validation, host audio, or the executor sandbox. Those are documented elsewhere.