SSD Nodes Learn Hosting plans →
கல்வி வழிகாட்டிகள் Matt Connorஆல் Matt Connor · புதுப்பிக்கப்பட்டது 2026-08-30

Claude Code Hooks: செயல்முறை மற்றும் பாதுகாப்பு விளக்கம்

Claude Code hooks எவ்வாறு செயல்படுகின்றன என்பதை அறியுங்கள். Model-ன் முடிவை மீறி இவை இயங்கும் விதம், exit code 2-ன் தாக்கம் மற்றும் பாதுகாப்பு அபாயங்கள் குறித்த விரிவான வழிகாட்டி.

Claude Code hook என்றால் என்ன

Claude Code hooks என்பவை, Claude Code தனது வாழ்க்கைச் சுழற்சியின் குறிப்பிட்ட நிலைகளில் தானாகவே இயக்கும் shell commands ஆகும். ஒரு hook-க்கும் rules file-க்கும் உள்ள அடிப்படை வேறுபாடு இதுவே. CLAUDE.md-ல் உள்ள ஒரு அறிவுரை என்பது ஒரு ஆலோசனையாகும்; அதை model தனது சூழலில் உள்ள மற்ற தகவல்களுடன் ஒப்பிட்டுப் பார்க்கும். ஆனால், ஒரு hook என்பது code ஆகும்; model ஒப்புக்கொண்டாலும் இல்லாவிட்டாலும் அது இயங்கும். நீங்கள் இரண்டு முறை சொல்லியும் உங்கள் agent formatter-ஐத் தவிர்க்கிறது என்றால், அதற்கு இன்னும் கடுமையான அறிவுரை தேவையில்லை. உங்களுக்கு ஒரு hook தேவை.

இதன் செயல்முறை எளிமையானது. ஒரு settings file-ல் event பெயர் ஒன்றின் கீழ் நீங்கள் ஒரு command-ஐப் பதிவு செய்ய வேண்டும். அந்த event நிகழும்போது, Claude Code உங்கள் command-ஐ இயக்கி, event தரவை அதன் standard input (stdin)-க்கு JSON (JavaScript object notation) வடிவில் எழுதும். உங்கள் command அந்தத் தரவைப் படித்து, தனது வேலையைச் செய்து, ஒரு exit status-ஐ வழங்கும். ஒரு PreToolUse hook-லிருந்து வரும் exit 2, tool call இயங்குவதற்கு முன்பே அதை ரத்து செய்யும்; உங்கள் script standard error (stderr)-ல் எதை எழுதியதோ, அதுவே காரணமான model-க்குத் தெரிவிக்கப்படும்.

இங்குள்ள event பெயர்கள் மற்றும் field பெயர்கள் Claude Code hooks reference-லிருந்து எடுக்கப்பட்டவை. இவை ஆகஸ்ட் 2026-ல் release 2.1.232 பதிப்பிற்காகச் சரிபார்க்கப்பட்டன. இந்த அமைப்பு வேகமாக மாறிவருவதால், எந்தவொரு blog post-லிருந்தும் JSON-ஐ நகலெடுக்கும் முன், உங்கள் பதிப்பிற்கான reference-ஐச் சரிபார்க்கவும். உங்களுடையதை claude --version மூலம் print செய்யவும்.

Hook configuration இருக்கும் இடம்

Hook என்பது settings file-ல் உள்ள ஒரு JSON block ஆகும். இதனை ஆறு இடங்களில் அமைக்கலாம்; அந்த file-ன் scope-தான் அந்த hook-ன் scope-ம் ஆகும்.

  • ~/.claude/settings.json: உங்கள் machine-ல் உள்ள அனைத்து project-களுக்கும் பொருந்தும், மற்றவர்களுக்குப் பொருந்தாது.
  • .claude/settings.json: ஒரு குறிப்பிட்ட project-க்கு மட்டும், இது repository-ல் commit செய்யப்படுவதால், clone செய்யும் அனைவருக்கும் இந்த hook கிடைக்கும்.
  • .claude/settings.local.json: ஒரு குறிப்பிட்ட project-க்கு மட்டும், உங்கள் machine-ல் மட்டும் செயல்படும்.
  • Managed policy settings: நிறுவனம் முழுவதும் பொருந்தும், இதை administrator அமைப்பார்.
  • hooks/hooks.json: ஒரு plugin-க்குள் இருப்பது, அந்த plugin enabled நிலையில் இருக்கும்போது மட்டும் செயல்படும்.
  • Skill அல்லது subagent frontmatter, அந்த component active நிலையில் இருக்கும்போது மட்டும் செயல்படும்.

இந்த file-களில் உள்ள hook entries ஒன்றையொன்று override செய்வதற்குப் பதிலாக ஒன்றிணைகின்றன (merge). ஒரு project settings file-ல் உள்ள hook-கள், உங்கள் user settings-ல் உள்ளவற்றுடன் சேர்க்கப்படுகின்றன, அவற்றை நீக்குவதில்லை. எனவே, ஒரு event-ல் பல file-களில் இருந்து வரும் பல hook-கள் இருக்கலாம். "disableAllHooks": true அமைப்பை set செய்வதன் மூலம் அவற்றை முடக்கலாம். இதற்கு ஒரு விதிவிலக்கு உண்டு: managed policy settings-ல் இருந்து வரும் hook-கள் தொடர்ந்து இயங்கும், அந்த setting-ஐ managed settings-லேயே முடக்கினால் ஒழிய அவை நிற்காது.

