feat(cli): Docker in the sandbox — nested daemon with proxied egress

[shejnowicz]

Fixes #70. Implements the sidecar-daemon approach from the issue's design draft, concretized after a manual routing spike: dind in its own network namespace with wg-client as its gateway, so egress from agent-launched containers provably transits mitmproxy.

Why not the draft's preferred option

The Sysbox runtime swap conflicts with sandcat's topology: the agent lives in network_mode: service:wg-client, which Sysbox does not support (it requires its own namespaces). Rootless dockerd in the agent conflicts with no-new-privileges (#90) — setuid newuidmap is blocked. The privileged sidecar is the option that works today, on stock Docker Desktop, with the current hardening intact.

Design

One include does everything: sandcat init --features docker appends sandcat/compose-docker.yml, which extends three services at once — the dind service, the agent's socket-volume mount, and wg-client's SANDCAT_DIND_GATEWAY flag.

• dind (pinned docker:27.5.1-dind, per security: pin mitmproxy image chain + rtk installer (Phase 1 of #20) #100 policy) runs the nested dockerd in its own netns. Its entrypoint wrapper installs the mitmproxy CA before dockerd starts (Go loads the x509 pool once — pulls pass the TLS bump), replaces the default route with wg-client fail-loud (no route → no daemon, never an unproxied fallback), publishes the matching docker CLI onto the socket volume (no version drift), and chgrps the socket to the vscode gid.
• wg-client NATs the compose subnet into wg0 and drops every other forward — routing through the gateway leads only INTO the policy path; the docker network and host are unreachable through it. No sysctl needed (Docker enables ip_forward in bridge-network namespaces; /proc/sys stays RO).
• Agent sees DOCKER_HOST + CLI via a guarded /etc/profile.d/sandcat-docker.sh (the fix(cli): export Java trust-store settings to all shells #109 pattern) — images built without the feature are unaffected.
• The host docker.sock appears nowhere in the generated project.

Answers to the issue's open questions: baseline = sidecar (Sysbox blocked by the netns constraint, not just Colima); placeholders are not propagated into inner containers by default; the dind service participates in normal compose lifecycle (depends_on wg-client healthy, restart: unless-stopped).

Test plan

• bats: full 16/16 suites (new: enable_docker idempotency, compose-docker template contract incl. a no-host-socket guard, setup_dind_gateway rules, feature parsing)
• Hands-on integration, everything wired by sandcat init --features docker (no manual steps):
  • stack up with dind healthy; agent has DOCKER_HOST and the published CLI (27.5.1)
  • docker run --rm alpine from the agent works on the nested daemon
  • image pull through the tunnel (registry over the TLS bump with the injected CA)
  • from an inner container: http://example.com → 200; https with the mitm CA → 200; POST → "Blocked by network policy" — the proof that inner egress transits mitmproxy
  • dind's default route via wg-client confirmed; no host docker.sock anywhere; agent baseline unregressed (GET 200/POST 403, no sudoers, no CA private key)
• Docs: new Configuration → Docker in the sandbox page (mechanism, caveats: privileged rationale, inner-container CA trust, placeholder policy)

Follow-up commits after further integration testing (both issues found by exercising the acceptance criteria, not by review):

• CLI plugins: only the bare docker binary was published — docker compose/docker build are client-side plugin binaries. dind now publishes cli-plugins/ onto the socket volume and the profile script links it into ~/.docker/cli-plugins. Verified live: docker compose 2.33.0 and docker buildx v0.20.1 from the agent.
• BuildKit vs the GET wildcard: BuildKit resolves manifests with HEAD, which allow * GET blocks — docker build failed 403 while pulls (GET path) worked. New host-scoped docker-registry network preset (Docker Hub + ghcr.io), seeded at the top of the project's network list by --features docker. Verified live with docker build --pull --no-cache (forces the HEAD): image builds, marker runs, and the POST-from-inner-container check still returns "Blocked by network policy". Also TESTCONTAINERS_HOST_OVERRIDE=dind is exported (inner ports publish in dind's namespace).
• A satisfying side-note: while re-testing, the pre-preset addon in the test project hit the feat(mitmproxy): predefined network allowlist presets #105 fail-loud path exactly as designed — mitmproxy refused to start on the unknown preset instead of running a weaker policy.

Not covered (noted for follow-up): a Testcontainers-based JVM suite run (acceptance item in #70) and the VS Code Reopen-in-Container pass — the compose project is IDE-agnostic so it should hold, but it hasn't been exercised in this PR.

🤖 Generated with Claude Code