[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

  1. I have Safety Net plugin installed to protect against destructive commands
  2. 2. Claude tries to run rm -rf ~/.claude/skills/ (outside cwd)
  3. 3. Safety Net blocks it with a scary red error message
  4. 4. I think something broke, when actually I'm being protected
  5. 5. With this feature, I'd see a friendly "blocked" message with a checkmark

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