தற்போது பதிவு செய்யப்பட்டுள்ள அனைத்து hook-களையும் பட்டியலிட, ஒரு session-க்குள் /hooks கட்டளையை இயக்கவும். இவை event வாரியாகக் குழுவாக்கப்பட்டு, ஒவ்வொன்றின் source file மற்றும் matcher விவரங்களுடன் காட்டப்படும். இந்த menu read-only முறையில் இருப்பதால், settings file-ஐ edit செய்வதன் மூலமே hook-ஐ மாற்ற முடியும். File watcher பொதுவாக restart செய்யாமலேயே மாற்றங்களை உடனுக்குடன் கண்டறிந்துவிடும்.

Claude Code-ல் என்னென்ன hook நிகழ்வுகள் உள்ளன

Release 2.1.232-ல் SessionStart முதல் SessionEnd வரை முப்பத்தி ஒன்று நிகழ்வுகள் பட்டியலிடப்பட்டுள்ளன. இவை compaction, subagents, worktrees மற்றும் configuration files ஆகியவற்றை உள்ளடக்கியவை. Server பணிகளுக்கு இவற்றில் சில மட்டுமே பயன்படுகின்றன.

  • PreToolUse: ஒரு tool call இயக்கப்படுவதற்கு முன்பு. இதுவே செயல்பாட்டைத் தடுக்கக்கூடிய (block) hook ஆகும்.
  • PostToolUse: ஒரு tool call வெற்றிகரமாக முடிந்த பிறகு. அது தோல்வியுற்றால் PostToolUseFailure தூண்டப்படும். எனவே, அனைத்து முடிவுகளையும் கண்காணிக்க வேண்டிய hook-க்கு இவை இரண்டுமே தேவை.
  • PermissionRequest: ஒரு tool call-க்கு அனுமதி தேவைப்படும்போது. இதுவே approval prompt தோன்றும் தருணமாகும்.
  • UserPromptSubmit: நீங்கள் ஒரு prompt-ஐ சமர்ப்பித்த பிறகு, Claude அதைச் செயலாக்குவதற்கு முன்பு. இந்த hook stdout-ல் எதை அச்சிடுகிறதோ, அது model-ன் context-ல் சேர்க்கப்படும்.
  • SessionStart மற்றும் SessionEnd: ஒரு session-ன் தொடக்கத்திலும் முடிவிலும். SessionStart என்பது compaction முடிந்த பிறகும், compact என்ற matcher மதிப்பிற்கு உட்பட்டும் தூண்டப்படும்.
  • Stop: Claude தனது பதிலை முடிக்கும்போது. இது ஒரு turn-க்கு ஒருமுறை மட்டுமே நடக்கும், ஒரு முழுமையான பணிக்கு ஒருமுறை அல்ல.

ஒவ்வொரு தொகுப்பிலும் ஒரு matcher இருக்கும், இது எந்த நிகழ்வுகளுக்கு hook இயங்க வேண்டும் என்பதைத் தீர்மானிக்கிறது. Tool நிகழ்வுகளில், இது tool-ன் பெயரை வைத்து வடிகட்டுகிறது. உதாரணமாக, "Edit|Write" என்பது file edits-க்கு மட்டுமே தூண்டப்படும், மற்றவற்றிற்கு அல்ல. Matcher-கள் case sensitive ஆனவை. காலியான matcher அனைத்து நிகழ்வுகளுக்கும் தூண்டப்படும். MCP (model context protocol) server-லிருந்து வரும் tool-கள் mcp__<server>__<tool> என்று பெயரிடப்பட்டுள்ளன. எனவே, "mcp__github__.*" என்ற matcher ஒரு குறிப்பிட்ட server-ன் tool-களை மட்டும் பிடிக்கும், மற்றவற்றை விட்டுவிடும்.

Stop hook-களை எழுதும் முன் கவனிக்க வேண்டிய ஒரு சிக்கல் உள்ளது. தடுக்கும் (blocking) தன்மையுள்ள ஒரு Stop hook, model-ஐ மீண்டும் வேலை செய்யத் தூண்டும். தொடர்ந்து எட்டு முறை இவ்வாறு தடுத்தால், Claude Code அந்த hook-ஐ மீறிச் செயல்படும். Hook input-லிருந்து stop_hook_active புலத்தைப் படித்து, அது true ஆக இருக்கும்போது exit 0 கொடுக்கவும். இல்லையெனில், அந்த வரம்பை எட்டும் வரை உங்கள் hook மீண்டும் மீண்டும் இயங்கிக்கொண்டே இருக்கும்.

ஒரு hook stdin-ல் எதைப் பெறுகிறது

Claude npm test-ஐ இயக்கத் தயாராகும்போது, Bash-ல் உள்ள ஒரு PreToolUse hook, stdin-ல் இதைப் படிக்கிறது:

{
  "session_id": "abc123",
  "cwd": "/home/deploy/myproject",
  "hook_event_name": "PreToolUse",
  "tool_name": "Bash",
  "tool_input": {
    "command": "npm test"
  }
}

ஒவ்வொரு நிகழ்வும் session_id, cwd, permission_mode, transcript_path மற்றும் hook_event_name ஆகியவற்றைக் கொண்டிருக்கும். கருவி நிகழ்வுகள் (tool events) tool_name, tool_input மற்றும் tool_use_id ஆகியவற்றைச் சேர்க்கின்றன. பிற நிகழ்வுகள் அவற்றிற்கே உரிய புலங்களைக் கொண்டுள்ளன: UserPromptSubmit என்பது prompt உரையைப் பெறுகிறது, மேலும் SessionStart என்பது startup, resume, clear, compact அல்லது fork ஆகியவற்றின் source-ஐப் பெறுகிறது.

