Skip to content

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

Open
Kyzcreig wants to merge 1 commit into
NousResearch:mainfrom
Kyzcreig:feat/env-gated-reboot-downgrade
Open

feat(approval): env-gated reboot/shutdown downgrade (HERMES_ALLOW_REBOOT)#38976
Kyzcreig wants to merge 1 commit into
NousResearch:mainfrom
Kyzcreig:feat/env-gated-reboot-downgrade

Conversation

@Kyzcreig

@Kyzcreig Kyzcreig commented Jun 4, 2026

Copy link
Copy Markdown
Contributor

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.

…OOT)

The reboot/shutdown family is on the unconditional hardline blocklist —
the correct default for most agents, but a hard blocker for fleet/ops
agents that legitimately need to restart the Linux hosts they manage.

Add an opt-in escape hatch: when HERMES_ALLOW_REBOOT is set truthy, the
reboot/shutdown family downgrades from HARDLINE to the DANGEROUS layer —
still approval-gated, and yolo / approvals.mode=off can pass it through.
Every other catastrophic pattern (root recursive delete, filesystem
format, raw-device overwrite, fork bomb, kill -1) stays unconditionally
hardline.

Default (flag unset) is byte-identical to the historical always-block
behavior. Verified: 129 tests pass including new downgrade and
isolation tests.
@alt-glitch alt-glitch added type/feature New feature or request P3 Low — cosmetic, nice to have tool/terminal Terminal execution and process management labels Jun 4, 2026
Kyzcreig added a commit to Kyzcreig/hermes-agent that referenced this pull request Jun 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

P3 Low — cosmetic, nice to have tool/terminal Terminal execution and process management type/feature New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants