Claude Code को बिना निगरानी चलाएँ, बिना पछतावे के

फ़्लैग से नहीं, मशीन से शुरू करें

नीचे का हर guardrail आसान हो जाता है, जब एजेंट ऐसी मशीन पर चले जिस पर और कुछ न हो। आपके लैपटॉप पर “allow all” का मतलब है आपका ईमेल, पासवर्ड मैनेजर, प्रोडक्शन credentials और आपकी फ़ोटो। एक रिपॉज़िटरी और एक सीमित टोकन वाली डेडिकेटेड मशीन पर “allow all” का मतलब है बस वह रिपॉज़िटरी और वह टोकन। Anthropic की अपनी सलाह है कि bypass मोड एक अलग-थलग माहौल में ही चलना चाहिए। एजेंट को ऐसे माहौल में रखें। फिर इस पेज का बाकी हिस्सा आसान हो जाता है।

Claude Code के permission modes

Claude Code में चार मोड हैं। हर टास्क के लिए एक मोड चुनें, हमेशा के लिए एक नहीं।

• default. फ़ाइल एडिट और शेल कमांड से पहले पूछता है। इंटरैक्टिव काम के लिए सही। रात भर के काम के लिए गलत।
• acceptEdits. वर्किंग डायरेक्टरी में बिना पूछे फ़ाइलें एडिट करता है। शेल कमांड से पहले अब भी पूछता है। ऐसे refactor के लिए अच्छा बीच का रास्ता, जहाँ टेस्ट फ़ैसला करते हैं।
• plan. पढ़ता है और सोचता है, पर कुछ नहीं बदलता। असली रन से पहले एक प्लान लेने के लिए इसका इस्तेमाल करें, जिसे आप जाँच सकें।
• bypassPermissions. कोई प्रॉम्प्ट नहीं। यही बिना निगरानी वाला मोड है। इसे सिर्फ़ अलग-थलग मशीन पर इस्तेमाल करें, और नीचे दिए deny नियम लगाकर।

शुरू करते समय मोड सेट करें।

claude --permission-mode acceptEdits

या किसी प्रोजेक्ट की settings फ़ाइल में एक मोड को डिफ़ॉल्ट बना दें। इसे commit किया जा सकता है, ताकि पूरी टीम इसे शेयर करे।

// .claude/settings.json
{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

Deny नियम हर मोड में काम करते हैं

ज़्यादातर लोग यही हिस्सा चूक जाते हैं। Permission नियम मोड के ऊपर लगते हैं, और deny नियम bypass मोड में भी कार्रवाई रोक देता है। इसलिए बिना निगरानी वाले रन के लिए deny नियम ही असली सेफ़्टी नेट हैं। Allow नियम उन चीज़ों को पहले से मंज़ूरी देते हैं जिन पर आप हर बार हाँ कहते। इससे एजेंट उन पर अटकता नहीं।

// .claude/settings.json
{
  "permissions": {
    "allow": [
      "Bash(npm test:*)",
      "Bash(npm run lint:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "Bash(git push origin HEAD:*)"
    ],
    "deny": [
      "Bash(git push:*--force*)",
      "Bash(git push origin main:*)",
      "Bash(rm -rf:*)",
      "Bash(curl:*)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(~/.ssh/**)"
    ]
  }
}

Deny लिस्ट को एक पॉलिसी की तरह पढ़ें, क्योंकि वह यही है। कोई force push नहीं। main पर push नहीं। recursive delete नहीं। एजेंट की खुद गढ़ी हुई कोई बाहरी रिक्वेस्ट नहीं। secrets फ़ाइलें पढ़ना नहीं। इसे अपने प्रोजेक्ट के हिसाब से बदलें, पर हर बिना निगरानी वाली मशीन पर deny लिस्ट रखें।

उन नियमों के लिए hooks, जो pattern से नहीं लिखे जा सकते

कुछ नियम संदर्भ पर निर्भर करते हैं। Hook टूल कॉल से पहले एक स्क्रिप्ट चलाता है। वह कॉल को मंज़ूर कर सकता है, रोक सकता है या बदल सकता है। एक आम hook हर उस कमांड को रोकता है जिसमें प्रोडक्शन hostname हो, कमांड चाहे जो भी हो।

// .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "./scripts/block-prod.sh" }
        ]
      }
    ]
  }
}

