SANDBOX_BACKEND=local unusable from published artifacts (sandbox-base has no exec daemon); buildx attestation images misreported as "image not found"

[noreplyciy]

Evaluating QM 0.1.4 as a self-hosted deployment (target: docker) on Windows + Docker Desktop. Two findings, one blocking and one a genuine bug in the failure path.

1. SANDBOX_BACKEND=local cannot work from published artifacts

check.js requires sandbox.app for both the docker and fly targets, and config.js only accepts "sprites" or "aws" for sandbox.backend — but core itself accepts a third value:

SANDBOX_BACKEND must be set explicitly in production — use sprites, aws, or local.

local is reachable by setting env.core.SANDBOX_BACKEND, since docker.js spreads config.env[service] after the computed sandbox env. Core starts fine and chat works.

Agents then can't execute anything. local-sandbox.ts runs the sandbox and polls /health, but nothing ever listens, because the published image has no exec daemon:

$ docker inspect ghcr.io/yc-software/qm/sandbox-base@sha256:52cb44a6e9d1...
Cmd=[sh -c while true; do sleep 3600; done]

The same is true of an image produced by qm sandbox publish (it inherits that Cmd). The image ships claude, codex, node, gh, aws, but nothing serving the /health, /read, /exec API that local-sandbox.ts calls, and /app/src/sandbox/ in the core image contains only client code. That daemon appears to come from npm run sandbox:local:build, which lives in the QM source repo rather than in anything published.

Question: is a published local sandbox image (or the build recipe) planned for people deploying from released artifacts rather than the monorepo? Right now local is discoverable from core's own error message but unreachable in practice, and sprites needs a token from an org that has Sprites enabled — sprite org auth returns sprites not enabled for this organization, email support@fly.io — so a self-hosted evaluator has no working sandbox backend without going through Fly support first.

2. Bug: buildx attestation images make preflight report "image not found"

local-sandbox.ts preflight runs:

docker image inspect -f '{{.Id}} {{if .Config.Labels}}{{index .Config.Labels "qm.sandbox-fingerprint"}}{{end}}' <image>

Images built by buildx with attestations — which is the default for Docker 29, and what qm sandbox publish emits ("exporting attestation manifest" / "exporting manifest list") — inspect as an OCI index whose .Config has no Labels key at all. The Go template then fails:

template parsing error: template: :1:20: executing "" at <.Config.Labels>:
map has no entry for key "Labels"

That exits non-zero, so the code reports:

local sandbox image <image> not found — run `npm run sandbox:local:build`

The image is present and valid; only the template failed. docker image inspect -f '{{.Id}}' <same image> succeeds. This sent me down a long wrong path — I rebuilt the image twice before checking the exit path itself.

Suggested fix: distinguish a non-zero inspect caused by a template error from a genuine missing image (or query labels via {{json .Config}} / a separate call, and treat a missing Labels key as "no fingerprint" rather than "no image"). Building with --provenance=false --sbom=false works around it.

Happy to supply more detail or test a patch.

[yzxcj797]

Fixing part 2 (the preflight bug) — confirmed the failure path exactly as reported: images built by buildx with attestations inspect as an OCI index whose Config has no Labels key, so the combined {{.Id}} {{if .Config.Labels}}...{{end}} template errors and exits non-zero, and the preflight misreports a present, usable image as not found — run npm run sandbox:local:build.

Fix: split the probe in two — docker image inspect -f {{.Id}} decides existence (works for index and manifest images alike), and the fingerprint template becomes a second, tolerated probe whose failure just means "no fingerprint" (skipping the stale-image comparison instead of failing the run).

Regression test extends the fake docker with the exact attestation behavior ({{.Id}} inspects fine, the labels template fails with the real map has no entry for key "Labels" error) and asserts provision no longer rejects with the not-found signature — verified it fails on main with precisely that misreport and passes with the fix.

Can't meaningfully address part 1 from a PR (the published-artifacts question is a maintainer decision), so keeping this scoped to the failure-path bug.