ஒரு shell script-க்குள் இதைப் படிப்பதற்கு jq வழக்கமான வழியாகும், ஆனால் ஒரு குறைந்தபட்ச server image-ல் இது இருக்காது. Ubuntu மற்றும் Debian-ல் sudo apt install -y jq மூலம் முதலில் இதை நிறுவவும்.

செயல்பாட்டில் உள்ள tool call-ல் exit status-ன் தாக்கம்

இதில் மூன்று முடிவுகள் உள்ளன.

  • Exit 0 என்பது உங்கள் hook எந்த ஆட்சேபனையும் தெரிவிக்கவில்லை என்று பொருள். PreToolUse-ல் இது ஒப்புதல் என்று அர்த்தமல்ல, வழக்கமான அனுமதி வழங்கும் நடைமுறை தொடர்ந்து நடைபெறும். UserPromptSubmit மற்றும் SessionStart-ல், stdout-ல் உள்ளவை model-ன் context-ல் சேர்க்கப்படும்.
  • Exit 2 என்பது தடுக்கக்கூடிய நிகழ்வுகளில் அந்தச் செயலைத் தடுக்கும், PreToolUse அவற்றில் ஒன்று, மேலும் stderr-ல் உள்ள தகவல் model-க்குக் காட்டப்படும். PostToolUse போன்ற தடுக்க முடியாத நிகழ்வுகளில், இந்தத் தடை புறக்கணிக்கப்படும், இருப்பினும் stderr-ல் உள்ள தகவல் feedback-ஆக model-க்குச் சென்றடையும்.
  • இதர exit code-கள் தடுக்காத பிழைகளாகக் கருதப்படும். அந்தச் செயல் தொடர்ந்து நடைபெறும். Failed with non-blocking status code: என்ற உரைக்குப் பிறகு, stderr-ன் முதல் வரியைக் கொண்ட hook பிழை அறிவிப்பு transcript-ல் காட்டப்படும்.

தடுத்தல் அல்லது அமைதியாக இருத்தல் என்பதைத் தாண்டி, exit 0-ஐப் பயன்படுத்தி stdout-ல் ஒரு JSON object-ஐ அச்சிடவும். ஒரு PreToolUse hook, permissionDecision மூலம் முடிவெடுக்கும்:

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "Database drops go through a migration, not through the agent."
  }
}

"allow" என்பது interactive prompt-ஐத் தவிர்க்கும், "deny" என்பது அழைப்பை ரத்து செய்து அதற்கான காரணத்தை model-க்கு அனுப்பும், மற்றும் "ask" என்பது prompt-ஐ வழக்கம்போலக் காட்டும். ஒரு hook-க்கு ஒரு பாணியைத் தேர்ந்தெடுக்கவும். Exit 2-ஐ stdout-ல் உள்ள JSON முடிவோடு இணைத்தால், நீங்கள் சரிபார்க்க வேண்டிய ஒரு குழப்பமான முடிவு கிடைக்கும்.

ஒரே நிகழ்விற்குப் பல hooks பொருந்தும்போது, அவை இணையாக (parallel) இயங்கும் மற்றும் ஒவ்வொன்றும் முழுமையாக நிறைவடையும். ஒரு hook-லிருந்து வரும் deny அதன் மற்ற hooks-ஐ நிறுத்தாது, எனவே ஒரு guardrail hook அழைப்பை மறுக்கும் அதே வேளையில், ஒரு logging hook தனது வரியைப் பதிவு செய்யும். Claude Code பின்னர் பதில்களை ஒருங்கிணைத்து, deny, defer, ask, allow என்ற வரிசையில் மிகவும் கட்டுப்பாடுடைய முடிவைத் தேர்ந்தெடுக்கும்.

உதாரணம் 1: ஒரு அழிவுகரமான கட்டளையை இயங்குவதற்கு முன்பே தடுத்தல்

இதை உங்கள் திட்டத்தில் .claude/hooks/block-destructive.sh ஆகச் சேமிக்கவும்:

#!/bin/bash
# Deny a Bash tool call whose command matches a banned pattern.
INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty')

for pattern in 'rm -rf /' 'mkfs' 'dd if=' 'DROP TABLE'; do
  if printf '%s' "$COMMAND" | grep -qiF -- "$pattern"; then
    echo "Blocked by policy: the command matches '$pattern'. A human runs this one." >&2
    exit 2
  fi
done

exit 0

இதை executable ஆக்கி, பின் .claude/settings.json-ல் உள்ள PreToolUse-ல் பதிவு செய்யவும்:

chmod +x .claude/hooks/block-destructive.sh
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-destructive.sh",
            "timeout": 10,
            "statusMessage": "Checking the command against policy"
          }
        ]
      }
    ]
  }
}

ஸ்கிரிப்டை நம்புவதற்கு முன் அதை நீங்களே சோதித்துப் பாருங்கள், ஏனெனில் அதன் சொந்த உள்ளீட்டிலேயே செயலிழக்கும் ஒரு hook, பாதுகாப்பைத் திறந்தே விட்டுவிடும்:

