सामग्री पर जाएँ
kenjtecJournal
Journal में खोजें

Claude Code hooks: बार-बार लागू होने वाले नियम निश्चित वर्कफ़्लो चरण बनते हैं

Hooks, Claude Code वर्कफ़्लो की घटनाओं से जुड़ते हैं। एक छोटी लेखन-सुरक्षा निर्णय-आउटपुट, पथ-जाँच और ऐसे नियंत्रण की सीमाओं को दिखाती है।

लेना साइकिल के पुर्ज़ों को एक छोटे रैंप से एक जाँच-द्वार की ओर लुढ़काती है; एक संदर्भ पुर्ज़ा काँच के बर्तन में रखा है। एआई चित्रण।

“कृपया केवल ड्राफ़्ट ही बदलें” एक समझदारी भरा कार्य-निर्देश है। लेकिन यह अभी कोई तकनीकी जाँच-बिंदु नहीं है। एक hook किसी बार-बार लागू होने वाले नियम को उस बिंदु पर लागू कर सकता है जहाँ कोई विशिष्ट क्रिया तैयार की जा चुकी हो। इससे एक सामान्य अनुरोध किसी विशेष टूल कॉल के बारे में एक सत्यापन-योग्य निर्णय में बदल जाता है।

यह Claude Code संदर्भ अन्य घटनाओं के साथ PreToolUse का भी वर्णन करता है: यह टूल पैरामीटर बनाए जाने के बाद और कॉल के संसाधित होने से पहले होता है। hook एक निर्णय लौटा सकता है। निम्नलिखित उदाहरण हमारे अपने एक मसौदे की व्याख्या करते हैं; इनके लिए कोई hook कॉन्फ़िगरेशन न तो इंस्टॉल किया गया और न ही चलाया गया।

निर्णय-बिंदु पर कौन-सी जानकारी उपलब्ध होती है?

हमारे शिक्षण प्रोजेक्ट में एक ड्राफ़्ट फ़ोल्डर और उसके बगल में एक संदर्भ फ़ाइल है। एजेंट को केवल ड्राफ़्ट संपादित करने चाहिए। इसलिए एक समझदारी भरा नियम किसी लेखन-क्रिया के विशिष्ट लक्ष्य को देखता है। वह यह तय नहीं करता कि बातचीत की पूरी सामग्री भरोसेमंद है या नहीं।

इंटरफ़ेस टूल का नाम और इनपुट प्रदान करता है। किसी उपयुक्त फ़ाइल अनुरोध के लिए इन्हीं से लक्ष्य निर्धारित किया जा सकता है। किसी अज्ञात टूल या समझ में न आने वाले इनपुट को एक अलग स्थिति उत्पन्न करनी चाहिए। जाँच प्रोग्राम में कोई मौन त्रुटि सफलतापूर्वक जाँचे गए पथ जैसी नहीं दिखनी चाहिए।

निर्णय एक संरचित रिटर्न मान है

प्रलेखित PreToolUse संरचना में एक उदाहरणात्मक अस्वीकृति मान इस प्रकार दिखता है। कारण हमारे अपने शब्दों में है; यह स्थानीय नियम का वर्णन करता है, उपयोगकर्ता के किसी सामान्य आकलन का नहीं।

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "The target file is outside the drafts area."
  }
}

यह अंश रिटर्न मान है, कोई पूर्ण जाँच प्रोग्राम नहीं। इसमें न तो hook का पंजीकरण है और न ही इनपुट को पढ़ना और जाँचना। यही अलगाव सहायक है: नियम, तकनीकी मूल्यांकन और इंटरफ़ेस आउटपुट को स्वतंत्र रूप से देखा जा सकता है।

किसी पथ से संबंधित होना मेल खाते उपसर्ग से कहीं अधिक है

