Auto-provision CI tools (node, npm, gh) in runner environments

[nicktallen]

Problem

New runners start with a minimal environment. Users frequently need common CI tools (Node.js, npm, gh CLI, etc.) but must install them manually or handle it in their workflow YAML.

Proposed Solution

Auto-detect and provision commonly needed CI tools when a runner is created, based on the repo's language/toolchain:

• Always install: gh CLI (for GitHub API access in workflows)
• Detect from repo: Node.js/npm (if package.json exists), Python (if requirements.txt/pyproject.toml), etc.
• User-configurable: Allow users to specify additional tools in runner config

Acceptance Criteria

• Runners auto-install gh CLI if not present in the environment
• Language detection from repo metadata provisions relevant toolchain
• Users can specify custom tool list in runner settings
• Tool provisioning runs at runner creation time (not per-job)
• Works for both user isolation and container isolation modes

Notes

Listed in README under "Planned Features." Filing to track formally.

[nicktallen]

Triage note — verification exists, provisioning does not

SetupWizard.swift (lines 88-96) checks for the presence of gh, git, and xcodebuild, but only verifies — it does not install missing tools. RunnerInstaller handles the GitHub Actions runner binary but not CI toolchain provisioning.

Implementation will need:

• Detection of missing tools (partially done in SetupWizard)
• Automated installation via Homebrew or direct downloads
• Per-runner or global provisioning option
• For container isolation: tool installation inside the container image or at container startup

---

Automated triage by mac-runner bot

[Peyton-Spencer]

Triage update — partially implemented in #66 (2026-03-25), keeping open for container-mode follow-up.

PR #66 (feat: auto-provision runner toolchains) shipped:

• gh CLI auto-provisioned before repo validation
• Language toolchain detection from repo root metadata at runner creation
• User-configurable settings.tools.extraPackages with settings UI for extra Homebrew packages
• Tests for package planning, config decoding, settings normalization, gh path detection

Per the PR notes: provisioning currently covers non-isolated and dedicated-user runners. Container-mode provisioning is explicitly out of scope for #66.

Remaining work to fully close this issue:

• Container isolation mode: install detected toolchain inside the container image or at container startup (ties into Support custom container images for containerized runners #44 — custom container images)
• Verify provisioning runs at runner-creation time only (not per-job) for the container path

Suggest splitting the container-mode piece into a separate issue if we want to mark this one done. For now, leaving open as P1 with reduced scope.