feat(daemon): probe the VM image's models in the background and carry them across upgrades

[zfy0701]

Problem

The VM strategy learned its runtime models only from a real session's turn (S2c), recorded against one image identity. Every upgrade changes the identity, so the record was discarded, and each runtime's VM entry in facts/daemon-runtimes advertised no models until a session of that runtime ran a turn in a VM. The console showed "0 models" for all of them. It was also a chicken-and-egg problem: an agent could not be configured from a VM catalog that only a session could fill.

Change

Probe the VM the way the host is probed, whenever the strategy is available.

• The cheap availability probe is unchanged. sandbox.microsandbox: false, no usable /dev/kvm or no image reference means nothing is installed, pulled or booted.
• Once it passes, the ready daemon runs a background task, once a run and never blocking startup. It installs msb and prepares the image when needed, as a first session would. Then it boots one probe VM (probe/models) through the manager's serialized start.
• Inside that VM it runs the host's runtime probe (probeRuntime: spawn, initialize, throwaway session/new, per-runtime budget) for each image runtime, one at a time, through the shim, via the in-process executor entry.
• Each runtime launches as its own local VM session would (prepareMicrosandboxLaunch, in a scope of its own under run/vm-probe), with this machine's credential step. The VM's mounts and credential bindings are the union of those launches.
• A runtime that disagrees with the others on a binding name, a mount, or another runtime's protected credential file is left out with a warning.
• Results go into strategies.microsandbox.models/modelsSource: probed. A failed probe keeps the previous list.
• The VM is drained and removed when the sweep ends. Shutdown aborts the sweep without waiting on it, so an in-flight pull cannot hold the drain. The next probe removes a probe VM that an earlier run left behind.
• Once shutdown has begun, nothing resumes. Readiness stops after msb's install, the manager's recovery and the image preparation, so a manager installed during shutdown is never adopted. A closed manager refuses to pull or to start or restart the preparation VM.
• The real-session capture stays as a refresh.

Carry the record across an image change. microsandbox/image-models.json is read whichever image wrote it. It is loaded at startup even before msb is installed, so an upgrade that also moves the msb pin starts from it too. Each runtime keeps its last list as cached until the new image's probe replaces it. There is no per-version matching.

The upgrade pre-pull does not probe. It runs as a separate short-lived process of the next release, with no runtime catalog, store or VM driver. The carried-over lists cover the new daemon until its own background probe replaces them a few minutes after it starts.

Docs: §5 of session-executors.md and daemon-sandbox-backends.md. "Boots no VM" now applies only to the availability probe; they also describe the background probe and the carry-over.

The console change (the model picker and the Decision rule editor reading the entry for the agent's strategy) follows in a separate PR.

Verification

• New test/microsandbox-model-probe.test.ts covers:
  • one VM with every runtime's own workspace and HOME, launched serially;
  • discard before and after, and boot before any runtime's budget;
  • placeholders bound once, and a conflicting binding left out;
  • a failing runtime reported while the rest still run;
  • a shutdown that stops the sweep.
• test/daemon-sandbox-capability.test.ts covers:
  • the previous image's list reported as cached at startup, before msb is installed;
  • the probe replacing it with probed and recording it;
  • a failure keeping it;
  • no probe when microsandbox is unavailable or microsandbox: false;
  • shutdown during the msb install or the manager's recovery adopting and preparing nothing.
• test/microsandbox-driver.test.ts covers:
  • the record carrying across a moved tag and a new image, and being replaced one runtime at a time;
  • shutdown during the image pull starting no preparation VM.
• The shutdown tests fail with the fence removed.
• Ran locally with --maxWorkers=2: those three files, plus daemon-model-selection, daemon-birth-strategy, executor-placement, model-catalog-daemon, daemon-k8s-mode, cluster-probe and runtime-prober (293 tests, all passing). Daemon typecheck (which includes the smoke script) and eslint on the changed files also pass.
• Not run locally: anything that boots a real VM needs Linux with KVM. scripts/smoke-microsandbox-runtime.mts gains a step that boots the probe VM. There it probes the daemon's fixture ACP agent, run inline by the image's Node, checks the exact model list it advertises, and checks that the VM is removed. CI's microsandbox smoke job runs it for this change. The first CI run showed the image's signed-out Claude adapter refusing session/new with an internal error; that is why the step now uses the fixture.

🤖 Generated with Claude Code . Claude Opus 5.5

[agentconnect-md-test]

The background VM probe introduces a shutdown race. When shutdown starts while msb installation or image preparation is pending, aborting the sweep does not stop microsandboxReady(). That readiness task can finish after stop() has passed its VM teardown and then continue preparing the image or creating its preflight VM. Please fence the readiness path at shutdown (including the post-install and post-pull continuations) so a probe started at readiness cannot create work after teardown. I did not find other blocking issues in the VM model probe. Focused tests were reviewed but not run here because this checkout has no installed dependencies.

_{sent by review-bot (Codex · gpt-6-sol) · open in session}

[agentconnect-md-test]

The update guards shutdown during msb installation, recovery, and the image pull. One preparation-VM race remains: probe() checks closed before awaiting VM creation, but stopAll() only drains environments and does not track that preparation VM. If shutdown starts while creation is pending, teardown can finish; creation then resolves and the probe runs its VM preflight after shutdown. Please fence that in-flight creation/preflight path before treating the shutdown issue as resolved. I found no other blocking issue in this revision. I reviewed the new tests but did not run them because this checkout has no installed dependencies.

_{sent by review-bot (Codex · gpt-6-sol) · open in session}

[agentconnect-md-test]

Approved. The preparation VM is now tracked through teardown, so shutdown waits for an in-flight creation to be cleaned up, and the closed-manager check prevents its preflight from running afterward. This resolves my prior blocking finding. I reviewed the added regression test and the new diff; I did not run tests locally because dependencies are not installed in this checkout.

_{sent by review-bot (Codex · gpt-6-sol) · open in session}

[agentconnect-md-test]

Approved. This revision replaces the test-wide msb install mock with a daemon constructor test seam; production still calls the same installMicrosandbox function, and the previously approved shutdown fencing is unchanged. I found no blocking issue. I reviewed the focused diff but did not run tests because dependencies are not installed in this checkout.

_{sent by review-bot (Codex · gpt-6-sol) · open in session}