echo '{"tool_name":"Bash","tool_input":{"command":"rm -rf /var/lib/postgresql"}}' \
  | .claude/hooks/block-destructive.sh
echo $?

நீங்கள் Blocked by policy: வரியை stderr-ல் காண்பீர்கள் மற்றும் exit code 2 ஆக இருக்கும். ls -la போன்ற பாதிப்பில்லாத கட்டளையை உள்ளீடாகக் கொடுத்தால், எந்த வெளியீடும் இருக்காது மற்றும் exit code 0 ஆக இருக்கும். ஒரு session-ல், மறுக்கப்பட்ட அழைப்பு, அதற்கான காரணத்துடன் உங்கள் செய்தியைக் கொண்டு transcript-ல் தோன்றும்; model அந்தச் செய்தியைப் படித்து அதற்கேற்ப தன்னை மாற்றிக்கொள்ளும்.

ஒரு சிறப்பம்சம் இதைச் செய்வதற்குத் தகுதியாக்குகிறது: PreToolUse hooks அனுமதி-முறை (permission-mode) சரிபார்ப்பிற்கு முன்பே, அனைத்து அனுமதி முறைகளிலும் இயங்கும். எனவே, bypassPermissions-ன் கீழும் இந்தத் தடுப்பு செயல்படும். இதுவே Claude Code auto mode மற்றும் அதன் அனுமதி அமைப்புகள் உடன் இணைந்து இந்த hook-ஐப் பயனுள்ளதாக்குகிறது, அங்கு prompts குறைக்கப்பட்டாலும் hook தொடர்ந்து இயங்கும்.

இது என்ன என்பதைப் பற்றி நேர்மையாக இருங்கள். ஒரு கட்டளைச் சரத்தை (command string) pattern matching செய்வது, ஒரு agent கவனக்குறைவாகச் செயல்படுவதைத் தடுக்கும் ஒரு பாதுகாப்பு அரணே தவிர, அது ஒரு agent தந்திரமாகச் செயல்படுவதைத் தடுக்கும் எல்லையல்ல. ஏனெனில், அதே கட்டளையை உங்கள் grep பார்க்க முடியாத வடிவத்தில் எழுத முடியும். கடுமையான விதிகள் (hard rules) அனுமதி அமைப்பிலும், அந்த process இயங்கும் account-லும் மட்டுமே இருக்க வேண்டும்.

உதாரணம் 2: ஒவ்வொரு திருத்தத்திற்குப் பிறகும் format மற்றும் lint செய்தல்

PostToolUse மற்றும் Edit|Write matcher-ஐப் பயன்படுத்தி, ஏதேனும் ஒரு file-editing கருவி இயங்கிய பிறகு இதை இயக்கலாம். இதை .claude/hooks/after-edit.sh எனச் சேமிக்கவும்:

#!/bin/bash
# Format the edited file, then report lint failures back to the model.
INPUT=$(cat)
FILE=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')
[ -z "$FILE" ] && exit 0

case "$FILE" in
  *.py)
    ruff format "$FILE" >/dev/null 2>&1
    if ! ruff check "$FILE" >&2; then
      exit 2
    fi
    ;;
  *.sh)
    if ! shellcheck "$FILE" >&2; then
      exit 2
    fi
    ;;
esac

exit 0
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/after-edit.sh",
            "timeout": 60
          }
        ]
      }
    ]
  }
}

ஒரு Python கோப்பில் தவறான indentation கொண்ட function-ஐச் சேர்க்குமாறு Claude-இடம் கேட்டு, பின்னர் அந்தக் கோப்பைத் திறக்கவும். அது தானாகவே format செய்யப்பட்டுவிடும். hook சரியாக இயங்கியதை இது உறுதிப்படுத்துகிறது, ஏனெனில் hook வெற்றிகரமாக இயங்கினால் உரையாடலில் எந்தத் தகவலும் காட்டப்படாது.

இங்குள்ள exit 2 எதையும் மாற்றாது. PostToolUse கருவி ஏற்கனவே இயங்கிய பிறகுதான் செயல்படும், எனவே திருத்தம் எப்படியும் disk-ல் சேமிக்கப்பட்டுவிடும். exit 2-ஐப் பயன்படுத்துவதன் நோக்கம், ruff check வெளியீட்டை model-க்கு feedback-ஆகக் கொண்டு செல்வதே ஆகும்; இதன் மூலம் அது செய்த பிழையைத் தானாகவே சரிசெய்துவிடும். commit செய்யும் போது கண்டறியப்படும் lint பிழைக்கும், agent அதே தருணத்தில் சரிசெய்யும் பிழைக்கும் உள்ள வித்தியாசம் இதுதான்.

இங்கு இரண்டு matcher வரம்புகள் முக்கியம். Edit|Write shell command மூலம் மாற்றப்பட்ட கோப்புகளைக் கவனிக்காது, மேலும் Claude அடிக்கடி Bash மூலம் கோப்புகளை எழுதுவதால் இந்த இடைவெளி உண்மையானது. ஒவ்வொரு அழைப்பிற்கும் (per-call) coverage கிடைக்க, Bash-ஐயும் match செய்து, git status --porcelain மூலம் மாற்றப்பட்ட கோப்புகளை script பட்டியலிடுமாறு செய்யவும். ஒரு turn-க்கு ஒருமுறை (once-per-turn) coverage கிடைக்க, அந்த scan-ஐ Stop hook-ல் வைக்கவும்.

