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 {{docs-sbx Security model}}. 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.

Fig. 7.4confirmed by a file, or only reportedcomparison

Original SVG

Original source

id: fig-7-4
kind: comparison
title: confirmed by a file, or only reported
claim: Eight claims were confirmed by a recorded file, five are reported without a test, and the community disputes one more.
caption: 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. From the files named in each box.

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 {{help-sbx sbx diagnose}}.

  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

title: the platform and connection checks on the recording host
source: capture/out/02-diagnose.txt
lang: text
note: The Installation and Storage groups are cut. The byte counts and sizes are masked by the kit.
---
  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

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 {{docs-sbx Use cloud sandboxes}}.

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.

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

title: the two suites and the artifact commands
source: research/sources/kit-spec-extras.md
lang: text
note: 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.
---
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

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 {{help-agent docker-agent sessions diff}}. 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.

- Treat a claim as confirmed only when [a captured run](manuals/docker-sandboxes-101/capture/out) shows the behaviour.
- Run `sbx diagnose` first and attach `--output github-issue` to any report.
- Run `kit-tck validate` on a kit you publish, and read its findings by the specification section they name.
- Keep two recorded sessions per agent and compare them with `sessions diff --fail-on-divergence`.

Sources: docs-sbx Security model, Default security posture, Architecture, FAQ, Use cloud sandboxes, Build and distribute kits, Use local and hosted models (research/sources/docs-sandboxes.md); help-sbx sbx diagnose, sbx create (research/sources/help-sbx.md); help-agent docker-agent sessions diff (research/sources/help-docker-agent.md); research/sources/kit-spec-extras.md (README Conformance, docs/spec/conformance.md); research/sources/help-sbx-cloud.md; research/conflicts-register.md rows C4, C13, C15, C16, C26, C29, C34, C45, C56, C105, C106 and the community rows of research/plan.md; capture/out/00-sbx-version.json, 02-diagnose.txt, 02-diagnose.json, 04-auto-stop.txt, 04-env.txt, 04-guest.txt, 08-clone-commit.txt, 08-clone-host.txt, 09-allowed.txt, 09-blocked.txt, 09-check-verbose.json, 10-env-sentinel.txt, 10-receiver.log, 10-swap-curl.txt, 11-gateway-tools-static.json, 11-static-inside.txt, 12-validate.txt, 13-kit-builder-status.txt, 13-kit-v3-validate.txt, 16-toolsets.txt, 18-cassette-head.txt, 21-sessions-diff.txt, 25-doctor.txt, 25-model-pull-latest.txt, 25-run-dmr.txt, 27-inside-run.txt, 28-buildx.txt, 28-manifest.json, 99-final-state.txt