rdmpw3265m — 2026-08-31 18:44–18:56 EDT

Two unrelated faults, both resolved and verified.

1. brew upgrade claude-code@latest reported no update when one existed

Not a broken install. Two compounding causes:

• HOMEBREW_NO_AUTO_UPDATE=1 (set by setup_terminal_standard.sh at ~/.zshrc:28) makes Homebrew 6.x api.rb: fetch_api_files! set stale_seconds = nil, so brew upgrade never re-downloads the cask index. Hosts were holding indexes ~15 min apart in age. Fix: always brew update && brew upgrade --cask <name>. dev_update.zsh already does this (lines 639/657), so the scheduled path was never affected — only ad-hoc upgrades.
• Brew 6.x resolves casks only from the aggregated signed packages.<tag>.jws.json, which lagged the per-cask api/cask/<token>.json by ~53 min (index gen 17:53:30 EDT held 2.1.251; per-cask API already had 2.1.252). HOMEBREW_USE_INTERNAL_API is deprecated with no opt-out, and a cask JSON outside a tap is rejected — so during that window the new version is simply not installable by any clean means.

Fleet upgraded 2.1.251 -> 2.1.252 at 18:48:15–18:49:01 EDT: all six hosts verified on 2.1.252 via claude --version.

Exec-bit trap fired again, and the documented remedy is WRONG

jdmbair13m5's 2.1.252 binary landed mode 644 ("permission denied" on exec). The remedy in fleet-operations/references/claude-code-install.md guarded the chmod with test -x — that guard returned TRUE for the mode-644 file. Both [[ -x $f ]] and /bin/test -x $f said executable (owner richh:staff, no ACL, com.apple.quarantine xattr present). So the guarded fix reported "already ok" and left the host broken. Reference doc corrected: chmod unconditionally, then verify by running the binary. jdmbair13m5 now 755 and runnable.

Boot-persistent updater installed (rdmpw3265m, rdmsm4x)

~/scripts/claude_code_update.zsh v1.1 + LaunchAgent com.eastcoastscience.claude-code-update (RunAtLoad, StartInterval 21600). Logs to ~/scripts/claude_code_update.log. Both verified running and logging at 18:51:54 / 18:52:05. Zsh trap hit while writing it: status is a read-only special variable in zsh (v1.0 died at line 50 with "read-only variable: status").

2. sshd-keygen-wrapper permissions could not be selected in System Settings

It was Automation, not Full Disk Access. FDA and Accessibility were already granted (system TCC.db, auth_value=2).

The user TCC.db held Automation (kTCCServiceAppleEvents) rows for /usr/libexec/sshd-keygen-wrapper with auth_value=0, auth_reason=9 (prompt timeout), flags=1. flags=1 makes the row non-toggleable in System Settings — the checkbox is greyed and the user cannot re-enable it from the UI.

Cause: an unattended SSH session drove AppleScript at Notes/Finder/Terminal with nobody at the keyboard; the consent dialogs timed out and TCC recorded hard denials. rdmpw3265m's three were stamped 2026-08-30 16:50:00/08/17 — 17 seconds apart. This is what would break fleet-notes-publish from an SSH session on these hosts.

Fix (snapshotted first, scoped to this client+service, Apple first-party targets only): reshaped the rows to match the known-good row on the same client — auth_value=2, auth_reason=3, flags=NULL — then killall tccd.

• rdmpw3265m: 3 rows (Notes, Finder, Terminal). Row count 103 -> 103. Verified over SSH: System Events => 2, Finder => "Macintosh HD", Notes => 85 folders, Terminal => 1.
• rdmpw3275m: 3 rows (Notes, Finder, systemevents — systemevents had been denied at 18:23:29 today). Row count 162 -> 162. Verified over SSH: 2 / "Macintosh HD" / 78 folders.
• Left alone deliberately: net.dataroo.RTTy on rdmpw3275m (third-party target, denied 2026-08-21) — user's call, not mine.
• Backups: ~/scripts/tcc-backups/TCC.db.<ts>.bak on each host.

Other four hosts

rdmsm4x, rdmbair13m5, rdmbair15m5, jdmbair13m5 have no user TCC.db at all — the file is created on first grant, so they carry no sticky denials. Note this is not the same as being configured: an SSH-driven AppleScript there will prompt, and if unattended it will time out and create exactly this fault. The earlier survey printed ? for these hosts; that was a failed read, not a clean result.

Environment note (not changed)

~/.zshrc:28 HOMEBREW_NO_AUTO_UPDATE=1 sits inside the block marked "Managed by setup_terminal_standard.sh - do not edit inside this block." Adding HOMEBREW_FORCE_API_AUTO_UPDATE=1 would make bare brew upgrade behave correctly; it belongs in that script, not in an in-place edit. Not done — awaiting Rich.

Addendum — 2026-08-31 19:08 EDT: a knowledge edit was silently reverted mid-session

Correction to an earlier claim in this session. I reported the fleet reference claude-code-install.md as corrected at ~18:52 EDT. It was written, and then it was gone by 19:05 — reverted on rdmpw3265m without any error.

Cause, identified: com.eastcoastscience.configsync on rdmsm4x runs ~/dev/fleet/maintenance/scripts/fleet_config_reconcile.zsh --quiet, which does rsync -a --delete ~/.claude/skills/<skill>/ <host>:.claude/skills/<skill>/ for every skill the canonical CLAUDE.md files reference — fleet-operations included. ~/.claude/skills/ on any non-hub host is rsync --delete target territory.

Why it was nearly invisible: rsync -a preserves the source mtime, so the reverted file read Aug 25 18:54 — indistinguishable from never having been edited — and its sha256 matched the hub byte for byte. Nothing logged. It surfaced only because a cross-host shasum comparison happened to be run for an unrelated reason.

Resolved: the correction is now applied on rdmsm4x (canonical, sha256 2f34c520...) and re-applied locally so this host is right until the next reconcile. The macos-permissions and fleet-notes-publish skill edits were made on rdmsm4x and are unaffected.

Rule for the successor: edit synced skills on rdmsm4x, never on a spoke. Verify a skill edit survived by shasum -a256 against the hub, not by re-reading it locally.

Not diagnosed, recorded so it is not mistaken for the above: com.rdm.fleetconfigsync (~/bin/fleet-config-sync.zsh, hourly, spoke → hub staging, push-only) has been failing on rdmpw3265m with [email protected]: Permission denied (publickey,password,keyboard-interactive) and kex_exchange_identification: read: Connection reset by peer. It does not write local skills and did not cause the revert. Config collection from this host into rdmsm4x:~/fleet-configs-staging/rdmpw3265m/ is therefore stale by an unknown amount. Worth a ticket; not opened this session.