Destructive-command gate false-positives on /dev/null, /dev/stdout, /dev/stderr redirects

[yesvus]

Bug

The destructive-command gate's /dev protection (added for the catastrophic-path guard around #604) matches by path prefix, so it also catches /dev/null, /dev/stdout, /dev/stderr, and /dev/fd/*.

This means completely routine, harmless redirects get hard-blocked as if they were destructive writes to a device node:

cat file.txt 2>/dev/null
grep foo file.txt >/dev/null
make 2>&1

These sinks only discard data — they can never damage a filesystem — but the gate can't currently tell them apart from something like dd if=x of=/dev/sda.

Fix

I have a fix + regression test ready on a fork (couldn't open a PR directly — repo's PR creation is collaborators-only):

https://github.com/yesvus/jcode/tree/fix/dev-null-gate-false-positive
Diff: yesvus/jcode@1jehuang:jcode:master...yesvus:jcode:fix/dev-null-gate-false-positive

Adds an explicit exemption for /dev/null, /dev/stdout, /dev/stderr, /dev/fd/* in crates/jcode-command-risk/src/paths.rs, checked before the catastrophic-path check runs, plus a regression test (stderr_suppression_to_dev_null_is_safe) in assess_tests.rs.

cargo test -p jcode-command-risk --lib — 61 passed, 0 failed, including the new test.

Happy to have someone with write access cherry-pick the commit, or grant PR access if that's easier.

[rameshbaskaran]

The /dev/null//dev/stdout//dev/stderr//dev/zero//dev/tty exemption from this issue is now covered as part of #751's fix (which lands the same discard-sink concept). I additionally extended it to match /dev/fd/* (per your patch here) since fd-duplication idioms like 3>/dev/fd/1 weren't covered by the narrower exemption. Verified via cargo test -p jcode-command-risk (65 passed) and a live-reloaded self-dev daemon. See #751 for details.

[daviskathy6643]

异步写法很干净，学习了 🛠️