Why It Matters

SEC363 flags committed Claude settings hook commands that start from a user home-directory path such as $HOME/, /Users/, or /home/.

This is useful because:

• shared Claude settings in git are team-facing configuration, not one machine's personal dotfiles
• home-directory hook paths are brittle and make setup harder to review, audit, and reproduce
• project-scoped wrapper paths are easier for teams to understand and maintain

Positioning

This is a compat rule, not a headline security finding. The issue is portability and shared-config correctness, not exploitability by itself.

What Triggers

This rule applies only to committed Claude settings surfaces:

• .claude/settings.json
• claude/settings.json

It triggers when a hooks entry with type: "command" has a command string that starts with:

• $HOME/
• /Users/
• /home/

It does not trigger on:

• project-scoped paths rooted in $CLAUDE_PROJECT_DIR
• commands that merely redirect output into $HOME/...
• fixture-like test/example paths

Examples

Bad:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "$HOME/.claude/hooks/audit.sh"
          }
        ]
      }
    ]
  }
}

Better:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "$CLAUDE_PROJECT_DIR/scripts/audit.sh"
          }
        ]
      }
    ]
  }
}

Remediation

• replace home-directory hook commands with project-scoped wrappers
• prefer repo-relative launch paths rooted in $CLAUDE_PROJECT_DIR
• keep shared Claude settings portable across machines