Manuals / Docker Sandboxes and Docker Agent 101 / Part 7 · Operating It
7.4

kit-tck, sbx diagnose, and the claims this manual checked

Every claim this manual repeats from Docker's pages or the community was checked against a capture or marked unverified, and this section is the ledger.

A vendor page says that credential values never enter the VM. A Hacker News thread from 2026-08-10 says the proxy re-signs every certificate, and a podcast from 2026-09-26 says nobody audited the boundary. You want to know which of those three someone checked. When you finish this section, you can say which claims this manual verified, with which file, and which it only reports.

The ledger

Each row names the claim and its source, the verdict, and the capture file behind the verdict. A verdict of confirmed means a recorded file shows the behaviour. Contradicted means a file shows the opposite. Disputed means two sources disagree and no capture settles it, and unverified means no capture was planned or recorded.

Claim and where it is madeVerdictEvidence
credential values never enter the VM (docs, Security model)confirmed10-env-sentinel.txt has M101_RECV_KEY=sbx-cs-<rand> and ANTHROPIC_API_KEY=proxy-managed, and 10-receiver.log shows the host receiver got Bearer m101-dummy-receiver-0000
the secret is injected only for a bound host, and the whole header is replaced (HN 2026-08-10, C34)confirmed, both sides10-swap-curl.txt: 204 on host.docker.internal:18080 and 000 on gateway.docker.internal:18080, while 10-receiver.log shows the swap with and without Bearer, and in X-Demo
outbound TCP is blocked unless a rule allows it (docs, Default security posture)confirmed09-blocked.txt: 403, and 09-check-verbose.json: "deny_kind": "implicit"
each sandbox has its own Docker Engine with no path to the host daemon (docs, Security model)confirmed in part04-guest.txt: Docker Engine 29.8.1 server inside, user agent in group docker, and no probe for a host path was run
--clone commits reach the host through sandbox-<name> (help, sbx create)confirmed08-clone-host.txt: git fetch sandbox-m101-clone brought 81e11df from sandbox, and 08-clone-commit.txt: a push to /run/sandbox/source is rejected
the guest uses 16 KiB pages on Apple silicon (blog 2026-05-26, C45)confirmed04-guest.txt: getconf PAGESIZE prints 16384
the proxy is gateway.docker.internal:3128 (issue #12, C26)confirmed04-env.txt: HTTPS_PROXY=http://gateway.docker.internal:3128, and PROXY_CA_CERT_B64 set
HTTPS is intercepted and re-signed (issue #12, HN 2026-08-10)not checked09-allowed.txt shows the CONNECT tunnel and a cloudflare reply, and no certificate chain was read
one MCP gateway endpoint per sandbox (docs, Architecture)confirmed11-static-inside.txt: MCP_GATEWAY_URL=http://mcp-gateway.docker.internal/mcp, and 11-gateway-tools-static.json: ask_wiki_question
27 toolset types, and transfer_task is not one of them (schema, C56)confirmed16-toolsets.txt: 27 rows, neither implicit name
the sbx kit commands are v1 and v2 tooling (C13)confirmed13-kit-v3-validate.txt: "is a v3 source kit and this load path has no kit builder configured", and 12-validate.txt: VALID
a kit signature verifies with sbx kit sign and verify (docs, Build and distribute kits)not checkedno sign or verify step was recorded, only 13-kit-builder-status.txt
a local model runs with no key (docs, Use local and hosted models)confirmed25-doctor.txt: every provider credential not set, Docker Model Runner reachable with docker.io/ai/qwen3:4b, and 25-run-dmr.txt answers Hello live. 18-cassette-head.txt shows the recorded requests going to localhost:12434, and 27-inside-run.txt answers from inside the VM. The 8B ai/qwen3:latest failed to pull (25-model-pull-latest.txt)
local use needs a Docker sign-in (docs, FAQ, disputed in HN 2026-08-10 and issue #321, C15)confirmed in part02-diagnose.txt lists Authentication as a check, the kit's prerequisites include sbx login, and help-sbx-cloud.md notes a TLS attempt to login.docker.com on every --help
sbx policy approval is not a command (the v0.47.0 help tree, C16)unverified09-blocked.txt: the 403 body says "Review and respond with: sbx policy approval ls", and no capture ran that command
the VMM is libkrun (talk 2026-01-14, HN 2026-08-10, C4)unverified00-sbx-version.json names no runtime, and 04-guest.txt shows kernel 7.0.14 and nothing more
a sandbox starts in tens of milliseconds (talk 2026-02-10, C29)not checkedthe timing runs planned as K35 were not recorded
an allowed host can carry data out (HN 2026-08-10, talk 2026-04-07)disputedboth sides are printed in the proxy section, and no capture tested it
a microVM HTTP API, a Kubernetes runtime, Warp Oz (blog 2026-05-26, blog 2026-08-21, talk 2026-03-31)unverifiedno Docker page confirms any of them (C105, C106)
an independent audit of the boundary existsnone foundthe podcast of 2026-09-26 says none exists, and the corpus has none (T24)
sbx ls hangs on macOS (#163), Windows start fails (#350)not reproduced99-final-state.txt: sbx ls answered at the end of the run
a sandbox stops itself after the last session ends (not in the docs)observed04-auto-stop.txt: "auto-stop grace period expired, stopping runtime"
Fig. 7.4confirmed by a file, or only reportedcomparison
Confirmed by a file, or only reported Two columns. The left column lists eight claims a recorded capture file confirms: the sentinel inside and the real secret outside, default deny on example.com:443, a private Docker Engine 29.8.1 inside, commits fetched through the sandbox-m101-clone remote, the proxy at gateway.docker.internal:3128, MCP_GATEWAY_URL set inside the sandbox, docker-agent toolsets printing 27 types, and ai/qwen3:4b answering on Docker Model Runner with no provider key set. The right column lists six claims. Five are reported without a test: a MITM proxy that re-signs HTTPS, libkrun as the VMM, a start in tens of milliseconds, a verified kit signature, and sbx policy approval missing from the help although a 403 body names it. One rose box marks the disputed exfiltration path. CONFIRMED BY A CAPTURE FILE REPORTED, NOT TESTED HERE sentinel inside, real secret outside 10-env-sentinel.txt, 10-receiver.log default deny on example.com:443 09-blocked.txt, 09-check-verbose.json private Docker Engine 29.8.1 inside 04-guest.txt fetched via sandbox-m101-clone 08-clone-host.txt proxy gateway.docker.internal:3128 04-env.txt MCP_GATEWAY_URL set inside 11-static-inside.txt toolsets prints 27 types 16-toolsets.txt ai/qwen3:4b on DMR, no key set 25-doctor.txt, 27-inside-run.txt HTTPS re-signed by a MITM proxy issue #12, not checked the VMM is libkrun talk 2026-01-14, unverified a start in tens of milliseconds talk 2026-02-10, K35 not run a kit signature verifies sbx kit sign, not recorded sbx policy approval is not a command 403 body names it, never run allowed host as exfiltration path HN 2026-08-10, both sides printed
Eight claims were confirmed by a recorded file, five are reported without a test, and the community disputes one more. Left, each confirmed claim with the capture file that shows it, coloured by the layer it belongs to. Right, dashed boxes are claims this manual reports without a test, and the rose box is the claim the community disputes.

sbx diagnose, the only self-check

sbx diagnose: the one command that checks an installation, in the four groups that the captured output shows: Installation, Platform, Storage, and Connection. It takes --json, --output github-issue for a report to paste into an issue, and --upload to send diagnostics to Docker support.

the platform and connection checks on the recording hosttextFull log
  Platform
  ✓ Virtualization — supported
      kern.hv_support is 1
  ✓ mkfs.erofs — found
      /opt/homebrew/Caskroom/sbx/0.47.0/Sbx.app/Contents/libexec/mkfs.erofs, default block size <n> bytes, guest kernel page size <n> bytes
…
  Connection
  ✓ Version match — v0.47.0
  ✓ Socket — responsive
  ✓ SSH client config — not configured
  ✓ Authentication — authenticated

─────────────────────────────────────────
  13 passed
The Installation and Storage groups are cut. The byte counts and sizes are masked by the kit.

All 13 checks passed, and the JSON form in 02-diagnose.json carries the same rows with a summary of pass, warn, fail, and skip counts. The Platform group is where the microVM boundary section reads the hypervisor and the page size. sbx --cloud diagnose runs a different set, sign-in, the cloud API, and account access, and needs no daemon.

kit-tck, not run in this edition

kit-tck: the conformance suite of the Sandbox Kit Specification v3, with two independent halves, one for a published kit artifact and one for a runtime. The conformance page of the specification repository describes both (our source record). kit-tck validate <reference> judges a published artifact against the publishing and OCI layout rules, and the BuildKit frontend runs the same checks before it exports. kit-tck runtime --adapter <path> drives an adapter, an executable with verbs such as capabilities, create, exec, stop, start, recreate, and rm.

The suite judges what the runtime does through those verbs. An adapter exits 2 when it refuses a request by policy, and any other non-zero code is a failure. A runtime that cannot provide a required capability must therefore refuse the kit.

the two suites and the artifact commandstextFull log
task tck:kit REF=docker.io/me/sbx-kit-gh:1.0.0   # is this artifact a conforming Kit?
task tck:runtime ADAPTER=./my-adapter            # does this runtime behave as the pages require?
…
kit-tck validate docker.io/me/sbx-kit-gh:1.0.0 --verbose
kit-tck validate docker.io/me/sbx-kit-gh:1.0.0 --format json
Four lines from the README of docker/sandbox-kit-spec. The task lines run from a checkout, and the kit-tck lines run a released binary.

Released kit-tck binaries are attached to each GitHub release of the specification for Linux, macOS, and Windows. kit-tck inspect reads a kit's descriptor and recipe without judging it. The suite places three known values in the adapter's environment, KIT_TCK_HOST_SENTINEL, KIT_TCK_BOUND_SECRET, and KIT_TCK_SKILL_NAME. A leak of host environment or of a bound secret is then visible.

This edition did not run it. The capture kit built a v3 artifact and pushed it to a local registry (28-buildx.txt, 28-manifest.json), but no kit-tck step ran against it.

The agent regression check

For agent runs, the planned check is docker-agent sessions diff --fail-on-divergence, which compares the tool calls of two recorded sessions, not the prose of the assistant. It stops at the first divergence. The capture kit ran it on recorded sessions (21-sessions-diff.txt). Two replays of one run are identical across five turns, and a run that called shell first diverges at turn 0 and exits 1. A relative reference such as -1 needs -- before it, or the parser reads it as a flag. The sessions section explains the session store.

Docker Sandboxes (sbx) and Docker Agent (docker-agent) sbx 0.47.0, docker-agent 1.149.0 · bf4169c · 2026-10-07 · Edition 2026.10