herdr resume — 0.9.0 upgrade revoked Rich's TCC grants; pinned; zsh token bug fixed

Session: claude@rdmbair15m5 · 2026-09-16 10:24:27 → 10:35 EDT (~11 min) · resume after 10 days idle

Headline

herdr went 0.8.2 -> 0.9.0 fleet-wide while this project was idle. The service survived; the privileges did not.

• Service intact: 5/5 reachable hosts started, still launchd-owned (PID 1075, ppid=1).
• Config survived the version bump: the 0.8.2-era config.toml validates applied on 0.9.0, sha 26c720d1d2a5 byte-identical on 5/5. No migration needed.
• Integrations unchanged by the upgrade: 4 per host, 5 on rdmsm4x.
• Rich granted the TCC toggles between sessions — and the upgrade threw them away. The rows are auth_value=2 (genuinely granted, not my auth=0 placeholders) but keyed on the 0.8.2 Cellar path, while the live binary is 0.9.0. A launchd-pane probe on 0.9.0: all five MISS again.

The lead worth keeping: one granted row is on /opt/homebrew/bin/herdr — a version-free path. TCC records the path AS EXEC'D, and the brew LaunchAgent execs /opt/homebrew/opt/herdr/bin/herdr, which landed as the versioned Cellar path. So pointing the service at the version-free path is a candidate durable fix. Deliberately not attempted: testing it needs a service restart, and this session is a descendant of that server — restarting kills the session doing the work; brew also regenerates the plist. Do it from outside herdr.

DEC-20260916-01 — herdr pinned on all five reachable hosts

brew pin herdr, verified brew list --pinned = 1 on each. An unplanned bump costs Rich six manual System Settings passes and silently undoes them; pinning makes upgrades deliberate, and one brew unpin herdr reverses it. Rejected: re-registering after each bump (only creates the denied placeholder, still needs his click); rewriting the brew plist now (see above); disabling herdr's [update] version_check (it only checks, it does not install).

0.9.0 placeholders registered on 5/5 and read back to confirm (...AllFiles|0|0, flags=0, so clickable). Re-granting is one pass: zsh ~/dev/fleet/herdr/herdr_tcc_grant.zsh --request at each Mac's keyboard — never over unattended ssh (a computer-use request_access blocked a session 24h on 09-14/15).

HERDR-20260916-19 — a zsh expansion bug, and the pipe trap that hid it

fleet_herdr_label.zsh printed WARN … token report failed for all four local workspaces on every run while the remote four passed, which read like a 0.9.0 API change. It was neither. ${br:+--token branch="$br"} expands to ONE word in zsh — zsh does not word-split parameter expansions the way bash does — so herdr got the malformed option --token branch=main and rejected the whole call. It only bit the local host because the remote probe returns an empty branch, so the expansion vanished there. Fixed with an array (brarg=(--token "branch=$br")); verified both directions — all 8 workspaces PASS, local rows gain branch=main, remote rows unchanged.

Method note: my instrumented debug run printed PASS on the very lines that were failing, because it piped herdr through head and the status came from head. The rc-through-a-pipe trap demonstrated itself while hunting a different bug.

The claude-hang host set MIGRATES — memory corrected

All hosts now on claude 2.1.273. claude --version: rdmsm4x 0s, rdmpw3275m 1s, rdmbair15m5 instant, rdmbair13m5 timed out 31s, rdmpw3265m timed out 30s. The auto-memory entry named four fixed hosts on 2.1.269; today it is two, and a different two. Three measurements over eleven days all show the set moving, so it is not a property of particular Macs. Memory entry claude-cli-hangs-on-four-fleet-hosts updated in place (description + a migration table + the two disproved kill-hypotheses), its ruled-out evidence preserved; MEMORY.md hook reworded.

Handled rather than fought: fleet_herdr_attach.zsh now runs --start claude where claude starts and --start none where it hangs, so an affected host gets a live signed-in remote shell instead of a dead pane.

HERDR-20260916-18 — jdmbair13m5 is offline

2/2 ping lost, ssh to 100.86.185.90 times out, Tailscale offline, last seen 12h ago. The host is down — not DNS, ssh or herdr. Same Mac left at 1.4 GiB free on a 926 GiB disk (HERDR-20260906-17); a Mac at 100% capacity failing to stay up is consistent. Excluded from the mesh; needs physical attention.

Sidebar state

4/4 reachable fleet panes live and verified: claude@rdmsm4x and claude@rdmpw3275m at Claude TUIs; shell@rdmbair13m5 and shell@rdmpw3265m at their own remote prompts ([ rdmbair13m5 ], [ rdmpw3265m ] in ~/dev). Rich's four local sessions untouched by --close, which matches by label inclusion.

Records

fleet/herdr/ISSUES.md (22 headings, was 19) · SESSION-STATE.md (341 lines, with a counts table against 09-06) · PROJECTS.md row · memory entry + index. All pushed to canonical rdmsm4x. No secrets written.