Claude Code की approval में उलझन बंद: read/edit/run/deploy का decision log कैसे बनाएं

शुक्रवार की शाम थी। मैंने Claude Code से कहा, “बस इस पेज के लिंक ठीक कर दो।” जवाब में पूरी स्क्रीन भर देने वाला confirmation आया। “क्या यह command चलाना ठीक है?” थका हुआ मैं content ढंग से पढ़े बिना ही Enter दबा बैठा।

अगली सुबह production साइट पर pricing की जानकारी बदल चुकी थी। लिंक के साथ-साथ AI ने “इसी मौके पर” वह फ़ाइल भी ठीक कर दी थी जिसमें दाम लिखे थे। allow का बटन दबाने वाला, बिना किसी शक के, मैं ही था।

दिक्कत AI की समझदारी में नहीं थी। असली दिक्कत यह थी कि कल जिस काम को मैंने OK किया था और आज जिसे रोकना चाहिए था, उसकी रेखा सिर्फ़ मेरे दिमाग़ में थी और हर बार हिल जाती थी। अगर उस दिन के मूड पर “चलो ठीक है” चलता रहे, तो हादसा सिर्फ़ समय की बात है। आज मैं यही रेखा दिमाग़ से बाहर निकालने का तरीक़ा — यानी “approval log” — लिखने जा रहा हूँ।

मुख्य बातें

Claude Code की approval को “read / edit / run / deploy” — पढ़ना, बदलना, चलाना, publish करना — इन चार हिस्सों में बाँट दें तो उलझन ख़त्म हो जाती है।
हर काम को “allow / ask / block” में डालें, और कारण तथा proof command रोज़ एक ही फ़ाइल में लिखें।
AI को सौंपें सिर्फ़ खोजबीन और draft; इंसान अपने हाथ में रखे — दाम, production publish, और delete, ये चार चीज़ें।
कॉपी-पेस्ट करने लायक log का template और AI से बँटवारा draft करवाने वाला prompt नीचे दिया है।
उलझन हो तो “allow” मत करना। सिर्फ़ इतने से ही “इसी मौके पर हो गया” वाले हादसे लगभग ख़त्म हो गए।

approval को “read / edit / run / deploy” चार हिस्सों में बाँटें

Claude Code चलाते वक़्त तरह-तरह के confirmation आते रहते हैं। इन सबको एक साथ “Yes या No” की तरह सोचते हैं, इसी से हर बार थकान होती है। काम को चार किस्म में बाँट दें तो निर्णय एकदम हल्का हो जाता है।

read (पढ़ना): फ़ाइल या log का content सिर्फ़ देखना। आम तौर पर allow रखने में कोई दिक्कत नहीं।
edit (बदलना): फ़ाइल को बदल देना। ब्लॉग की वर्तनी ठीक करना हल्का काम है। दाम वाली टेबल बिलकुल दूसरी चीज़ है।
run (चलाना): कोई command चलाना। काम की जाँच हल्की है, पर बाहर असर डालने वाली command पर सावधानी।
deploy (publish करना): production साइट पर बदलाव लाइव करना। इसे मैं हमेशा आख़िरी किला मानकर चलता हूँ।

एक ही “edit” में भी ब्लॉग के मुख्य पाठ की वर्तनी और payment settings की फ़ाइल का वज़न ज़मीन-आसमान का है। इसलिए मैंने काम के किस्म के साथ-साथ “कौन-सी फ़ाइल है” — यह भी तय करना शुरू किया।

निर्णय को तीन स्तर में बाँटें

चार किस्म में बाँटने के बाद हर एक को तीन स्तर में डालें। कोई भारी शब्द की ज़रूरत नहीं।

स्तर	मतलब	उदाहरण
allow	चुपचाप आगे बढ़ने दें	article फ़ोल्डर पढ़ना, मुख्य पाठ की वर्तनी ठीक करना
ask	एक बार मुझसे पूछें	pricing फ़ाइल बदलना, production पर publish करना
block	इस बार करने ही न दें	फ़ाइलों का एकमुश्त delete, ज़बरदस्ती overwrite

तरकीब सिर्फ़ एक है। ज़रा-सी भी उलझन हो तो उसे “allow” में मत डालो। फ़िलहाल “ask” में रख दो। बाद में जब समझ आ जाए कि “यह तो हर बार सुरक्षित है”, तब इसे “allow” में चढ़ा देना। शुरू में सब कुछ अपने हाथ में रखो, और जो सुरक्षित साबित हो जाए सिर्फ़ उसी की लगाम ढीली करो। बस इसी क्रम का पालन करने से शुरुआत वाला pricing हादसा होना बंद हो जाता है।

