feat(security): deny irreversible destructive commands in every posture

[JordanTheJet]

Summary

• Base branch: master
• What changed and why: is_command_allowed returns true immediately when allowed_commands contains * and block_high_risk_commands is false. That is the documented operator opt-out from command screening — but today it also opts out of the handful of operations that leave no system to recover on. This adds a deny tier that no configuration can disable.
• Scope is deliberately tiny. Only operations that are immediate, irreversible, and never legitimate from an agent shell: mkfs (and mkfs.<fstype>), dd writing to a raw block device, rm naming the filesystem root, and the classic fork bomb.
• Evaluated per chain segment and ahead of the wildcard opt-out, so ls && mkfs.ext4 /dev/sdb1 is caught. Reports a distinct error rather than the generic policy refusal, so an operator can tell "you turned screening off but this is still denied" from "your allowlist rejected this".
• Scope boundary: No change to the allowlist, to command_risk_level, to approval flow, or to what block_high_risk_commands does for everything else. This does not attempt general shell-syntax normalization — the existing guards already reject backticks, $(), and process substitution outside the wildcard path.
• Blast radius: Every caller of SecurityPolicy::is_command_allowed / validate_command_execution, i.e. the shell tool and anything reusing the policy gate. Behavior changes only for the four patterns above; ordinary work is unaffected and covered by a negative test.
• Linked issue(s): N/A
• Labels: type:feat, risk:medium, size:S

Testing (required)

How you can test

• Reviewer testing requested? Yes
• Interface(s) exercised: surface = cli (shell tool via the security policy)
• Setup / preconditions: A config with allowed_commands = ["*"], block_high_risk_commands = false, autonomy = "full" — the most permissive posture available.
• Steps to run: Ask the agent to run mkfs.ext4 /dev/sdb1 (use a device that does not exist if you would rather not find out).
• Expected on this branch (after): Refused with "irreversible destructive operation, denied in every posture".
• Prior behavior on master (before): The policy permits it and the command reaches the shell.

How I tested

Four tests written before the implementation. At red, three failed and catastrophic_deny_does_not_capture_ordinary_work already passed — establishing that the negative cases were allowed before the change and still are after it.

• catastrophic_commands_are_denied_in_the_most_permissive_posture — nine variants, asserting both the is_command_allowed refusal and the distinct error text
• catastrophic_deny_does_not_capture_ordinary_work — dd if=input.iso of=output.img, dd of=./disk.img, rm -rf ./build, rm -rf /tmp/scratch, echo ':(){ :|:& };:', grep -r mkfs docs/
• catastrophic_deny_survives_a_high_risk_command_being_explicitly_listed — listing dd unlocks dd if=a.img of=b.img but not of=/dev/sda
• catastrophic_deny_applies_to_every_segment_of_a_chain

cargo test -p zeroclaw-config
# test result: ok. 1245 passed; 0 failed  (+ 90, 8, 5, 1, 1 in the other targets)

cargo test -p zeroclaw-tools --lib shell
# test result: ok. 4 passed; 0 failed

cargo fmt --all -- --check                                       # clean
cargo clippy -p zeroclaw-config --all-targets -- -D warnings     # clean
bash scripts/ci/comment_hygiene_gate.sh                          # passed

• CI checks relied on and why they cover this change: Rust quality gate over zeroclaw-config, which owns the policy gate; the full 1245-test policy suite is the regression surface for a shared predicate.
• Known CI coverage gap, if any: Windows-specific naming is only partly exercised — strip_windows_exe_suffix is a no-op off Windows, so mkfs matching is validated on Unix naming only. The four patterns are Unix-shaped by nature.
• Beyond CI, what did you manually verify? I checked that quoted text is not captured (the fork-bomb matcher strips quoted spans first, so echo ':(){ :|:& };:' stays allowed) and that /dev/null and /dev/zero are excluded from the raw-block-device prefixes so output suppression keeps working. I did NOT run any of these commands against real hardware.

Security & Privacy Impact (required)

• New permissions, capabilities, or file system access scope? No — this removes capability
• New external network calls? No
• Secrets / tokens / credentials handling changed? No
• PII, real identities, or personal data in diff, tests, fixtures, or docs? No
• Prompt injection or untrusted model-visible text introduced/changed? No
• If any Yes, describe the risk and mitigation: N/A. The intended risk trade-off is stated plainly: an operator who deliberately set ["*"] loses the ability to run four specific patterns. That is the point of the tier, and the error message says so rather than failing as a generic policy refusal.

[JordanTheJet]

Note on the diff size. This branch is based on upstream/master (e91a7a0c6), but this fork's master is 313 commits behind upstream, so GitHub renders the base gap as ~1000 changed files. The real change is one file:

crates/zeroclaw-config/src/policy.rs | 201 +++++++++++++++++++++

Review with git diff upstream/master...fix/command-policy-hard-deny. Same fork-sync caveat as #22.