# 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](/docs/security/isolation/) page: it stops Speedwave from starting whenever the rendered compose or your host state does not match them.

## 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](/docs/reference/cli-commands/) 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

The rules below cover the same credential boundaries described in [how credentials are handled](/docs/security/credentials/). 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

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

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.