Claude Code में खतरनाक prompts से बचें: auto push और skipped tests रोकें

Claude Code से कहना, “सब ठीक कर दो, खुद push कर दो, tests बाद में देखेंगे” तेज लग सकता है। लेकिन ऐसा tool जो files edit कर सकता है, shell commands चला सकता है, git इस्तेमाल कर सकता है और documentation देख सकता है, उसमें यह एक वाक्य review control कमजोर कर सकता है।

यह guide डराने के लिए नहीं है। इसका लक्ष्य prevention है। मैंने 3 जून 2026 को official Claude Code docs देखे, खासकर permission modes, /permissions, settings.json और common workflows, फिर risky patterns को ऐसे safe prompts में बदला जिन्हें real work में copy-paste किया जा सके।

flowchart LR
  A["Request लिखें"] --> B["Investigation allow करें"]
  B --> C["Plan review करें"]
  C --> D["छोटा edit करें"]
  D --> E["Tests और diff चलाएं"]
  E --> F["push/deploy मानव तय करे"]

Prompt कब खतरनाक बनता है

यहां खतरनाक का मतलब malicious नहीं है। मतलब है कि scope, authority या completion criteria अस्पष्ट हैं, जबकि Claude Code powerful actions कर सकता है। Beginners के लिए: permission boundary वह रेखा है जहां agent को files edit करने, commands चलाने या project के बाहर जाने से पहले इंसान से पूछना चाहिए।

Claude Code project files पढ़ और search कर सकता है, code edit कर सकता है, tests चला सकता है और git इस्तेमाल कर सकता है। Official docs बताते हैं कि local session में Claude Code user को उपलब्ध files और terminal capabilities के साथ काम कर सकता है। इसलिए अच्छा prompt सिर्फ यह नहीं बताता कि क्या allowed है, बल्कि यह भी बताता है कि क्या forbidden है।

Risky wording	Safe replacement
सब ठीक कर दो	Target files और exclusions लिखें, फिर पहले plan मांगें
Done हो तो push कर दो	diff और tests summarize करो; push मैं तय करूंगा
Tests छोड़ दो	सबसे छोटी useful check propose करो और न चल सके तो कारण लिखो
Production DB में check करो	सिर्फ dev/staging use करो; production SQL generate करो, run नहीं
सारी approvals skip करो	Plan mode में investigate करो, फिर approved steps ही चलाओ
पुरानी चीजें delete करो	पहले deletion candidates list करो; approval के बाद ही delete करो
सब latest पर update करो	security fixes, minor updates और major updates अलग करो
Research करके implement करो	official sources cite करो और findings को edit proposals से अलग करो

Current docs से permission boundaries

Claude Code का permission mode सिर्फ chat में “safe रहना” लिखने से नहीं बदलता। CLI में Shift+Tab या --permission-mode इस्तेमाल होता है; IDE और Desktop में mode selector; persistent defaults settings.json में रहते हैं।

3 जून 2026 तक official docs के मुख्य modes ये हैं: default, जो read-only से अलग actions पर पूछता है; acceptEdits, जो file edits और common filesystem operations auto-accept करता है; plan, जो read, explore और plan बनाने के लिए अच्छा है; auto, background safety checks वाली research preview है; dontAsk, जो pre-approved न होने वाले tools deny करता है; और bypassPermissions, जिसे isolated containers या VMs तक सीमित रखना चाहिए।

/permissions command Allow, Ask और Deny rules दिखाती है। Deny जीतता है, इसलिए teams को force push, .env reads और production deploy commands deny करने चाहिए, सिर्फ याददाश्त पर निर्भर नहीं रहना चाहिए। Shared rules .claude/settings.json में रखें; personal experiments .claude/settings.local.json में।

Minimal settings.json

इसे starting point की तरह use करें और अपने project के command names बदलें।

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Bash(git status)",
      "Bash(git diff *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm publish *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(git push --force *)",
      "Bash(* --no-verify *)"
    ]
  }
}

मुख्य बात restraint है। Bash(*) जैसी broad rule approval layer को बहुत पतला कर देती है। npm run test और git diff जैसी repeatable checks pre-approve करने से session तेज रहता है, लेकिन risky operations hidden नहीं होते।

Use case 1: bugfix

Risky request है: “Login वाली सारी चीजें ठीक करो और चले तो push कर दो।” Scope बहुत बड़ा है और remote action edit के साथ बंधा हुआ है।

