docs(sandbox): publish the installed sandbox as a containerDisk

[r33drichards]

Follow-up to #3131. That PR merged before this section was finished, so these commits were left on the branch after it closed.

Adds Publish the installed sandbox as a containerDisk: turn the sandbox you just built by hand into an OCI image, push it to GHCR, and boot it locally and on Fleet — so nobody has to repeat the GUI install, least of all on Fleet.

Covered

• what a containerDisk is (an OCI image whose entire content is /disk/disk.img, which despite the name is qcow2)
• never sign in before exporting, with the three concrete places a credential survives
• creating the instance and fetching Java 17 without a Microsoft account
• the sb.stop() trap that deletes the session disk
• qemu-img convert -O qcow2 -c, the two-line Dockerfile, and --provenance=false --sbom=false
• GHCR being private on first push, and write:packages
• the os_type override, and why a Windows containerDisk otherwise boots SeaBIOS against a GPT disk
• five troubleshooting rows

Verified end to end while writing it

Published as ghcr.io/trycua/minecraft-agent:1.20.1 (repo created for this) and booted from it:

step	result
export	8 min 44 s, 7,697,072,128 bytes from a 3.40 GB overlay
build + push	6 min 28 s, one 7,631,366,006-byte layer, plain manifest — no unknown/unknown children
anonymous pull	manifest 200 with no credentials at all
local boot	pulled and booted; game files, Mesa beside javaw.exe, no accounts.json
Fleet boot	READY in 157 s

That Fleet boot is the first end-to-end confirmation that a custom Windows containerDisk on a public non-ECR registry runs there. It needs cua-sandbox 0.3.2 (#3148); before that the gateway refused any non-allowlisted image.

Two corrections in the last commit, both from running it

The retry advice was wrong. The section said to retry a BindDeadlineExceeded boot. Doing that returns 403 k8s request is not allowed on update template — both branches of pool_admission.rego are guarded by input.method != "PATCH", so a template can be created but never updated, and reusing the name makes the SDK patch it. The retry needs a new name. Sequence measured: cold attempt hit the 300 s deadline → same name returned 403 → fresh name reached READY in 157 s.

tunnel.forward(3000) does not work on every Fleet path. A sandbox from a pool claim carries the base FleetTransport, which does not implement port forwarding (pool.py:161); only a directly-created sandbox carries FleetCloudTransport. The error names the transport, not the cause.

Not verified

• The game was never launched from the published image. Prism will not add an offline account without a Microsoft account first, so there is no credential-free smoke test. Files verified present, not running. This image's Java came from the Installations tab rather than from a Launch, so Prism auto-detecting java-runtime-gamma is untested.
• The Fleet sandbox was torn down when the script exited, so the service URL was not curled afterwards. READY does imply the readiness wait passed.

Credential hygiene

The first export was discarded. It passed every filesystem check — accounts.json gone, in-guest findstr clean, Prism showing an empty account wizard — and the raw image still had 47 hits for the refresh-token prefix and profile name, in pagefile.sys, in file slack past a log's valid-data length, and in unallocated clusters the zero-fill missed. The published image was rebuilt without ever signing in. Scanned before publishing: refresh-token prefix 0, profile name 0. The 86 JWT headers present decode to RFC 7515 example data (http://example.com/is_root":true}), and the pristine base image already carries 58 of them.

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com

🤖 Generated with Claude Code