स्क्रिप्ट standard input से टूल कॉल पढ़ती है। उसे रोकने के लिए वह non-zero कोड के साथ exit करती है। Hooks छोटे और सीधे-सादे रखें। जो hook ऐसे फ़ेल हो सकता है कि किसी को पता न चले, वह hook न होने से भी बुरा है।

Git आपका सबसे अच्छा guardrail है

एजेंट के अंदर की सेटिंग्स एक परत हैं। रिपॉज़िटरी दूसरी परत है, जिसे फ़र्क नहीं पड़ता कि कौन सा एजेंट चल रहा है।

• main को protect करें। merge के लिए pull request और हरा CI रन ज़रूरी करें। फिर कोई गलत push कुछ भी अंदर नहीं ला सकता।
• हर टास्क की एक ब्रांच। एजेंट नई ब्रांच पर शुरू करता है और सिर्फ़ वही ब्रांच push करता है।
• एजेंट को ऐसा टोकन दें जो ब्रांच push कर सके और pull request खोल सके, इससे ज़्यादा कुछ नहीं। कोई admin scope नहीं। कोई delete scope नहीं। एक रिपॉज़िटरी तक सीमित fine-grained GitHub टोकन यही करता है।
• टेस्ट फ़ैसला करते हैं। अगर suite फ़ेल हो, तो pull request लाल रहती है और सुबह आपको दिख जाती है।

Credentials: कम से कम, और अलग

बिना निगरानी वाली मशीन पर कभी अपना निजी credential न रखें। एजेंट के लिए अलग अकाउंट या टोकन बनाएँ, जिसका scope उतना ही हो जितना टास्क के लिए ज़रूरी है। प्रोडक्शन नहीं, staging। जहाँ पढ़ना काफ़ी हो, वहाँ read-only। अगर एजेंट को ब्राउज़र से किसी सर्विस में साइन इन करना है, तो टेस्ट अकाउंट से करें। प्रोजेक्ट खत्म होने पर टोकन बदल दें।

सीमा के साथ headless रन

स्क्रिप्ट वाले टास्क के लिए print मोड एक प्रॉम्प्ट चलाकर बंद हो जाता है। इसे टर्न की सीमा दें, ताकि उलझा हुआ एजेंट पूरी रात लूप में न घूमे।

claude -p "Fix the failing tests in packages/api and open a PR" \
  --permission-mode acceptEdits \
  --max-turns 60

आउटपुट को फ़ाइल में लॉग करें। सुबह आप पढ़ना चाहेंगे कि उसने क्या किया, अंदाज़ा नहीं लगाना चाहेंगे।

Codex के लिए वही नियम

Codex CLI दो सवालों को अलग रखता है। वह मंज़ूरी कब माँगता है, और वह किसे छू सकता है। एक रिपॉज़िटरी के अंदर बिना निगरानी वाले टास्क के लिए सही जोड़ी है: कभी न पूछे, और सिर्फ़ workspace के अंदर लिखे।

codex -a never -s workspace-write exec "Fix the failing tests and commit"

Codex में एक फ़्लैग ऐसा भी है जो मंज़ूरी और sandbox दोनों हटा देता है। इसे ठीक Claude Code के bypass मोड जैसा मानें। या तो अलग-थलग मशीन, या बिल्कुल नहीं।

कभी नहीं वाली लिस्ट

आप कोई भी टूल इस्तेमाल करें, बिना निगरानी वाला एजेंट इनमें से कुछ भी न कर पाए। अगर आपका सेटअप इनमें से किसी एक की भी अनुमति देता है, तो पहली रात वाले रन से पहले उसे ठीक करें।

• protected ब्रांच पर push करना, या कहीं भी force push करना।
• ऐसा secret पढ़ना या भेजना, जो टास्क के लिए ज़रूरी नहीं था।
• प्रोडक्शन डेटा छूना, पढ़ने के लिए भी।
• पैसा खर्च करना। कोई क्लाउड कंसोल नहीं, कोई पेमेंट पेज नहीं, कोई ऐड अकाउंट नहीं।
• लोगों को मैसेज भेजना। न ईमेल, न चैट, न सोशल।
• वर्किंग ट्री के बाहर कुछ भी डिलीट करना।