वर्ण-शृंखलाओं की केवल तुलना मिलते-जुलते नामों वाले पड़ोसी फ़ोल्डरों में भ्रम पैदा कर सकती है। इसलिए आपके अपने नियम को स्पष्ट रूप से हल किए गए पथों के साथ काम करना चाहिए और जाँचना चाहिए कि लक्ष्य वास्तव में इच्छित रूट फ़ोल्डर से संबंधित है या नहीं। उपयोग में लिए जा रहे वातावरण में अलग-अलग विभाजकों और लिंक को ध्यान में रखना होगा।

own rule logic, schematic:
  Input fully readable? Otherwise check status unknown.
  Tool belongs to the write path being handled? Otherwise not checked.
  Resolve target and permitted root unambiguously.
  Target really inside the root? Otherwise deny.
  Assess only the specific call being handled.

यह रूपरेखा जानबूझकर पूर्ण सुरक्षा का संकेत नहीं देती। विशेष रूप से बाहरी प्रोग्राम, जो स्वयं आगे की फ़ाइलें बदलते हैं, किसी एकल फ़ाइल फ़ील्ड से अलग विचार की माँग करते हैं। किसी अनुमत प्रारंभिक फ़ाइल से अभी यह पता नहीं चलता कि कोई स्क्रिप्ट आगे कौन-सी क्रियाएँ करती है।

चार परीक्षण पहुँच को दृश्यमान बनाते हैं

एक अस्थायी प्रोजेक्ट में एक अनुमत फ़ाइल, एक संरक्षित संदर्भ और मिलते-जुलते नाम वाला एक पड़ोसी फ़ोल्डर बनाएँ। एक अमान्य इनपुट जोड़ें। हर मामले के लिए पहले से लिख लें कि कौन-सा निर्णय अपेक्षित है। फिर रिटर्न मान और वास्तविक निष्पादन, दोनों को देखें।

जाँच प्रोग्राम की स्वयं की विफलता का भी परीक्षण करें। विफलता का व्यवहार घटना और कॉन्फ़िगरेशन पर निर्भर करता है और इसलिए स्वीकृति का हिस्सा है। कोई संदेश न आना इस बात का प्रमाण नहीं है कि नियम की जाँच सफलतापूर्वक हुई।

हर परीक्षण के लिए यह भी नोट करें कि hook तक पहुँचा गया भी या नहीं। कोई क्रिया जो किसी अलग मार्ग से जाती है, नियम को दरकिनार कर सकती है, भले ही उसकी आंतरिक पथ-जाँच ने गलत तरीके से काम न किया हो।

hook कोई पूर्ण सुरक्षा ढाँचा नहीं है

PreToolUse टूल कॉल से संबंधित है। संदर्भ अन्य मार्गों से भी सत्र में प्रवेश कर सकता है; वर्तमान संदर्भ इस संबंध में सीमाओं का स्पष्ट रूप से वर्णन करता है। इसलिए hook न तो अनुमतियों का स्थान लेता है और न ही वातावरण के नियंत्रण का, और यह prompt injection के विरुद्ध कोई सामान्य सुरक्षा उपाय नहीं है।

एक ही स्थानीय नियम से शुरुआत करें और उन मार्गों का दस्तावेज़ीकरण करें जिन्हें वह कवर करता है और जिन्हें कवर नहीं करता। तकनीकी लाभ एक समझने योग्य जाँच-बिंदु में निहित है। यह जाँच-बिंदु आपके संस्करण में सही ढंग से स्थापित है या नहीं, यह उपयुक्त इंटरफ़ेस के साथ एक वास्तविक परीक्षण से ही दिखाया जा सकता है।

स्रोत और दस्तावेज़ीकरण की स्थिति: 25 अक्टूबर 2026।

हैम्बर्ग हमारा शुरुआती बिंदु है।

उपयोगी ज्ञान आपके साथ चलता है।

हैम्बर्ग से AI का व्यावहारिक ज्ञान, दुनिया के लिए।

सेव किए गए लेख