repo-sudo

Codex form of the /repo:sudo command. Other commands appear as $repo-<verb> skills. Helper scripts and .claude/ paths below are relative to the repository root and exist when the Claude Code surface is installed alongside this one.

$repo-sudo — Passwordless-sudo setup for dev machines

Install (or inspect, or remove) a NOPASSWD: sudoers drop-in for the current user on this machine, so an agent driving the box over SSH isn't stopped dead by a sudo password prompt it can't answer. A non-interactive SSH session has no TTY to type a password into, so every root-level remediation — launchctl bootout, killing a runaway root process, spctl, renice — stalls until a human runs the command by hand. This command installs the standard fix once, safely, so agent-driven remote sessions can finish end-to-end.

This is machine-global, consequential setup: the drop-in grants anyone holding the user's SSH key effective root on this box. It is therefore in the same always-confirm-first class as $repo-remote, $repo-followups, and $repo-update-tools — it shows the exact file contents it will write and never applies silently, even without --ask. There is nothing to opt into; confirmation is the only mode. The reasonable trade this makes — passwordless root for personal dev machines on a private tailnet — is a deliberate operator choice, so the operator makes it explicitly every time a scope changes.

Touch ID is the better answer for local, interactive use — enabling pam_tid.so in /etc/pam.d/sudo lets a Mac authorize sudo with a fingerprint. But Touch ID does not work over SSH (there is no local fingerprint reader on the remote end), which is exactly why a NOPASSWD: drop-in is the right tool for agent sessions and this command exists.

The destructive-command guard still applies on top. Passwordless sudo removes the password gate, not the guard's ask/block gates on risky commands (rm -rf /, force-push to main, cloud destruction, …). Granting passwordless root does not weaken any of those checks.

Run this from a host session, not from inside a Loom-managed repo session. $repo-sudo configures the machine, not this repository's contents, and its write step (step 5) is deliberately built around mktemp — a path this repo's worktree-write-confinement guard can never resolve, so it is denied fail-closed whenever a managed worktree exists here. That denial is expected and must not be worked around: invoke $repo-sudo from a session outside a Loom-managed checkout, or have the operator run step 5's commands by hand in a plain shell/SSH login. Full explanation, and why the temp file must stay mktemp-created, is in the guard note in step 5.