Make the dev account an ordinary user of the box rather than a tenant on it

[ldayton]

The role assumed the provisioned account was a guest on somebody else's machine: it did not own Homebrew, its home was unreadable to the account that did, and sudo was a per-host grant that defaulted off. Every mechanism deleted here descends from one of those three. The visible symptom was an account that could run brew but not install with it — brew install failed on an unwritable prefix, and the documented workaround was to install as somebody else.

The account owns Homebrew

It installs the prefix itself, and takes over one another account left behind. That is Homebrew's only supported arrangement, and it removes the shared-group alternative: the setgid pass on directories, the group-write pass on files, and the repair pass for the combination of the two. That last one mattered — group-write reached the login shell of an account holding sudo, so brew-group membership was equivalent to root, and the comment saying so was really the argument against the feature.

Taking ownership copies nothing. The cost the sharing existed to avoid was 3.6G on disk; a chown moves no bytes. Measured at 0s over a 206M prefix.

With one owner there is nobody to hand a file to, so the Brewfile is read from the account's own clone and the root-owned staging directory is gone. The home stays 0750 — that is HOME_MODE on this distribution, so it is now simply what every normal user gets rather than something the role arranges and then works around.

The login shell moves to the distribution's zsh

Same release as Homebrew's (5.9). The only thing the Homebrew one bought was matching the cloud image's own account, which stopped being a consideration when this became the account you log into. Naming a shell that exists before Homebrew is what lets the account be created first and then install Homebrew as itself — which is what removes the connection-account discovery task and the refusal to install over a root connection.

Passwordless sudo stops being a flag

The account is created with a locked password, so password sudo could never have worked; the choice was never which kind of sudo but whether the account had any. It is also a precondition rather than a preference: the Homebrew installer probes sudo -n before it will create anything under /home.

Two defects fixed on the way

Both made a stock cloud image fail where a CI runner passed.

install.sh generates settings.json through claude/build-settings, which requires jq. jq comes from the Brewfile, so the Brewfile now installs before the home is configured rather than after it. That alone was not enough — command runs no login shell, so the Homebrew prefix was never on PATH and the jq just installed still was not found. The installer task now names the prefix explicitly.

A GitHub runner ships apt's jq on the default PATH, which is why neither showed up in CI. Both were found by running the role in a bare ubuntu:24.04 container.

Verification

Run in containers, not just linted:

Scenario	Result
Prefix pre-owned by another account (the CI case)	takeover, then brew install works as the account
Stock image: no brew, no jq	installs brew as the account, Brewfile, then install.sh
take_ownership: false against a foreign prefix	refuses, prefix untouched
Second run, both scenarios	changed=0 failed=0
ansible-lint	clean at the production profile

CI

Stops pinning the login shell to /bin/bash, so it exercises the real one, and asserts the account ends up owning the prefix and can install a formula with it — the operation ownership actually gates, and the one that did not work before. The jq/PATH blind spot is documented in the workflow rather than left implicit.

33 tasks where there were 43; dev_user_brew_share_mode, dev_user_brew_group, dev_user_brew_owner, dev_user_brew_stage_dir and dev_user_sudo_nopasswd are gone.

The one real trade-off

Whoever owned the prefix before can still run every binary in it, but can no longer brew install. On a box where another account needs to install its own packages, this is the wrong role — dev_user_brew_take_ownership: false makes it refuse rather than degrade silently.

https://claude.ai/code/session_01XBpcNj3TG2iV63QjJ1P4SD