உதாரணம் 3: தணிக்கைக்காக ஒவ்வொரு tool அழைப்பையும் log செய்தல்

PostToolUse-ல் உள்ள ஒரு காலி matcher, ஒவ்வொரு tool-க்கும் செயல்படும். பதிவை home directory-ல் உள்ள ஒரு கோப்பிற்கு அனுப்பாமல் system journal-க்கு அனுப்புவது, அதை agent-ன் சொந்த shell-ன் அணுகலுக்கு அப்பாற்பட்டு வைத்திருக்கும்:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "jq -c '{time: now|todate, session: .session_id, cwd: .cwd, tool: .tool_name, input: .tool_input}' | logger -t claude-code -p local0.info"
          }
        ]
      }
    ]
  }
}

இதை journalctl -t claude-code -o cat | tail -n 5 மூலம் மீண்டும் வாசிக்கலாம். ஒவ்வொரு tool அழைப்பிற்கும் ஒரு JSON வரி இருக்க வேண்டும், புதியவை கடைசியில் இருக்கும். எதுவும் தோன்றவில்லை என்றால், hook இயங்கவில்லை என்று அர்த்தம்; அதற்கான தீர்வுகள் கீழே உள்ள troubleshooting பகுதியில் உள்ளன.

தோல்வியடைந்த அழைப்புகளைப் பிடிக்க PostToolUseFailure-ன் கீழ் அதே தொகுப்பைச் சேர்க்கவும், ஏனெனில் PostToolUse வெற்றியின் போது மட்டுமே செயல்படும், மேலும் தோல்வியடைந்த கட்டளைகளே பெரும்பாலும் முக்கியமானவை. உங்கள் home directory-ல் உள்ள கோப்பில் சேர்ப்பதை விட logger-ஐப் பயன்படுத்துவதற்கான காரணம் உரிமை (ownership) ஆகும்: ஒரு hook, agent-ன் shell இயங்கும் அதே பயனராகவே இயங்குகிறது, எனவே அந்த பயனர் எதில் எழுத முடியுமோ, அதை அந்த பயனரே அழிக்கவும் (truncate) முடியும். Journal, systemd-journald-ஆல் அதன் சொந்த கணக்கின் கீழ் எழுதப்படுகிறது.

ஒரு hook எவ்வளவு நேரம் இயங்கலாம்

ChartDefault hook timeout in seconds, by hook type and event
The data behind this chart
[
  {
    "label": "command, http or mcp_tool hook",
    "default_timeout_seconds": 600
  },
  {
    "label": "agent hook",
    "default_timeout_seconds": 60
  },
  {
    "label": "prompt hook",
    "default_timeout_seconds": 30
  },
  {
    "label": "command hook on UserPromptSubmit",
    "default_timeout_seconds": 30
  },
  {
    "label": "command hook on MessageDisplay",
    "default_timeout_seconds": 10
  },
  {
    "label": "any hook on SessionEnd",
    "default_timeout_seconds": 1.5
  }
]

ஒரு command hook இயல்பாக 600 வினாடிகள் வரை இயங்கும், இது பத்து நிமிடங்களுக்குச் சமம். சில நிகழ்வுகள் இந்த நேரத்தை வெகுவாகக் குறைக்கின்றன. SessionEnd hooks அனைத்தும் சேர்ந்து 1.5 வினாடிகள் என்ற பொதுவான கால வரம்பையே பகிர்ந்து கொள்கின்றன. எனவே, session முடிவில் செய்யப்படும் cleanup பணிகள் விரைவாக இருக்க வேண்டும். எனினும், hook-ல் நீண்ட timeout-ஐ அமைப்பதன் மூலம், அந்தப் பொதுவான கால வரம்பை 60 வினாடிகள் வரை அதிகரிக்க முடியும்.

தனது கால வரம்பை எட்டும் ஒரு hook ரத்து செய்யப்படும், அது எந்த முடிவையும் வழங்காது. ஒரு PreToolUse guardrail-ஐப் பொறுத்தவரை, இது எதையும் தடுக்காது என்று பொருள்: அந்த tool call வழக்கமான அனுமதி ஓட்டத்தில் (permission flow) தொடர்ந்து செல்லும். இதனாலேயே guardrail scripts-ஐச் சிறியதாக வைத்திருக்க வேண்டும். ஒரு log-ஐ வேறொரு இடத்திற்கு அனுப்புவது போன்ற, எவரும் காத்திருக்கத் தேவையில்லாத மெதுவான பணிகளுக்கு, "async": true-ஐ அமைக்கவும். அப்போது அந்த hook பின்னணியில் இயங்கும், அது tool call-ஐத் தாமதப்படுத்தாது.

Hooks, rules files, skills மற்றும் MCP servers

ஒரு agent-ன் செயல்பாட்டை மாற்றும் நான்கு விஷயங்கள் குழப்பத்தை ஏற்படுத்தலாம். அவற்றில் ஒன்று மட்டுமே பரிந்துரை என்பதைத் தாண்டி கட்டாயமாகச் செயல்படுகிறது.

ஒரு rules file (CLAUDE.md, அல்லது .claude/rules/-ன் கீழ் உள்ள ஒரு கோப்பு) என்பது model-ன் context-ல் ஏற்றப்படும் உரை ஆகும். இது நடத்தையை வடிவமைக்குமே தவிர, எதையும் கட்டாயப்படுத்தாது. நீண்ட உரையாடல், பெரிய diff மற்றும் புதிய பயனர் கோரிக்கை ஆகியவற்றிற்கு மத்தியில், இதில் உள்ள ஒரு வரி கவனிக்கப்படாமல் போகலாம். நீங்கள் எழுதிய அறிவுறுத்தல்களை agents புறக்கணிப்பதற்கான சாதாரண காரணம் இதுதான்.

