fix(terminal): block sudo -S password guessing when SUDO_PASSWORD is unset

[29206394]

Problem (fixes #9590)

The LLM can brute-force sudo passwords by iterating:

echo guessedpass1 | sudo -S whoami  # "Sorry, try again"
echo guessedpass2 | sudo -S whoami  # "Sorry, try again"
# ... iterate based on sudo's error output

The existing _transform_sudo_command only injects -S when SUDO_PASSWORD is configured. Without it, any explicit sudo -S in the command is the LLM piping a guessed password — a brute-force attack vector.

Fix

Add a _check_sudo_stdin_guard() in tools/approval.py:

• Detects sudo -S (stdin password flag) when SUDO_PASSWORD env var is not set
• Regex is anchored to command-start positions (^ ; && || | etc.) to avoid false positives on literal text mentions
• Integrated into check_all_command_guards() above yolo/mode=off, like the hardline floor — this is never legitimate

When SUDO_PASSWORD IS set, the guard is bypassed (the system itself injects -S in that case, which is legitimate).

Changes

File	Change
tools/approval.py	+44 lines: regex, guard function, block result helper, integration
tests/tools/test_hardline_blocklist.py	+88 lines: 6 tests

Tests (6 new, all pass — 246 total in related suites)

1. detects: sudo -S, piped variants, compound commands with &&
2. allows: plain sudo, -S on other tools, literal echo text
3. bypasses when password set: SUDO_PASSWORD configured → no block
4. integration: check_all_command_guards returns block result
5. yolo can't bypass: HERMES_YOLO_MODE=1 still blocked
6. container bypass: docker/singularity/modal/daytona/vercel still skip guards

[kshitijk4poor]

Merged via #23736 (salvage: cherry-picked onto current main). Your commit authorship preserved in git log. Thanks for the fix!