[FEATURE] Add ModeChanged hook event and programmatic /color API for mode-aware visual feedback

Problem

Claude Code now supports /color to set the input border color — great for visual customization. However, its practical value is severely limited:

1. /color can only be invoked manually — no programmatic access from hooks, scripts, or settings.
2. No hook event fires on mode switches — toggling between Default, Plan, Edit, or Bypass Permissions triggers no hook, so automation can't react.

Users must manually type /color green every time they enter Plan mode, /color blue for Edit, etc. — which makes color-as-status-indicator impractical.

The UX Case: Why Border Color > Status Text

From a visual perception standpoint, border color is a far stronger mode indicator than a small text label in the status line.

• Peripheral vision: A colored border surrounding the input area is visible even when the user isn't actively looking at the status bar. It creates an ambient awareness of the current mode — something a few characters of text in the corner simply cannot do.
• Pre-attentive processing: Color is processed by the human visual system before conscious attention kicks in. Users can feel they're in a dangerous mode (red border for Bypass Permissions) without needing to read anything.
• Redundancy reduces error: Once the border reliably signals the mode, the text label becomes a secondary confirmation rather than the primary indicator. This is a well-established principle in UI design — critical state should never rely on a single, easily-overlooked channel.

To be clear: I'm not asking Anthropic to change the default behavior. Users are already accustomed to the current experience, and that should be respected. What I'm requesting is that the interfaces be opened up — so users who want this level of customization can build it themselves.

Proposed Solution

1. New ModeChanged hook event

Fire a hook whenever the user switches modes:

{
  "event": "ModeChanged",
  "mode": "plan",          // "default" | "plan" | "edit" | "bypassPermissions"
  "previousMode": "default"
}

2. Programmatic /color control

Allow hooks to set the input border color. Any of these approaches would work:

• A color field in hook return JSON — e.g., { "color": "green" } applied immediately.
• An environment variable — e.g., CLAUDE_CODE_BORDER_COLOR read by the UI on change.
• A watchable settings key — e.g., "borderColor" in settings.json.

Example: Automatic Mode Coloring

With both features in place, the setup would be trivial:

// settings.json
{
  "hooks": {
    "ModeChanged": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "mode-color.sh"
          }
        ]
      }
    ]
  }
}

#!/bin/bash
# mode-color.sh
case "$CLAUDE_MODE" in
  plan)              echo '{"color":"green"}' ;;   # Safe, read-only planning
  edit)              echo '{"color":"blue"}' ;;    # Active editing
  bypassPermissions) echo '{"color":"red"}' ;;     # Elevated risk
  *)                 echo '{"color":"default"}' ;;  # Normal operation
esac

Why This Matters

• Safety: A red border for Bypass Permissions is an unmissable visual guardrail — far more effective than a text label users might overlook before issuing a destructive command.
• Workflow clarity: When juggling multiple sessions or switching modes frequently, color-coded borders eliminate cognitive overhead.
• Completes the /color story: Without programmatic access, /color is a curiosity. With it, /color becomes infrastructure for real user-driven automation.
• Respects existing users: This changes no defaults — it simply opens the door for power users to customize their experience.

Related Issues

• #3447 — Request for additional hook event types
• #7415 — Plan mode border/style override
• #29475 — Customizable background color for permission prompts
• #34702 — UI color/theme customization
• #29166 — Customizable UI colors/themes via settings.json