रोज़ एक फ़ाइल में लिखें: log का template

दिमाग़ में याद रखने की कोशिश में ही गड़बड़ होती है। दिन में एक फ़ाइल, उस दिन का बँटवारा बस लिख देना है। format कुछ भी हो सकता है, पर मैं इसी रूप पर आकर ठहरा। कॉपी-पेस्ट करके सीधे इस्तेमाल कर सकते हैं।

{
  "date": "2026-06-07",
  "scope": "सिर्फ़ article का मुख्य पाठ और CTA लिंक बदलना",
  "read":   { "allow": ["site/src/content/**", "site/src/lib/gumroadProducts.ts"] },
  "edit":   { "allow": ["नई article फ़ाइलें"], "ask": ["pricing", "payment settings", "production secrets"] },
  "run":    { "allow": ["npm run build", "public URL का दिखना जाँचना"], "ask": ["deploy", "git push"] },
  "deploy": { "askUntil": ["build pass हो", "public URL का h1 सही हो", "हर भाषा का दिखना आँखों से जाँचा हो"] },
  "nextTime": "pricing आगे भी ask ही रहे। article CTA बदलना सुरक्षित जाँच के बाद allow करें।"
}

लिखने में 2–3 मिनट लगते हैं। पर यही 2–3 मिनट अगले दिन के उस 10 मिनट को मिटा देते हैं, जब आप सोचते रहते हैं “अरे, यह कल मैंने कैसे किया था?”। scope की वह एक पंक्ति चुपचाप बहुत काम आती है। आज का काम कहाँ तक है यह पहले लिख देने से, AI उसके बाहर निकलते ही आपको पता चल जाता है।

AI को क्या सौंपें, और इंसान क्या तय करे

इन दोनों को मिला दिया तो हादसा तय है। रेखा साफ़ खींच लेते हैं।

AI को सौंपना ठीक है

कौन-सी फ़ाइल का संबंध हो सकता है, यह खोजना
बदलाव का draft बनाना
बदलाव से पहले और बाद का diff दिखाना
“build pass होता है या नहीं” जाँचने वाली command चलाना

इंसान ज़रूर अपने हाथ में रखे

दाम, payment, या आवेदन फ़ॉर्म को छूने वाला बदलाव
production साइट पर publish (publish का बटन ख़ुद दबाएँ)
फ़ाइल या data का delete
वह काम जिसकी undo की प्रक्रिया आप समझा न सकें

मेरा नियम सीधा है — “पैसा”, “production”, “delete”, “वापस नहीं ला सकते” — इन चार में से कोई भी जुड़ा हो तो आख़िरी निर्णय अपने हाथ से लो। उल्टे शब्दों में, इनके अलावा बाकी खोजबीन और draft बेझिझक AI को फेंक दो। यही सोच नॉन-इंजीनियर के लिए Claude Code परिचय में भी छुई है, पर तकनीकी ज्ञान के बिना भी अगर आप तय कर लें कि “पैसा और production सिर्फ़ मैं”, तो काफ़ी हद तक सुरक्षित रहेंगे।

AI से बँटवारा draft करवाने वाला prompt

बँटवारा ख़ुद ही AI से भी करवाया जा सकता है। पर निकले हुए नतीजे पर आँख मूँदकर भरोसा मत करना; आख़िर में ख़ुद देखना। नीचे दिया निर्देश सीधे पेस्ट करके इस्तेमाल करें।

आज के Claude Code काम के लिए, हर operation को "allow / ask / block" में बाँटिए।
चार किस्में हैं: read / edit / run / deploy.

हर किस्म के लिए यह लौटाइए:
1. जिन्हें allow किया जा सकता है उनकी सूची
2. जिन्हें एक बार ask करना चाहिए उनकी सूची
3. जिन्हें इस बार block करना है उनकी सूची
4. सुरक्षा जाँचने के लिए proof command (उदाहरण: npm run build)
5. अगली बार के लिए note (ask से allow में चढ़ाने की शर्त)

pricing, payment, production publish और delete से जुड़े operation,
उलझन हो तो "ask" में डालिए।

असली बात आख़िरी पंक्ति है। इसे डाल देने से AI अपने आप “यह तो allow कर ही देना चाहिए” कहकर निर्णय ढीला नहीं करता। prompt लिखने की कला और गहराई से सीखनी हो तो Claude Code का advanced prompt design भी देख लीजिए।

