feat(approval): env-gated reboot/shutdown downgrade (HERMES_ALLOW_REBOOT)

[Kyzcreig]

Summary

The reboot/shutdown family is on the unconditional hardline blocklist in tools/approval.py — blocked even under --yolo, approvals.mode=off, and cron approve mode. That's the right default for most agents, but it's a hard wall for fleet/ops agents that legitimately manage Linux hosts and need to restart them.

This adds a narrow, opt-in escape hatch.

What changed

• New HERMES_ALLOW_REBOOT env flag (default unset).
• When unset → behavior is byte-identical to today: reboot/shutdown stay hardline-blocked.
• When set truthy → the reboot/shutdown family (shutdown|reboot|halt|poweroff, init 0/6, systemctl poweroff/reboot, telinit 0/6) downgrades out of the hardline floor into the existing DANGEROUS_PATTERNS layer. It is then approval-gated like any other dangerous command, and --yolo / approvals.mode=off can pass it through.
• Every other catastrophic pattern stays unconditionally hardline regardless of the flag: root recursive delete, filesystem format, raw block-device overwrite, fork bomb, kill -1. The flag only touches the reboot/shutdown family.

Why this design

• Safe default preserved — opt-in only; no behavior change for anyone who doesn't set the flag.
• Not a removal of the safety floor — reboot stays a dangerous command (still prompts unless yolo). It just stops being unconditional.
• Scoped — a single explicit set of descriptions (_REBOOT_HARDLINE_DESCS) is downgraded; the rest of the hardline floor is untouched.

Tests

tests/tools/test_hardline_blocklist.py — added:

• reboot/shutdown stays hardline when flag unset
• reboot/shutdown downgrades to dangerous (not free) when flag set
• other catastrophic patterns stay hardline even with the flag set
• flag + session yolo => full guard pipeline approves
• falsey flag values (0, false, no, empty) stay blocked

129 passed (existing hardline suite + new tests), no regressions.

[teknium1]

Thanks for the narrowly scoped implementation and the coverage preserving the default hardline behavior.

This is an automated hermes-sweeper review. The PR adds HERMES_ALLOW_REBOOT as a user-facing, non-secret behavioral feature flag, but the standing policy rejects new HERMES_* variables for behavioral configuration: AGENTS.md:102-107 requires these settings to live in config.yaml instead.

• Current main does have the reported hardline behavior: tools/approval.py:396-403 classifies the reboot/shutdown family as unconditional hardline patterns.
• The proposed mechanism reads HERMES_ALLOW_REBOOT to alter that safety behavior (dc5d1a492619345f6a4ebdef236d301b3004a131).
• If this capability is pursued, please re-scope it around an explicit config.yaml approval setting rather than a new environment-variable interface.

---

Closed as not-planned per standing maintainer policy (env-var-for-config). This is a design-direction decision, not a code-quality judgment — see the Contribution Rubric in AGENTS.md for what the project is looking for. If you believe this policy was misapplied to your change, comment here and a maintainer will take a look.