Route desktop leases to the desktop base and fix silent create failures

[malpern]

Two lab defects that compound. create failed with no diagnostic, and when it did succeed a --desktop lease landed on the wrong base.

Silent create failure

remote.sh runs over a non-interactive SSH shell, which does not source the login profile and therefore has no Homebrew on PATH. The repository sets core.hookspath, and those hooks call git-lfs. With git-lfs unreachable the hook exits non-zero and set -e aborts mid-command — create died immediately after staging its archive, reporting only exit 2 with nothing on stderr.

The script now sets the PATH it needs rather than depending on how it was launched. That matches the convention the launcher branches in warmup_desktop/warmup_lease already follow.

Desktop leases landed on the wrong base

base_for() took only (macos, lane) and ignored the desktop flag, so --desktop still resolved to keypath-macos-N. That base has no console session, no Homebrew, and no desktop tooling — desktop-bootstrap failed on it and semantic UI automation could never run, while the lease itself looked healthy.

desktop is now threaded through to base_for, routing macOS 26/27 desktop leases to keypath-macos-N-desktop.

Managed lanes are deliberately excluded: only the managed base carries MDM enrollment, so a managed desktop lease keeps its base and takes desktop capability from the launcher. warmup_lease's remaining call sites are reached only when desktop is 0, so they keep the default.

Why it regressed invisibly

The existing desktop tests asserted the lease id but never which base was used. They now assert the recorded base_name for macOS 26 and 27, and that a managed desktop lease keeps the managed base. Reverting base_for makes the suite fail, confirming the assertions bite.

Note: in test mode warmup_desktop calls the stub launcher without --parallels-template, so the calls log cannot carry that flag — the recorded base_name is the assertable signal.

Verification

Against the real lab, through the normal controller with no PATH workaround:

source=KeyPath macOS 27 Desktop Base
type=template-keypath-macos-27-desktop-base
ready ssh=keypathqa@10.211.55.62:22

Console user in the guest is keypathqa — the session is inherited as intended. Previously this same command produced the plain base. Scripts/lab/tests/keypath-lab-tests.sh passes; lease was artifact-collected and destroyed.

Follow-up, not fixed here

The desktop base itself still lacks tooling: no Homebrew, no peekaboo, no mcporter, and /Applications holds only Safari and Utilities. So desktop-bootstrap --install-tools still fails on it. That is a base-image provisioning task (install tools, re-checkpoint), not a code fix, and it is the same step docs/testing/remote-installer-lab.md already records as outstanding for the macOS 26 base. Worth noting because a6f4fa161 marked this base proven with "signed Peekaboo Lab Host approvals," which does not match the base as it exists today.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[claude]

Reviewed the diff. Two things worth a second look, otherwise this looks solid (the base_for desktop-base logic and its managed-lane exclusion are consistent with the new tests):

1. PATH ordering in the new bootstrap loop (Scripts/lab/remote.sh:4-13): the loop processes /opt/homebrew/bin first, then /usr/local/bin, prepending each in turn. Since each iteration prepends to the front, the final order ends up /usr/local/bin:/opt/homebrew/bin:... — the reverse of the stated intent. On Apple Silicon this means an Intel/Rosetta git-lfs (if present under /usr/local/bin) would shadow the native /opt/homebrew/bin one. Probably harmless for just satisfying the hook, but worth confirming that's intentional since it's the opposite of typical Homebrew-on-ARM precedence.

2. Managed + desktop combo verifies base_name only, not actual desktop capability: the new test (managed_desktop_create, around line 704 in keypath-lab-tests.sh) confirms the manifest keeps base_name=keypath-macos-26-managed and desktop_enabled=true, matching base_for's intent that desktop capability comes "from the launcher" rather than the base image for managed lanes. But nothing in the diff shows/tests that the launcher actually applies --desktop (or equivalent) in this path — only the manifest fields are asserted. Worth double-checking the functional wiring exists, since a regression there would silently produce a managed lease with desktop_enabled=true but no real desktop capability, and the test suite wouldn't catch it.

Minor: the new desktop-base test coverage only exercises macOS 26 for the managed+desktop path (and 27 for the plain unmanaged+desktop path) — no test combines macOS 27 with managed-functional + desktop. Not blocking, just a coverage gap given base_for's branch covers both 26 and 27.

[claude]

Reviewed the diff. One thing worth double-checking before merge:

base_for desktop-flag threading may be incomplete. The new desktop param (base_for "$macos" "$lane" "$desktop") is only threaded through the 4 call sites touched in this diff (warmup_desktop x2, write_provisional_lease_manifest, create_lease). Since desktop defaults to 0 when omitted, any other base_for call site elsewhere in remote.sh that isn't part of this diff (e.g. resume/restart/reuse-existing-lease logic, if any) would silently fall back to the non-desktop base for a lease that's actually flagged for desktop use, rather than erroring. Worth a quick grep -n 'base_for' Scripts/lab/remote.sh to confirm every call site that needs desktop-awareness got updated.

Everything else looks solid: the PATH-bootstrap fix for non-interactive SSH (matches the existing /usr/local/bin:/opt/homebrew/bin ordering convention used elsewhere in the file), the disk_reserve_path/absolute-binary-path hardening for the disk guard, and the new managed+desktop / desktop-base regression tests are all correct and well-justified by their comments.