ऐसी जगहों पर काम आता है (तीन उदाहरण)

1. ब्लॉग article बदलना लोकप्रिय article के नीचे लगा कोई एक आवेदन लिंक बदलना है। ऐसे में “जो-जो संबंधित हो वह ठीक कर दो” कह दें तो दायरा बहुत चौड़ा हो जाता है। पहले “जिन फ़ाइलों को छूना ठीक है”, “जिन्हें नहीं छूना”, और “जिस public URL को जाँचना है” — यह log में लिख दें। तब काम के बाद की जाँच “लगता है ठीक है” से बदलकर “इस आधार पर publish कर सकते हैं” बन जाती है।

2. पूछताछ की छँटाई आई हुई पूछताछ AI से पढ़वाकर, जिनमें संभावना दिखे सिर्फ़ वही बताने को कहें। पढ़ना “allow” में रखना ठीक है। पर customer सूची में जोड़ना “ask” में ही रहे। AI छँटाई में ग़लती करे तो भी, production data में अपने आप लिखने से पहले रुक जाएगा।

3. बहुभाषी article का publish से पहले check frontmatter में भाषा सही होने पर भी, मुख्य पाठ अंग्रेज़ी में ही रह जाता है — ऐसा होता है। हर भाषा में heading, शुरुआत और CTA लिंक देखकर जाँचें कि उस भाषा का पाठक आगे क्या करना है समझ पा रहा है या नहीं। इस आँखों वाली जाँच को “publish से पहले की check सूची” के रूप में log में पक्का कर दें।

कॉपी-पेस्ट करके चलने वाली: approval log की check script

log लिख भी लें, पर असली “publish से पहले की जाँच” छोड़ दें तो कोई मतलब नहीं। इसलिए publish से पहले हमेशा गुज़रने वाली जाँच को एक script में डाल देते हैं। build pass होता है या नहीं, और production URL का heading सही है या नहीं — यह मशीन से जँचवाने का उदाहरण। Node.js हो तो चल जाएगा।

node check-before-deploy.mjs https://claudecode-lab.com/blog/claude-code-permission-decision-log/

अंदर बस इतना है।

import { execSync } from "node:child_process";

// argument में दिए गए public URL को जाँचें
const url = process.argv[2];
if (!url) {
  console.error("जिस public URL को जाँचना है उसे pass कीजिए");
  process.exit(1);
}

// 1. build pass होता है या नहीं जाँचें (यहाँ गिरा तो publish नहीं करते)
try {
  console.log("build जाँच रहे हैं...");
  execSync("npm run build", { stdio: "inherit" });
} catch {
  console.error("build विफल हुआ। publish रोक रहे हैं।");
  process.exit(1);
}

// 2. public URL पर एक h1 heading है या नहीं जाँचें
const res = await fetch(url);
const html = await res.text();
const h1Count = (html.match(/<h1[\s>]/g) || []).length;

if (res.status !== 200) {
  console.error(`URL नहीं खुल रहा (status code: ${res.status})। publish पर दोबारा सोचें।`);
  process.exit(1);
}
if (h1Count !== 1) {
  console.error(`h1 heading ${h1Count} हैं। एक करके फिर publish करें।`);
  process.exit(1);
}

console.log("build, URL और heading की जाँच pass हुई। publish करना ठीक है।");

यह script हरी होने पर ही “deploy” को allow करें। उल्टे शब्दों में, जो हरी न हो उसे चाहे कुछ भी हो publish मत करें। निर्णय को इंसान के मूड के बजाय मशीन के ✓/✗ के हवाले करना ही तरकीब है।

जो ग़लतियाँ अक्सर होती हैं, और उनका इलाज

सच कहूँ तो मैंने सारी ग़लतियाँ एक-एक करके कीं।

कारण लिखे बिना सिर्फ़ setting बदल देना। setting फ़ाइल भर update करके “ऐसा क्यों किया” न लिखें, तो अगले दिन का आप वही उलझन फिर दोहराते हैं। इलाज सीधा है — log के “nextTime” में बस एक पंक्ति कारण लिख दें। जैसे “pricing सीधे भरोसे से जुड़ी है, इसलिए ask ही रहे।”

जोश में deploy को allow कर देना। build pass होने के जोश में आप वहीं publish तक allow कर बैठते हैं। पर publish से पहले की जाँच अलग चीज़ है। production URL का heading, टूटा हुआ layout, और मोबाइल पर दिखना तक देखने वाले item को “askUntil” में पक्का करें, और मशीन-check pass होने तक publish न करें।