Goal: Login के तुरंत बाद session expire होने वाला bug fix करना।
Scope: सिर्फ src/auth/**, src/session/** और tests/auth/**।
Forbidden: git push, deploy, production DB access, और .env पढ़ना।
Process:
1. Relevant files पढ़ो और ज्यादा से ज्यादा 3 likely causes बताओ।
2. Change plan propose करो और मेरी approval का इंतजार करो।
3. Approval के बाद smallest useful edit करो।
4. npm run test -- auth चलाओ और failures summarize करो।
5. अंत में git diff summary और remaining risks बताओ।

इससे Claude Code investigate, edit और verify कर सकता है, लेकिन review points बने रहते हैं। छोटा bugfix unrelated rewrite में बदलने की संभावना भी घटती है।

Use case 2: refactor

Risky request है: “पुरानी implementation clean करो और unnecessary files delete कर दो।” पुराना, clean और unnecessary जैसे शब्द unstable हैं।

Goal: billing module की duplicated validation consolidate करना।
Allowed changes: src/billing/validators.ts और उसके tests।
Do not change: migrations/**, prisma/**, public/**, package-lock.json।
Deletion rule: सिर्फ deletion candidates list करो। Approval के बिना delete मत करो।
Verification: npm run test -- billing और npm run lint चलाओ।
Output: reason, compatibility impact और missing tests छोटा report करो।

Refactor में exclusion list अक्सर target list से ज्यादा जरूरी होती है। Migrations, lockfiles और generated files दिखने में unnecessary लग सकते हैं, लेकिन project के लिए जरूरी हो सकते हैं।

Use case 3: deploy से पहले review

Risky request है: “CI slow है, skip करो और production में ship कर दो।” --no-verify सिर्फ lint नहीं, hooks और secret scanning भी skip कर सकता है।

Goal: Short release readiness check करना।
Allowed commands: git status, git diff, npm run test -- --runInBand, npm run build।
Forbidden commands: git push, deploy, --no-verify, npm publish।
Decision rule:
- Tests या build fail हों तो stop करो।
- Failure log की सिर्फ last 80 lines summarize करो।
- Status Ready / Needs fix / Hold decision में report करो।

Deploy customers, billing, search indexes, caches और support workflows को छूता है। Claude Code से evidence तैयार कराएं; final release action इंसान की explicit decision रहनी चाहिए।

Use case 4: research और documentation

Risky request है: “Latest info खोजो और article में जैसा ठीक लगे update कर दो।” External facts बदलते हैं, इसलिए sources और edit scope अलग रखने चाहिए।

Goal: Claude Code permission modes पर text update करना।
Sources: Official docs को प्राथमिकता दो और URLs अंत में list करो।
Forbidden: Official docs से confirm न होने वाली features assert मत करो।
Process:
1. Current article text और official docs का comparison table बनाओ।
2. सिर्फ edit proposals दो; article edit करने से पहले wait करो।
3. Edit के बाद stale links और description length check करो।

Research tasks में Claude Code को पहले source checker और diff organizer की तरह use करें, writer की तरह बाद में।

Concrete failure cases

पहला, unlimited retries। “Success होने तक retry करो” outage को extra cost और rate limit pressure में बदल सकता है। Maximum attempts, delay और stop condition जरूर लिखें।

दूसरा, secrets। Real API keys prompts में paste करने से वे conversation history, local logs और subagent handoff में रह सकते हैं। Values environment variables या secret manager में रखें; prompt में सिर्फ variable names लिखें।

तीसरा, dependency upgrades। “सारे packages latest करो” major versions और breaking changes ला सकता है। npm outdated से list बनाएं, security fixes को normal updates से अलग करें, और major updates separately review करें।

चौथा, cleanup और migrations। “DB files clean करो” migration history delete करने जैसा समझा जा सकता है। पहले list मांगें, और production data को touch करने वाले काम को generated SQL पर रोकें।

Review checklist

High-impact prompts के अंत में यह paste करें।

Safety check:
[ ] Target files और excluded files लिखे हैं
[ ] git push / deploy / publish forbidden या approval-only है
[ ] Production DB, production API और billable operations block हैं
[ ] .env, private keys और personal data reads block हैं
[ ] Edit से पहले Plan mode या plan मांगा है
[ ] कम से कम एक test, lint या build check शामिल है
[ ] Failure पर stop करके logs summarize करने को कहा है
[ ] Final diff, commands run और remaining risks मांगे हैं

अगर आप ये rules हर बार फिर से नहीं लिखना चाहते, तो products page में prompt packs और checklists हैं। Team adoption के लिए CLAUDE.md, permission settings, review gates और onboarding exercises को आपके real repository के आधार पर Claude Code training और consulting में design किया जा सकता है।

Related Articles

• Claude Code के 7 real production incidents और recovery steps
• Claude Code security best practices complete guide
• Claude Code permissions complete guide
• Claude Code approval flow और sandbox design

Official Links

• Claude Code: Choose a permission mode
• Claude Code: Configure permissions
• Claude Code settings
• Claude Code common workflows

実際に試した結果: Masa के workflow में सबसे ज्यादा असर तीन बातों से आया: पहले Plan mode, change scope को दो से पांच files तक सीमित रखना, और push/deploy को human decision रखना। Dangerous prompts से बचना Claude Code को slow करना नहीं है; यह handoff को इतना clear बनाना है कि काम तेज चले और review कम तनाव वाला हो।