dev_update 2.11 (the FDA check asks for the grant that matters) and close-out of the dev_update / fleet-sweep lane
When: 2026-09-23 14:26:03 → 2026-09-23 14:37:08 EDT
(both read from the clock) · Host: rdmsm4x ·
Scope: all six fleet Macs Tickets:
ISSUE-20260923-05 (taken and resolved) · corrections posted on
ISSUE-20260920-04 and ISSUE-20260922-03 Commits
(~/dev/scripts): fe8810e (dev_update 2.11 +
normalize 1.10), f0fa046 e67671d (session
state)
One line: the nightly sweep had its first fully clean night, and the one recurring dev_update finding that nobody could act on — three "Full Disk Access is OFF" HIGHs per host — now asks once for the switch that actually covers agent sessions.
1. Production check of the nightly sweep (fleet_dev_update 1.2)
2026-09-23 03:07: 6 of 6 dry runs passed the gate and 6 of 6 real runs completed — the first fully clean night since the gate was fixed. No run hit its cap, so no snapshot was needed. rdmpw3275m (Intel) 29m10s, rdmsm4x 23m14s, rdmbair13m5 1m48s (its second clean night running).
2. dev_update 2.11 — ISSUE-20260923-05
Filed this morning by the rdmbair15m5 lane and left unclaimed.
perm_prime_fda raised "Full Disk Access for
claude/codex/agy is OFF" as three HIGHs per host, every run, from
per-CLI rows only:
- it never looked at ECSToolHost, the process TCC holds responsible for herdr-hosted agent sessions;
- the per-CLI grants it asked for are pinned to versioned Caskroom paths and go stale at every upgrade;
- its "placeholder priming" read ran as dev_update's own process, so it primed the wrong subject.
Now ECSToolHost's row is read from the system TCC db (bounded read). Granted → PASS. Installed with no row → one HIGH naming the app path to add with + (with no row there is no switch to flip). Not installed → info. Unreadable → a warning. The priming read is removed. The app is found by known paths before Spotlight, which cannot see it on rdmbair13m5.
Measured before coding, over ssh on all six hosts: an ECSToolHost FDA row exists only on rdmbair15m5, and the app is installed on all six.
| check | result |
|---|---|
| live dry run, rdmbair15m5 (row present) | PASS, 0 HIGH |
| live dry run, rdmsm4x / rdmbair13m5 (no row) | exactly 1 HIGH each, with the path |
| isolated branch test (stubs) | findings 0 / 1 / 0 / 0 — granted / no row / not installed / unreadable |
| payload | unchanged (2.22, sha
a4a80d636cc2); --verify-embedded OK |
| deploy | normalize_dev_update 1.10 on
all six hosts: canonical v2.11, rollback v2.10, v2.09 archived —
0 FAIL each |
3. Close-out of the lane
- Tickets: all of this lane's are resolved (ISSUE-20260920-03, ISSUE-20260921-07, ISSUE-20260922-03, ISSUE-20260923-05). ISSUE-20260920-04 had been resolved on 2026-09-21 10:34 by another agent; my summaries of 09-21 and 09-22 wrongly called it open — corrected on the ticket.
~/dev/CLAUDE.md§7 no longer pins "v1.99 / payload 2.11": it says how to read the live version (several lanes ship versions daily) and documents the nightly sweep and its 0/10/20/30 gate contract. All eight section headers verified intact.- Cross-reference: another lane's dev_update 2.07 bounds Homebrew downloads (20 s connect, abort below 1 KB/s for 60 s), which covers the class of fetch stall rdmsm4x showed on 09-22.
4. What is left, and whose it is
The other lane (rdmbair15m5) closed the Developer ID export (on all six hosts since 00:57 today) and the Xcode team sign-in (6/6). The one remaining person-item is the one dev_update 2.11 now names: Full Disk Access for ECSToolHost — add it with "+" on rdmsm4x, rdmbair13m5, jdmbair13m5, rdmpw3265m and rdmpw3275m; that lane's console v1.5 walks through it.
Undo
ln -sfn dev_update_v2.10.zsh ~/dev/scripts/dev_update.zsh
(and the four aliases) on any host, or roll normalize back one step;
v2.10 is kept as the rollback everywhere.