Plan: add mise and Homebrew to the dogfood Ubuntu images with mise-first PATH

Goal

• Make both dogfood Ubuntu images ship brew and mise.
• Ensure mise doctor does not complain about activation/PATH ordering in the shell entrypoints we support.
• Keep the implementation robust against the persistent /home/coder volume used by the dogfood template.

Verified context

• The relevant image definitions are:
  • dogfood/coder/ubuntu-22.04/Dockerfile
  • dogfood/coder/ubuntu-26.04/Dockerfile
• The dogfood template mounts a persistent home volume at /home/coder/ in
  dogfood/coder/main.tf:840-843, so required image-baked state should not
  live only under /home/coder.
• Both Dockerfiles already manipulate PATH in multiple places:
  • Go appended early (:26)
  • Cargo prepended (ubuntu-26.04/Dockerfile:202-206; mirrored in 22.04)
  • Node via nvm prepended (ubuntu-26.04/Dockerfile:245-255; mirrored in
    22.04)
  • Final coder PATH prepends /home/coder/go/bin
    (ubuntu-26.04/Dockerfile:348-358; mirrored in 22.04)
• COPY files / is already present in both Dockerfiles, so adding new global
  shell-init files is possible without Terraform changes.
• scripts/lib.sh:94-124 uses command -v for dependency detection, so PATH
  order is the practical repo-level behavior we need to control.
• .github/workflows/dogfood.yaml:99-126 builds both Ubuntu variants, and the
  22.04 image is still tagged latest, so both Dockerfiles must be updated in
  the same change.

Recommended implementation

Phase 1 — Bootstrap Homebrew and mise in both Ubuntu Dockerfiles

1. Update both Dockerfiles in parallel:
   • dogfood/coder/ubuntu-22.04/Dockerfile
   • dogfood/coder/ubuntu-26.04/Dockerfile
2. Add the minimum explicit Homebrew prerequisites that are missing from the
   current apt package set.
   • The images already install build-essential, curl, file, and git.
   • Audit whether procps must be added explicitly for Homebrew’s Linux
     requirements.
3. Install Homebrew in the supported Linux prefix:
   • Prefix: /home/linuxbrew/.linuxbrew
   • Keep the install/build logic in the Dockerfile, before USER coder.
   • Make the resulting prefix writable by coder before switching users.
     Prefer the smallest-diff approach that leaves brew install ... usable as
     coder.
4. Install mise to a stable image-owned path instead of relying on
   ~/.local/bin:
   • Preferred binary path: /usr/local/bin/mise
   • Use a pinned installation method that fits the current Dockerfile style
     (versioned release asset or otherwise explicitly pinned installer path).
5. Add defensive build-time sanity checks near the install steps so the image
   fails early if assumptions are wrong:
   • test -x /usr/local/bin/mise
   • test -x /home/linuxbrew/.linuxbrew/bin/brew
   • brew --version
   • mise --version

Quality gate: both Dockerfiles build locally, and the resulting container can
run brew --version and mise --version as coder.

Phase 2 — Make mise win PATH resolution by default

1. After USER coder in both Dockerfiles, define stable environment variables
   for the final shell/runtime behavior:
   • HOMEBREW_PREFIX=/home/linuxbrew/.linuxbrew
   • MISE_DATA_DIR=/home/coder/.local/share/mise
   • MISE_ACTIVATE_AGGRESSIVE=1 only if later shell activation proves
     necessary
2. Replace the final PATH composition so it resolves in this order:
   1. mise shims
   2. Homebrew bin/sbin
   3. Existing /home/coder/go/bin
   4. Existing image/system PATH
3. Keep the current Go/Rust/Node setup intact aside from the final PATH
   ordering. Add a short Dockerfile comment explaining that mise shims must be
   first so mise doctor and command -v resolve mise-managed tools ahead of
   Homebrew/system binaries.
4. Do not rely on image-baked mise state under /home/coder for the
   initial implementation. The goal here is binary availability and path
   precedence, not preinstalling shared mise toolchains.

Quality gate: in a fresh container as coder, echo "$PATH" shows
mise shims before Homebrew, and mise doctor/mise doctor path show no PATH
or activation problem in the tested shell entrypoints.

Phase 3 — Add shell-init hardening only if smoke tests prove it is needed

1. Start with the Dockerfile ENV PATH solution as the default behavior.
2. If dogfooding shows that supported login shells still need shell integration
   beyond the final ENV PATH, add minimal global shell-init files under:
   • dogfood/coder/ubuntu-22.04/files/etc/profile.d/
   • dogfood/coder/ubuntu-26.04/files/etc/profile.d/
3. If these files are needed, keep them narrowly scoped:
   • a Homebrew file that exports/evals brew shellenv
   • a mise file that only reinforces the intended shims-first behavior
4. Avoid touching per-user dotfiles in /home/coder; they are the wrong place
   for required image behavior because of the persistent home volume.

Quality gate: if profile.d files are added, login-shell smoke tests pass and
we do not introduce new PATH-order regressions versus the Dockerfile-only path.

Acceptance criteria

• Both Ubuntu dogfood Dockerfiles are updated in one change and still build.
• brew is installed in /home/linuxbrew/.linuxbrew and is usable as coder.
• mise is installed at /usr/local/bin/mise and is usable as coder.
• mise doctor does not report an activation/PATH-ordering problem in the
  shell entrypoints we verify.
• Final PATH precedence is:
  1. mise shims
  2. Homebrew bin/sbin
  3. existing user/tool paths
  4. system paths
• Existing dogfood workflows still work for Go/Rust/Node tooling after the PATH
  change.
• The change passes the dogfood image CI path in .github/workflows/dogfood.yaml.

Dogfooding and verification

1. Build both images locally:
   • dogfood/coder/ubuntu-22.04
   • dogfood/coder/ubuntu-26.04
2. Run each image with an empty mounted home volume at /home/coder to mimic
   the actual dogfood runtime constraint instead of only testing the image’s
   baked filesystem.
3. Capture a short terminal recording and screenshots for each variant showing:
   • brew --prefix
   • brew --version
   • mise --version
   • echo "$PATH"
   • mise doctor
   • mise doctor path
4. Verify at least one login-shell path and one non-login-shell path, so we can
   tell whether Dockerfile ENV PATH is sufficient or whether /etc/profile.d
   hardening is required.
5. Add one tool-resolution smoke test that proves mise wins when configured:
   • install/use a small mise-managed runtime as coder
   • run which -a <tool>
   • run <tool> --version
6. Verify existing image behavior did not regress:
   • go version
   • node --version
   • any other must-have image tools that were already on PATH
7. Preserve the artifacts from dogfooding for review:
   • screenshots attached to the change summary
   • a short screen recording (or terminal recording) covering the smoke test

Risks and decision points

• Homebrew ownership model: installing Homebrew during docker build is not
  enough by itself; the prefix must end up writable for coder.
• Scope control: the initial change should solve mise doctor by fixing PATH
  precedence, not by introducing a larger mise-managed tool bootstrap.
• Shell-init uncertainty: if the dogfood terminal entrypoints do not source
  /etc/profile, a Dockerfile ENV PATH fix may be sufficient and profile.d
  may be unnecessary. This should be decided by smoke tests, not by assumption.
• Persistent home behavior: avoid any required implementation detail that
  only works if fresh volumes copy image-baked /home/coder contents.