हल्के और भारी काम को एक जैसा बरतना। मुख्य पाठ की वर्तनी ठीक करना, और आवेदन लिंक या दाम बदलना — दोनों को एक ही “allow” से चलाएँ तो कभी-न-कभी शुरुआत वाला हादसा होगा। gumroad के लिंक, pricing, या फ़ॉर्म को छूने वाला काम वर्तनी सुधार से अलग खाने में रखें। यह रेखा CLAUDE.md लिखने का तरीक़ा में नियम के रूप में लिख देने से हर बार सोचना नहीं पड़ता।

अक्सर पूछे जाने वाले सवाल

Q. approval log और security setting में क्या फ़र्क़ है? A. security setting “क्या allow करना है” को पक्का करती है, जबकि approval log “आज वह निर्णय क्यों लिया” को बचाकर रखता है। setting नियम है, log डायरी के क़रीब। दोनों हों तो अगले दिन का आप या टीम वही निर्णय दोबारा दोहरा सकती है।

Q. रोज़ लिखना झंझट लगता है। टिके रहने की तरकीब? A. पूर्णता का पीछा मत कीजिए। शुरू में “edit” और “deploy” — बस दो कॉलम भी काफ़ी असर करते हैं। 2–3 मिनट में लिखने लायक रूप बनाकर, काम शुरू करने से पहले पहले input के रूप में पेस्ट करने की आदत बना लें तो यह चलता रहता है।

Q. AI का सुझाया बँटवारा भरोसे लायक है? A. draft के तौर पर सुविधाजनक है, पर आख़िरी निर्णय इंसान करता है। ख़ासकर pricing, production और delete वाली पंक्तियाँ — AI चाहे “allow ठीक है” कहे, उन्हें ख़ुद ask में गिराइए। मक़सद निर्णय की मेहनत घटाना है, निर्णय को ही पूरा सौंप देने का औज़ार नहीं।

Q. टीम में इस्तेमाल करते समय क्या ध्यान रखें? A. log एक ही जगह इकट्ठा करें, और “allow” में डाले जाने वाले काम का ऐसा कारण लिखें कि कोई भी देखे तो वही निर्णय निकले। बिना कारण वाला allow अलग-अलग लोगों के लिए अलग मतलब रखता है और हादसे की जड़ बनता है। approval को धीरे-धीरे चौड़ा करने की सोच के लिए सुरक्षित तरीक़े से autonomy बढ़ाना भी काम का है।

Q. छोटे ब्लॉग के लिए भी इतना ज़रूरी है? A. आकार जितना छोटा होगा, pricing या लिंक का हादसा उतना सीधा कमाई पर असर डालता है। बल्कि व्यक्ति या छोटी टीम के लिए ही “पैसा और production सिर्फ़ ask” — इस एक नियम से शुरू करने की क़ीमत है।

संदर्भ लिंक

असल में आज़माने के बाद का नतीजा

इस approval log को क़रीब दो हफ़्ते चलाने के बाद, सबसे ज़्यादा असर अजीब तरह से “हल्के काम” पर पड़ा। article की वर्तनी ठीक करना निश्चिंत होकर allow में रखा जा सकता है, पर pricing, लिंक, आवेदन फ़ॉर्म और publish settings को ask में रखा। बस इस फ़र्क़ को पहले लिख देने से, AI का जवाब पढ़ने के बाद हर बार “यह काम allow करना ठीक था क्या?” दोबारा सोचने की मेहनत मिट गई।

उलझन सबसे ज़्यादा “run” और “deploy” में होती थी। build allow करना ठीक है, पर production URL जाँचे बिना publish करना अभी जल्दबाज़ी है। एक बार heading, टूटा layout और मोबाइल दिखावट तक आँखों से जाँच लेने के बाद, उसी किस्म के publish को अगली बार से allow में चढ़ा सका। इस तरह स्तर record में दर्ज होते जाते हैं, इसलिए approval log किसी भारी security दस्तावेज़ से ज़्यादा रोज़ के निर्णय हल्के करने वाली एक note की तरह इस्तेमाल करना ही सबसे व्यावहारिक है — फ़िलहाल यही मेरा अनुभव है।

permission की रेखा अपनी टीम के हिसाब से ढालनी हो, या production publish के नियम साथ मिलकर पक्के करने हों, तो ट्रेनिंग / सलाह में इन्हें ठोस operation में उतारा जा सकता है।