rdmbair15m5-changelog-20260901-1256-tcc-recheck-and-rdmbair13m5-exec-fault

rdmbair15m5 changelog — 2026-09-01 12:48–12:57 EDT

Session 902def67 · run from rdmbair15m5 · continues claude-code-tcc-20260831

What changed on disk

Host	Path	Change
rdmsm4x	`~/dev/fleet/claude-code-tcc-20260831/FINDINGS-20260901.md`	created (188 lines, sha256 `207d7324…`)
rdmsm4x	`~/dev/fleet/ISSUES.md`	4 OPEN entries inserted at top, 75 → 119 lines, 0 original lines lost
rdmsm4x	`~/.claude/backups/ISSUES.md.bak-20260901-1256`	snapshot taken before the edit

Nothing else was written. No TCC database was modified on any host, no LaunchAgent was installed/loaded/unloaded, and net.dataroo.RTTy on rdmpw3275m was left exactly as found (DEC-20260831-09 is the gate).

Findings

NEW — rdmbair13m5 has claude-code 2.1.252 installed and cannot execute it. claude --version hangs in state S, no stdout/stderr, never exits (×3, killed at 20s). Mode 755, Mach-O arm64 on arm64, codesign valid — every metadata check passes. Quarantine ruled out: all six hosts carry com.apple.quarantine, five run fine. Root cause not established. claude_code_update.zsh v1.1 has logged UNCHANGED 2.1.252 (brew rc=0) twice against this dead install because it trusts brew's version report instead of running the binary. TASK-20260831-18 must stay open.
CORRECTION — Ghostty was never TCC-denied anywhere. Zero auth_value=0 rows for com.mitchellh.ghostty across all six system TCC databases. The 2026-08-31 agy instruction to "toggle Ghostty ON on jdmbair13m5 (previously recorded as denied)" appears to misattribute kTCCServiceDeveloperTool | com.apple.Terminal | auth=0.
CORRECTION — rdmpw3275m sshd Accessibility is auth=0 (denied), not pending. A denial is cached and never re-prompts, so it reads as "pending" forever. rdmbair13m5's same client is already auth=2. Different service and different (SIP-sealed, system) database from the 2026-08-31 per-user Automation repair, which remains intact.
NEW — jdmbair13m5 unreachable by hostname (ping 100% loss, ssh timeout) across ~18h and a reboot; Tailscale 100.86.185.90 works. Fleet scripts using the bare hostname are failing there.
Rollout re-measured: the updater LaunchAgent is on all six hosts, not the 2 recorded in SESSION-STATE.md; launchctl last exit 0 on the five that answer promptly.

Still blocked on Rich

DEC-20260831-08 — HOMEBREW_FORCE_API_AUTO_UPDATE.
DEC-20260831-09 — net.dataroo.RTTy Automation on rdmpw3275m.
GUI-only — toggle sshd-keygen-wrapper ON in System Settings ▸ Privacy & Security ▸ Accessibility on rdmpw3275m. Cannot be done from a shell; tccutil reset is wholesale.

Traps hit this session

zsh nomatch on claude-code@latest (trap #7 in the hand-off) aborted a whole fleet loop and printed no matches found for five hosts — which reads like five findings, not one glob failure. Re-ran through /bin/sh with find.
Nearly asserted quarantine as the cause of the rdmbair13m5 hang from a single-host reading. Checking all six falsified it. Two measurements differing is not evidence of a cause.

No secrets recorded.