ஒரு skill என்பது, அது பொருத்தமானது என்று model கருதும் போது ஏற்றப்படும் அறிவுறுத்தல்கள் மற்றும் scripts அடங்கிய கோப்புறை ஆகும். அந்தத் தீர்மானமே ஒரு skill-ன் அடிப்படை, அதே சமயம் அதுவே அதன் எல்லையும் கூட: இறுதி முடிவு model-ஆலேயே எடுக்கப்படுகிறது. Ponytail, இது ஒரு agent-ஐ மிகச்சிறிய மாற்றத்தை நோக்கித் தள்ளுகிறது போன்ற ஒரு skill-ல் இந்த இரண்டு பக்கங்களையும் நீங்கள் காணலாம். இது ஒரு பணியை அணுகும் முறையை எந்த ஒரு hook-ஆலும் செய்ய முடியாத வகையில் வடிவமைக்கிறது, ஆனால் model அதை ஏற்றத் தேர்ந்தெடுக்கும் வரை மட்டுமே இது செயல்படும்.

ஒரு MCP (model context protocol) server, model-க்கு அழைப்பதற்கான புதிய கருவிகளை வழங்குகிறது. இது agent-ன் செயல்பாட்டு எல்லையை விரிவுபடுத்துகிறது. இது agent-ஐ எதையும் செய்யத் தூண்டுவதில்லை, மேலும் இதை நீங்கள் தனிப்பட்ட process-ஆக இயக்க வேண்டும், இது ஒரு தனிப் பணியாகும்: VPS-ல் MCP servers-ஐ இயக்குவது என்பதைப் பார்க்கவும்.

இந்த நான்கில், model-ன் தேர்வு இன்றி இயங்கும் ஒரே விஷயம் hook மட்டுமே. ஒரு விருப்பத்திற்கு rules file-ஐயும், ஒரு செயல்முறைக்கு skill-ஐயும் பயன்படுத்தவும். ஒவ்வொரு முறையும் நடக்க வேண்டிய அல்லது ஒருபோதும் நடக்கக்கூடாத ஒரு செயலுக்கு hook-ஐப் பயன்படுத்தவும். ஒரு skill எப்போது rules file-ஐ விடச் சிறந்தது என்பது உட்பட விரிவான ஒப்பீட்டிற்கு, skills, MCP மற்றும் rules files ஒப்பீடு என்பதைப் பார்க்கவும்.

Plugin என்பது ஐந்தாவது வழிமுறை அல்ல, அது ஒரு தொகுப்பு முறை மட்டுமே. இது hooks மற்றும் skills-ஐ ஒரே install செய்யக்கூடிய அலகாக மாற்றுகிறது. இதன் மூலம் ஒரு குழு ஒரே guardrail-ஐ அனைத்து கணினிகளிலும் பயன்படுத்த முடியும்: Claude Code plugins எவ்வாறு செயல்படுகின்றன என்பதைப் பார்க்கவும்.

பகிரப்பட்ட VPS-ல் பாதுகாப்பு குறித்த முடிவு

Hook என்பது agent-ஆல் தூண்டப்படும் ஒரு code ஆகும். இது Claude Code-ஐத் தொடங்கிய பயனரின் உரிமையிலேயே இயங்கும். இது அந்தப் பயனரின் environment மற்றும் file permissions-ஐப் பெறும். ஒரு laptop-ல் இது ஒரு workflow சார்ந்த கேள்வி. ஆனால், ஒரு agent கவனிக்கப்படாமல் இயங்கும் VPS-ல், இது நான்கு நடைமுறைப் பகுதிகளைக் கொண்ட ஒரு பாதுகாப்புச் சிக்கலாகும்.

Repository-ல் உள்ள ஒரு hook என்பது நீங்கள் எழுதாத code ஆகும். .claude/settings.json commit செய்யப்படுவதால், ஒரு repository-ஐ clone செய்து அதற்குள் session-ஐத் தொடங்குவது, அந்த repository-உடன் வந்த hooks-ஐப் பதிவு செய்யக்கூடும். Claude Code, அந்த folder-க்கான workspace trust உரையாடல் பெட்டி மூலம் project hooks-ஐக் கட்டுப்படுத்துகிறது. அதாவது, trust-ஐ ஏற்றுக்கொள்வது என்பது அவற்றை இயக்க நீங்கள் எடுக்கும் முடிவாகும். முதலில் hooks தொகுப்பைப் படிக்கவும்.

Hook முழுமையான tool input-ஐக் காணும். tool_input-ஐ log செய்யும் ஒரு audit hook, ஒவ்வொரு command-ன் ஒவ்வொரு argument-ஐயும் ஒரு file-ல் எழுதும். இதில் command line-ல் இருக்கும் எந்தவொரு token-ம் அடங்கும். அந்த log-க்கு, secret-க்குத் தேவைப்படும் அதே பாதுகாப்பு தேவைப்படுகிறது. இது AI agent-ன் அணுகலுக்கு வெளியே ரகசியங்களை வைத்திருத்தல் என்ற பரந்த சிக்கலின் ஒரு பகுதியாகும்.

