Installer (macOS): no Tier 0 path — a Mac with Docker already running is still forced through the admin/sudo gate

[LukasWodka]

Summary

install_macos has no Tier 0 path. On a Mac where a container runtime is already installed and running — the exact condition the host audit classifies as Tier 0, "zero root, no privileged steps" — step b still runs _macos_require_admin and then preflight_sudo, demanding an administrator password to install a runtime that is already installed and answering.

install_linux has had this branch since RFC 0001 #1175. macOS never got it.

Observed on v1.9.34, macOS/arm64, Docker Desktop running:

Host check
Container runtime  Docker 29.7.2 — docker info OK               ✓
Privilege          regular user; sudo needs a password            –
→ Install tier  Tier 0 (zero root) — a container is already runnable; no privileged steps.

b) Installing what tracebloc needs

⚠  Installation did not complete.

with the log showing it get as far as the admin check and no further:

step b: install_macos starting (OS=Darwin ARCH=arm64 tier=0)
step b: admin check passed

Root cause

install_macos is a flat sequence with no tier branch:

install_macos() {
  _macos_require_admin
  preflight_sudo
  install_homebrew
  install_docker_desktop
  assert_amd64_emulation
  install_macos_cli_tools
  _install_macos_autostart || true
}

Compare install_linux, which short-circuits:

if [ "${INSTALL_TIER:-}" = "0" ]; then
  info "Using the container runtime already on this machine — no administrator rights needed."
  _install_userspace_tools    # ~/.local/bin, no sudo
  _tier0_gpu_flags
  return 0
fi

install_macos_cli_tools compounds it: it hardcodes TB_TOOLS_DIR=/usr/local/bin and TB_TOOLS_SUDO=sudo with the comment "macOS has no Tier/rootless model". So even if the admin gate were skipped, writing the pinned tools would still prompt for a password.

Impact

• Every Mac that already has Docker running takes the privileged path it was explicitly classified as not needing.
• On a non-admin Mac it fails outright with the managed-Mac remedy — even though Tier 0 is precisely the case RFC 0001 opened up: a user with no admin rights on a machine where someone else provisioned the runtime.
• Wasted work in the common re-run case: Homebrew and Docker Desktop are both re-checked when both are demonstrably present.

Proposed fix

• Add the Tier 0 branch to install_macos: skip the admin gate, sudo priming, Homebrew and the Docker Desktop install; still run assert_amd64_emulation, install the CLI tools, and set up login autostart (a per-user LaunchAgent needs no admin).
• Give install_macos_cli_tools the same no-sudo target Linux uses at Tier 0 — ~/.local/bin, on PATH — and call _persist_tools_on_path (which self-gates and is already macOS-aware).
• Leave every other tier byte-identical, including an unset INSTALL_TIER (a stale bootstrap that never fetched probe.sh), which must keep the privileged path.

Acceptance

• Tier 0 → no _macos_require_admin, no preflight_sudo, no Homebrew, no Docker Desktop install; tools land in ~/.local/bin.
• Tier 2 and unset tier → unchanged.
• bats coverage for each, mutation-real against the missing branch.