Skip to content

v0.11.0 — az capability + lazy install framework

Choose a tag to compare

@coder-pm coder-pm released this 25 Apr 19:55
· 270 commits to main since this release

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

  • az capability — cleat config --enable az or cleat --cap az mounts ~/.azure (read-write) so az login tokens persist on the host across cleat rm, cleat nuke, and cleat rebuild. Same auth-persistence model as gh
  • Lazy-install framework — caps listed in the new LAZY_CAPS registry have an install script at cli/docker/cap-installs/<cap>.sh. After docker run -d, cleat probes the container with command -v <tool>; if absent, it runs the install script via docker exec --user root with 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 across cleat resume and 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.sh spells out the apt repo + GPG keyring steps explicitly (Microsoft's official Debian 12 repo at packages.microsoft.com) rather than piping aka.ms/InstallAzureCLIDeb to bash, so each step is reviewable

Changes

  • KNOWN_CAPS adds az; the config picker, cleat config --list, and --cap validation pick it up automatically
  • _run_lazy_installs is invoked from cmd_start, cmd_resume, and cmd_claude before exec_claude — so any path that launches Claude in a container with a lazy cap active gets the install
  • _lazy_cap_is_installed is exposed as an override point so tests can simulate both the missing-tool and present-tool branches without an actual command -v round-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 in smoke.bats (--cap az --help, cleat config --enable az round-trip)
  • 36 mutations caught
  • Full design in concept/10-capabilities.md → "Lazy install capabilities" section + dedicated az cap section