rig/changelog.d/139.md

### Fixed

- `rig forgejo-runner install`, `rig runner install` and `rig users apply` refuse with a named remedy when root's `PATH` carries no `/usr/sbin`, instead of dying on `useradd: command not found` after prompting for a token (#139)
fix: refuse a PATH without /usr/sbin, before the token prompt Reported from a real ci-box: `rig forgejo-runner install` read a registration token off the operator's terminal and then died with …/forgejo-runner-install.sh: line 250: useradd: command not found rig checked `id -u` and concluded it could administer the machine. Being root and being able to FIND the admin binaries are different facts, and only the first was asserted. `su` without `-`, sudo with a sanitised secure_path, and several container images all produce a root shell with no /usr/sbin on PATH, which is where useradd lives. Three call sites had it: both runner installers and users apply. The last is the worst — it runs mid-convergence, so a PATH-shorn root could fail partway through a user sweep rather than before it starts. require_admin_bins refuses rather than repairing PATH itself: a command that quietly prepends /usr/sbin teaches the operator nothing and leaves a misconfigured host misconfigured. The message names the remedy and, deliberately, not this script — echoing an internal path back at someone who typed `rig forgejo-runner install` is the unhelpful half of the original error. It sits beside each root check, so identity and capability are asserted together and before anything is spent. A secret typed for a run that could never succeed is the avoidable half of this bug, and there is a test for exactly that ordering. Closes #139 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> 2026-08-01 18:39:03 +00:00			`### Fixed`

			- `rig forgejo-runner install`, `rig runner install` and `rig users apply` refuse with a named remedy when root's `PATH` carries no `/usr/sbin`, instead of dying on `useradd: command not found` after prompting for a token (#139)