v0.11.0 — az capability + lazy install framework
az capability and a reusable lazy-install framework — opt-in tools too large to ship in the base image now install inside the container on first activation, with auth dirs persisted on the host.
The gh and docker caps already pre-install their CLIs in every image. That doesn't scale to cloud-vendor tooling: azure-cli is ~250 MB, awscli ~80 MB, google-cloud-cli ~200 MB. Pre-installing all of them would inflate the image for every user. The new lazy-install framework keeps the base image lean and pushes the cost to users who actually opt in. az is the first cap to use it; aws and gcloud are queued to follow the same pattern.
Features
azcapability —cleat config --enable azorcleat --cap azmounts~/.azure(read-write) soaz logintokens persist on the host acrosscleat rm,cleat nuke, andcleat rebuild. Same auth-persistence model asgh- Lazy-install framework — caps listed in the new
LAZY_CAPSregistry have an install script atcli/docker/cap-installs/<cap>.sh. Afterdocker run -d, cleat probes the container withcommand -v <tool>; if absent, it runs the install script viadocker exec --user rootwith a spinner. Subsequent starts hit the fast path and skip entirely. Aborts cleat on install failure rather than silently launching a half-broken environment - Per-container install scope — the tool itself lives inside the container (lost on
cleat rm, preserved acrosscleat resumeand Docker daemon restarts). Auth dirs always bind-mount from the host, so credentials survive every container lifecycle operation - Audit-friendly install path —
cap-installs/az.shspells out the apt repo + GPG keyring steps explicitly (Microsoft's official Debian 12 repo atpackages.microsoft.com) rather than pipingaka.ms/InstallAzureCLIDebto bash, so each step is reviewable
Changes
KNOWN_CAPSaddsaz; the config picker,cleat config --list, and--capvalidation pick it up automatically_run_lazy_installsis invoked fromcmd_start,cmd_resume, andcmd_claudebeforeexec_claude— so any path that launches Claude in a container with a lazy cap active gets the install_lazy_cap_is_installedis exposed as an override point so tests can simulate both the missing-tool and present-tool branches without an actualcommand -vround-trip- 632 (+12) behavioral tests across 24 files — 9 az-cap unit tests in
capabilities.bats(mounts, registration, description, install/skip/no-op/failure paths), 2 smoke tests insmoke.bats(--cap az --help,cleat config --enable azround-trip) - 36 mutations caught
- Full design in
concept/10-capabilities.md→ "Lazy install capabilities" section + dedicatedazcap section