Every released CLI predates desktop-runtime-check: PyPI's latest unsloth is
2026.7.5 and MIN_DESKTOP_BACKEND_VERSION stays 2026.5.3, so a field install is
version-compatible and simply lacks the subcommand. It then exits 2 with no
stdout, which read as a failed probe, and probe_managed_bin returned Stale
before consulting the capability cache, so a healthy install was force-repaired
and an offline user could not start at all. Fall back to the previous launch
probe, gated on 'desktop-runtime-check --help' (0 when the command exists, 2
when it does not), so a new CLI that crashes or times out still reports Stale.
Metadata outlives the package it describes. Hatchling wheels store
.dist-info/METADATA as the first archive entry (verified: index 0 for both
fastapi and typer), so an unpack killed midway leaves a readable version for
modules that never landed and the probe called the venv ready. RECORD is
written last, so a missing file list marks that unpack; checked against all 298
distributions in a real venv with no false positives. This supersedes my
earlier reasoning that the metadata is written last, which was wrong.
run.py raises SystemExit at import for a rejected setting such as
UNSLOTH_CPU_THREADS, and SystemExit is not an Exception, so it escaped the
handler and emitted no payload at all. Report it as backend_startup_failed and
keep it out of the repair path: no reinstall can change an inherited
environment value, so repairing would replace a healthy install and fail again.
Also clear the install marker when the installer fails to spawn, the one
terminal outcome that still left it behind.
8f343038ef