Hook model-ன் context-ல் எழுத முடியும். ஒரு SessionStart அல்லது UserPromptSubmit hook stdout-க்கு எதை அனுப்புகிறதோ, அது உரையாடலில் சேர்க்கப்படும். வெளியிலிருந்து, ஒரு issue tracker-லிருந்து அல்லது log file-லிருந்து text-ஐ உள்ளிடும் ஒரு hook, நீங்கள் நீங்களே தட்டச்சு செய்தது போல நம்பகத்தன்மையற்ற text-ஐ model-க்கு வழங்குகிறது. ஒரே VPS-ல் உள்ள மற்றொரு Claude Code session-லிருந்து ஒரு குறிப்பை அனுப்பும் hook-ம் இதையே செய்கிறது. ஒரு agent-ன் வெளியீடு, issue tracker-ஐ விட அதிக நம்பிக்கைக்குரியது அல்ல. அந்த stdout-ஐ வெளியீடாகக் கருதாமல், உள்ளீடாகக் கருதி கையாளவும்.

உரிமைகளே (Privilege) உண்மையான கட்டுப்பாடு. Agent-ஐ, அதற்குத் தேவையான sudo விதிகள் மட்டுமே கொண்ட ஒரு பிரத்யேக, குறைந்த அதிகாரம் கொண்ட பயனராக இயக்கவும். ஒரு PreToolUse deny இருப்பது நல்லது, ஆனால் அது வடிவமைப்பிலேயே சிறந்த முயற்சியாகவே (best effort) இருக்கும்: if filter-ஐப் பற்றியும் இதுவே கூறுகிறது. உங்களுக்குக் கடுமையான தடை (hard deny) தேவைப்படும்போது, permission system-ஐப் பயன்படுத்தும்படி அது அறிவுறுத்துகிறது. Permission விதிகளும், process இயங்கும் account-ம் மட்டுமே அழுத்தமான சூழலில் பாதுகாப்பை உறுதி செய்யும்.

ஒவ்வொரு configuration-லும் ஒரு பண்பு மாறாமல் இருக்கும். PreToolUse hooks, அனைத்து permission mode-களிலும் permission-mode சரிபார்ப்புக்கு முன்பே இயங்கும். எனவே, deny-ஐத் திருப்பி அனுப்பும் ஒரு hook, bypassPermissions-ன் கீழும் tool-ஐத் தடுக்கும். Hooks, permission விதிகள் அனுமதிப்பதை மேலும் கட்டுப்படுத்த முடியும். ஆனால், அவற்றை தளர்த்த முடியாது.

எனது hook ஏன் செயல்படவில்லை?

