Claude Code permission safety ladder: access धीरे-धीरे बढ़ाएं

beginner के लिए मुश्किल फैसला prompt नहीं है। असली सवाल है कि Claude Code कौन सा action बिना पूछे चला सकता है। सब ask होगा तो workflow धीमा होगा। सब allow होगा तो risk बढ़ेगा। permission safety ladder access को controlled steps में बढ़ाती है।

permissions guide पढ़ने वाला reader settings में डालने लायक क्रम चाहता है। यह article पहले सप्ताह में safe permissions और हमेशा deny या human approval में रहने वाली operations को अलग करता है।

संबंधित लेख: claude-code-permissions-guide, claude-code-security-best-practices, claude-code-harness-lite-workflow.

पहले edit से पहले यह ढांचा क्यों जरूरी है

Claude Code तब सबसे अच्छा काम करता है जब task की boundary साफ हो। अच्छी boundary बताती है कि कौन से files पढ़ने हैं, कौन से edit हो सकते हैं, कौन से operations नहीं चलाने हैं, और work खत्म होने का proof क्या है। boundary न हो तो beginner prompt भी बड़ा rewrite बन सकता है और content change free PDF, Gumroad या consultation path तोड़ सकता है।

यह pattern revenue work में भी मदद करता है क्योंकि technical proof और reader proof को साथ रखता है। local build pass होने पर भी अगर page reader को गलत product पर भेज रहा है, तो काम पूरा नहीं है। scope, command, public URL और CTA record करने से अगली बार memory पर नहीं, evidence पर improvement होता है।

काम में इस्तेमाल होने वाला workflow

1. Level 0 में केवल Read, Glob और Grep allow करें
2. Level 1 में git status, git diff और build जैसे proof commands जोड़ें
3. Level 2 में content और tests जैसे limited paths के Write/Edit को ask रखें
4. Level 3 में deploy checks केवल explicit confirmation से चलें
5. secrets, force push, destructive deletes और billing changes deny या human-approved रहें

स्थिति	सुरक्षित कदम	प्रमाण
Personal content site	MDX और image edit ask में रहें, build allow हो सकता है, deploy confirmation से हो और CTA check proof बने।	build, diff, URL
SaaS dashboard	UI components और tests limited edit हो सकते हैं, auth, billing और migrations approval-only रहें।	screenshot, test
Team workflow	permission level CLAUDE.md में लिखें ताकि reviewer जान सके agent को कितनी autonomy थी।	log, command, handoff

पहला pass छोटा रखें। audit का output बड़ा report नहीं, decision होना चाहिए। अगर 20 मिनट बाद भी decision unclear है, तो safe next step edit शुरू करना नहीं, बल्कि एक और file पढ़ना है।

कॉपी करने लायक prompt और code

इस repository के लिए चार level की Claude Code permission ladder design करें। read-only, proof commands, limited edits और deploy checks अलग करें। deny में रहने वाले actions भी लिखें।

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Bash(npm.cmd run build)",
      "Bash(git status --short)",
      "Bash(git diff --stat)"
    ],
    "ask": [
      "Write(site/src/content/**)",
      "Edit(site/src/content/**)",
      "Bash(npm install *)",
      "Bash(npx wrangler pages deploy *)"
    ],
    "deny": [
      "Bash(git push --force*)",
      "Bash(rm -rf*)",
      "Read(.env*)"
    ]
  }
}

code जानबूझकर छोटा है। यह operating idea को checkable object में बदलता है: scope है, protected areas हैं और proof command जुड़ा है। आप इसे article publishing, app development, debugging या team handoff के लिए बदल सकते हैं।

तीन असली उदाहरण

Personal content site

MDX और image edit ask में रहें, build allow हो सकता है, deploy confirmation से हो और CTA check proof बने।

सबसे जरूरी हिस्सा proof है। एक command, एक visible page या एक note रखें जो दिखाए कि work सच में reader तक पहुंचा।

SaaS dashboard

UI components और tests limited edit हो सकते हैं, auth, billing और migrations approval-only रहें।

सबसे जरूरी हिस्सा proof है। एक command, एक visible page या एक note रखें जो दिखाए कि work सच में reader तक पहुंचा।

Team workflow

permission level CLAUDE.md में लिखें ताकि reviewer जान सके agent को कितनी autonomy थी।

सबसे जरूरी हिस्सा proof है। एक command, एक visible page या एक note रखें जो दिखाए कि work सच में reader तक पहुंचा।

जिन गलतियों से बचना है

• deploy या push जल्दी allow करने से proof से पहले publication हो सकती है।
• हर action ask में रखने से workflow sustain नहीं होता।
• deny rules के बिना dangerous operations unclear रह जाते हैं।

दूसरी subtle failure localization drift है। English article सही product path समझा सकता है, लेकिन दूसरे locale में पुराना CTA रह सकता है। इसलिए public check में हर भाषा का h1, opening body और CTA language देखना चाहिए, केवल frontmatter lang नहीं।

reader को free PDF, Gumroad और consultation तक कैसे ले जाएं

अगर reader को अभी commands की आदत चाहिए, तो free cheatsheet से शुरू कराएं। setup, permissions, CLAUDE.md, hooks, MCP या CI/CD में रुकावट हो तो Setup Guide सही paid next step है। review, debugging और refactor prompts बार-बार लिखने पड़ते हों तो 50 Prompt Templates भेजें। team rollout, workflow design या revenue path चाहिए तो consultation पर भेजें। सारे विकल्प देखने के लिए products खोलें।

हर reader को तुरंत paid product पर न भेजें। beginners को पहले low-friction PDF चाहिए। जो prompts दोहराते हैं वे templates के करीब हैं। permissions, CLAUDE.md, hooks, MCP या CI/CD में अटके readers Setup Guide के करीब हैं। team और process सवाल consultation के करीब हैं।

publish से पहले और बाद में क्या जांचना है

इस लेख की verification केवल HTTP 200 नहीं है। h1, शुरुआत का body text, heroImage, internal links, Gumroad links और consultation path एक ही reader intent से जुड़े होने चाहिए।

multilingual publishing में Japanese, English, Chinese, Korean, Spanish, French, German, Portuguese, Hindi और Indonesian अलग-अलग verify करें। slug match हो सकता है पर body stale हो सकती है। mobile screenshot opening paragraph और CTA साथ दिखाता है, इसलिए गलती जल्दी मिलती है।

अगले नंबर जिन्हें देखना चाहिए

अगले metrics हैं PDF starts, Gumroad clicks, products visits, training visits, search source, country mix और article-to-CTA click rate। PV बढ़े लेकिन Gumroad click न बढ़े तो product match मजबूत करें। technical article से consultation visits बढ़ें तो reader को शायद workflow design चाहिए।