[Feature Request] Hook rejections should have distinct "blocked" styling vs "error" styling
Resolved 💬 3 comments Opened Jan 15, 2026 by JohnnyBonk Closed Jan 19, 2026
Problem
When a PreToolUse hook intentionally blocks a command (e.g., Safety Net blocking rm -rf outside cwd), it surfaces to the user as an error with red/alarming styling.
This is confusing because:
- The hook worked correctly
- - The user is being protected
- - - Nothing actually failed
Users may disable safety hooks because they think something is broken, when actually the hooks are working as intended.
Proposed Solution
Add a distinct "blocked" or "prevented" state that hooks can return, with friendlier styling:
- Different color (yellow/orange vs red)
- - Checkmark or shield icon instead of error icon
- - - Messaging that indicates protection, not failure
Example output:
✓ Safety Net blocked command
Reason: rm -rf outside cwd is blocked
Tip: Run manually if this was intentional
This reinforces that blocking dangerous commands is a feature, not a bug.
Use Case
- I have Safety Net plugin installed to protect against destructive commands
- 2. Claude tries to run
rm -rf ~/.claude/skills/(outside cwd) - 3. Safety Net blocks it with a scary red error message
- 4. I think something broke, when actually I'm being protected
- 5. With this feature, I'd see a friendly "blocked" message with a checkmark
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