இதை வரிசைப்படி சரிபார்க்கவும். ஒவ்வொரு படியும் நீங்கள் காணும் அறிகுறியைக் குறிப்பிடுகிறது.

  • /hooks-ஐ இயக்கி, நீங்கள் எதிர்பார்த்த நிகழ்வின் கீழ் hook உள்ளதா என்று பார்க்கவும். மெனுவில் hook இல்லை என்றால், settings கோப்பில் JSON syntax பிழை இருக்கலாம்; ஏனெனில் trailing commas மற்றும் comments அனுமதிக்கப்படாது, அல்லது கோப்பு மேலே குறிப்பிடப்பட்டுள்ள ஆறு இடங்களில் ஒன்றில் இல்லை என்று அர்த்தம்.
  • Matcher-ஐ tool பெயருடன் துல்லியமாக ஒப்பிடவும். Matchers case sensitive என்பதால், "bash" என்பது ஒருபோதும் Bash tool-உடன் பொருந்தாது.
  • மேலே உள்ள உதாரணம் 1-ல் உள்ளது போல, sample input-ஐக் கொண்டு script-ஐ நீங்களே கைமுறையாக இயக்கவும். நீங்கள் எதிர்பாராத exit code கிடைத்தால், அது உங்கள் script-ல் உள்ள பிழை; Claude Code இதை decision-ஆகக் கருதாமல் hook பிழையாகவே தெரிவிக்கும்.
  • jq: command not found என்ற அறிவிப்பு வந்தால், அந்த machine-ல் jq இல்லை என்று அர்த்தம். உங்கள் சொந்த script-க்கு command not found கிடைத்தால், path சரியாகக் கிடைக்கவில்லை என்று பொருள்; எனவே ${CLAUDE_PROJECT_DIR} அல்லது absolute path-ஐப் பயன்படுத்தவும். script இயங்கவே இல்லை என்றால், அது executable நிலையில் இல்லாமல் இருக்கலாம்.
  • hook சரியான JSON-ஐ அச்சிடுகிறது, ஆனால் எதுவும் நடக்கவில்லை. shell-form hook sh -c வழியாக இயங்குகிறது; உங்கள் shell profile ஏதேனும் banner-ஐ அச்சிட்டால், அந்த banner உங்கள் JSON-க்கு முன்னால் சேர்க்கப்படும். Stdout இப்போது {-ல் தொடங்காது, எனவே Claude Code முழுவதையும் plain text-ஆகக் கருதி decision-ஐப் புறக்கணிக்கும். exit 0 நிலையில், debug log-ஐத் தவிர வேறு எங்கும் தகவல் இருக்காது. உங்கள் profile-ல் உள்ள ஏதேனும் echo-ஐ interactive shells-ல் மட்டும் இயங்குமாறு மாற்றவும்.
  • இன்னும் சிக்கல் நீடித்தால்: claude --debug-file /tmp/claude.log மூலம் session-ஐத் தொடங்கி, இரண்டாவது terminal-ல் tail -f /tmp/claude.log-ஐ இயக்கவும். எந்த hook பொருந்தியது, ஒவ்வொன்றும் என்ன exit code-ஐத் திரும்ப அளித்தது, மற்றும் அவை stdout மற்றும் stderr-ல் என்ன எழுதின என்பதை debug log பதிவு செய்யும்.

FAQ

Claude Code hook மற்றும் CLAUDE.md அறிவுறுத்தலுக்கு இடையே உள்ள வேறுபாடு என்ன?

ஒரு CLAUDE.md அறிவுறுத்தல் என்பது மாதிரியின் (model) சூழலில் உள்ள உரை ஆகும். எனவே, இது உரையாடல் மற்றும் தற்போதைய கோரிக்கையுடன் கவனத்தைப் பெறுவதற்குப் போட்டியிடும்; மாதிரி இதை மற்றவற்றுடன் ஒப்பிட்டு எடைபோட முடியும். ஒரு hook என்பது Claude Code அதன் வாழ்க்கைச் சுழற்சியில் ஒரு குறிப்பிட்ட புள்ளியில் இயக்கும் shell command ஆகும். எனவே, மாதிரி என்ன முடிவெடுத்தாலும், அந்த நிகழ்வு நடக்கும்போதெல்லாம் இது இயங்கும். ஒரு விருப்பத்திற்கு (preference) அறிவுறுத்தலைப் பயன்படுத்தவும். எப்போதும் நடக்க வேண்டிய ஒரு படி அல்லது ஒருபோதும் நடக்கக்கூடாத ஒரு செயலுக்கு hook-ஐப் பயன்படுத்தவும்.

ஒரு குறிப்பிட்ட shell command-ஐ Claude Code இயக்குவதைத் தடுப்பது எப்படி?

ஒரு PreToolUse hook-ஐ, Bash matcher உடன் பதிவு செய்யவும். இது .tool_input.command-லிருந்து கட்டளையை வாசித்து, stderr-க்கு ஒரு காரணத்தை எழுதி, 2 என்ற நிலையில் வெளியேற வேண்டும் (exit 2). Claude Code அந்த அழைப்பை ரத்து செய்து, உங்கள் காரணத்தை மாதிரிக்குக் காட்டும். இது permission-mode சரிபார்ப்புக்கு முன்பே நடப்பதால், bypassPermissions பயன்முறையிலும் இந்தத் தடை நீடிக்கும். ஒரு கட்டளைச் சரத்தில் pattern matching செய்வது ஒரு பாதுகாப்பு அரண் மட்டுமே, இது ஒரு முழுமையான பாதுகாப்பு எல்லை அல்ல. ஏனெனில், அதே கட்டளையை pattern-க்குத் தெரியாத வகையில் எழுத முடியும். எனவே, இதை permission விதிகள் மற்றும் சலுகைகள் இல்லாத (unprivileged) கணக்குடன் இணைத்து வலுப்படுத்தவும்.

எனது hook சரியான JSON-ஐ அச்சிடுகிறது, ஆனால் எதுவும் நடக்கவில்லை. ஏன்?

இதற்கு மிக முக்கியமான காரணம் உங்கள் shell profile ஆகும். args புலம் இல்லாத ஒரு hook, sh -c வழியாக இயங்குகிறது. சில profile-கள் ஒவ்வொரு shell-லும் ஒரு banner-ஐ அச்சிடும், இது உங்கள் JSON-க்கு முன்னால் stdout-ல் வந்துவிடும். வெளியீடு {-ல் தொடங்காததால், Claude Code அதை வெறும் உரையாகக் கருதி முடிவைப் புறக்கணித்துவிடும். exit 0 நிலையில், transcript-ல் எதுவும் காட்டப்படாது. உங்கள் profile-ல் உள்ள ஏதேனும் echo-ஐ interactive-shell சோதனை மூலம் பாதுகாக்கவும், பின்னர் claude --debug-file /tmp/claude.log-லிருந்து debug log-ஐ வாசிப்பதன் மூலம் திருத்தத்தை உறுதிப்படுத்தவும்.

பகிரப்பட்ட server-ல் Claude Code hook-களை இயக்குவது பாதுகாப்பானதா?

Hook-கள் Claude Code-ஐத் தொடங்கிய பயனராகவே இயங்குகின்றன, அந்தப் பயனரின் கோப்பு அனுமதிகளுடன் (file permissions) அவை செயல்படும். எனவே, அந்தக் கணக்கினால் எதைச் செய்ய முடியுமோ, அதை hook-ஆலும் செய்ய முடியும். இரண்டு பழக்கங்கள் பெரும்பாலான அபாயங்களைக் குறைக்கும்: agent-ஐ ஒரு பிரத்யேகமான, சலுகைகள் இல்லாத கணக்கில், குறுகிய sudo கொள்கையுடன் இயக்கவும். மேலும், ஒரு களஞ்சியத்தின் (repository) workspace trust உரையாடலை ஏற்றுக்கொள்வதற்கு முன், அதன் hooks தொகுதியை வாசிக்கவும். ஏனெனில் project hook-கள் .claude/settings.json-க்குள் வருகின்றன. எதையும் இயக்கக்கூடாது என நீங்கள் விரும்பினால், உங்கள் settings கோப்பில் "disableAllHooks": true-ஐ அமைக்கவும்.