Fleet changelogs · dev.ecs0.net
rdmsm4x-changelog-20260901-1801-raise-stop-hook-block-cap

rdmsm4x-changelog-20260901-1801-raise-stop-hook-block-cap

When: 2026-09-01 17:59-18:01 EDT · Host: rdmsm4x · Agent: Claude Code (Opus 5)

One-line summary: raised the Claude Code Stop-hook block cap from 9 to 50 on this host, at Rich's request, and identified (but did not fix) the fleet hook defect that makes the cap matter.

Scope

This host only. No other fleet host touched. No RTTy source changed.

Files touched

Backup / undo

Backup: session scratchpad, /private/tmp/claude-501/-Users-richh-dev-apps-RTTy/aeaeae05-.../scratchpad/settings.json.bak-20260901-* Undo: remove the env block (or restore the backup). Scratchpad is tmp — copy the backup out if the undo path needs to outlive the boot.

Verification

NOT verified

That Claude Code actually reads its stop-hook cap from settings-injected env rather than only the OS environment at launch. Not observable from inside the session that made the change. If the nag still caps at 9 next session, set it in the shell profile instead so it is in the OS env at launch.

Outstanding owner action

~/dev/fleet/ops/project-state/project_state_hook.py never reads stop_hook_active (grep, all 375 lines, no match). The documented contract for Stop hooks is to exit 0 while that flag is true. It does not, so it re-blocks unconditionally, and in RTTy its root-level SESSION-STATE.md probe can never pass (state lives at Project/SESSION-STATE.md by design). Raising the cap therefore turns 9 unsatisfiable blocks into 50. Fix is two lines near main(). Fleet-wide script — not changed without Rich's say-so; route to claude@rdmsm4x if he prefers.

Secrets

None read, written, or referenced.