settings.json: 用户级 / 项目级配置

📚 सीरीज नेविगेशन: पिछला लेख 30 功能怎么选：CLAUDE.md vs Skill vs Hook vs MCP vs Subagent आपको सिखाता है कि "आवश्यकता आने पर किस एक्सटेंशन पॉइंट को प्लग करना है"। यह लेख एक स्तर और नीचे जाता है—इन एक्सटेंशन पॉइंट्स के पीछे के स्विच, आखिरकार किस फ़ाइल में लिखे जाते हैं, और उपयोगकर्ता-स्तर और प्रोजेक्ट-स्तर में से कौन सा पहले लागू होता है। settings.json Claude Code का मुख्य नियंत्रण बोर्ड (control board) है, आज हम इसके तारों के कनेक्शन के नियमों को एक बार में स्पष्ट करेंगे।

यहाँ एक बहुत ही आसान बेवकूफी भरी गलती है जिसे आप कर सकते हैं, जिसे एक बार करने के बाद आप कभी नहीं भूलेंगे।

जब मैंने गंभीरता से Claude Code का उपयोग करना शुरू किया, तो एक सामान्य ऑपरेशन किसी प्रोजेक्ट के .claude/settings.json में defaultMode: "auto" जोड़ना था, ताकि प्रोजेक्ट में प्रवेश करते ही यह स्वचालित रूप से बिना पूछे कमांड्स चलने दे। इसे बदलने के बाद कुछ नहीं हुआ। मेरी पहली प्रतिक्रिया यह थी कि मैंने फ़ील्ड का नाम गलत लिखा है, इसलिए मैंने आधिकारिक दस्तावेज़ों के खिलाफ शब्द-दर-शब्द तीन बार जांच की, एक भी अक्षर गलत नहीं था। फिर मुझे संदेह हुआ कि JSON प्रारूप (format) दूषित हो सकता है, इसलिए मैंने इसे एक ऑनलाइन सत्यापनकर्ता (validator) के माध्यम से चलाया, यह पूरी तरह से वैध था। लगभग बीस मिनट तक परेशान रहने के बाद, मुझे यहाँ तक संदेह होने लगा कि क्या Claude Code के इस संस्करण में कोई बग (bug) है।

बाद में मुझे दस्तावेज़ के एक कोने में वह वाक्य मिला: जब defaultMode को "auto" पर सेट किया जाता है, तो प्रोजेक्ट सेटिंग्स में इसे सीधे अनदेखा कर दिया जाता है—यह आधिकारिक तौर पर जानबूझकर ब्लॉक किया गया है ताकि किसी रिपोजिटरी को गुप्त रूप से अपने लिए स्वचालित मोड सक्षम करने से रोका जा सके (लेख 20 में भी इसका उल्लेख किया गया है)। उस कॉन्फ़िगरेशन की सिंटैक्स पूरी तरह सही थी, फ़ाइल क्षतिग्रस्त नहीं थी, यह विशुद्ध रूप से गलत "मंजिल" पर लिखा गया था। इसे उपयोगकर्ता-स्तर के ~/.claude/settings.json में ले जाने पर, यह तुरंत प्रभावी हो गया।

यह उदाहरण देने का कारण आपको यह याद दिलाना है: settings.json की 90% समस्याएँ इस बात में नहीं होतीं कि "इसे कैसे लिखा जाए", बल्कि "इसे किस स्तर पर लिखा जाए, और कौन सा स्तर दूसरे को ओवरराइड करता है" में होती हैं। आज हम इस "मंजिल नियम" को पूरी तरह से स्पष्ट करेंगे, ताकि अगली बार जब आप कॉन्फ़िगर करें, तो आपको पता हो कि किसी नियम को मुख्य निर्देशिका में रखना है या प्रोजेक्ट।

इस लेख को पढ़ने के बाद, आपको मिलेगा:

एक वाक्य में स्पष्टीकरण कि settings.json क्या है और CLAUDE.md के साथ इसका क्या विभाजन है
तीन स्तरों (उपयोगकर्ता-स्तर / प्रोजेक्ट-स्तर / स्थानीय-स्तर) में से प्रत्येक के लिए फ़ाइल पथ, प्रभाव का दायरा और क्या रखा जाना चाहिए
एक "कौन किसे ओवरराइड करता है" प्राथमिकता तालिका, साथ ही एक सबसे विपरीत-सहज अपवाद (सरणी (arrays) मर्ज होती हैं, ओवरराइड नहीं)
कुछ कॉन्फ़िगरेशन आइटम जिन्हें आप सबसे अधिक बदलते हैं (model, permissions, env, hooks, statusLine), वे क्या करते हैं और किस स्तर पर जाते हैं
एक व्यावहारिक अभ्यास जिसे आप फ़ॉलो कर सकते हैं और अपेक्षित आउटपुट देख सकते हैं: एक कॉन्फ़िगरेशन लिखना → इसे सत्यापित करने के लिए /status का उपयोग करना

01 पहले समझें: settings.json क्या है और CLAUDE.md के साथ इसका क्या विभाजन है

पहले निष्कर्ष: settings.json Claude Code के "व्यवहार स्विचों का संग्रह" है—यह JSON प्रारूप में अनुमतियों, पर्यावरण चर, डिफ़ॉल्ट मॉडल, Hook और स्थिति पट्टी जैसे टूल व्यवहारों को प्रबंधित करता है; यह और CLAUDE.md दो अलग-अलग प्रणालियाँ हैं, एक "काम कैसे करना है" का प्रबंधन करती है और दूसरी "क्या याद रखना है" का।

बहुत से लोग शुरू में इन दोनों को भ्रमित कर देते हैं। आपने लेख 18 में CLAUDE.md लिखा है, लेख 20 में अनुमति नियमों को कॉन्फ़िगर किया है, और आगे Hook को कॉन्फ़िगर करेंगे—ये सभी चीज़ें अंततः settings.json फ़ाइल में समाप्त होती हैं, लेकिन यह CLAUDE.md से पूरी तरह से अलग सामग्री संग्रहीत करता है।

एनालॉजी: कंपनी का प्रोजेक्ट फ़ाइल कैबिनेट बनाम आपके वर्कस्टेशन पर पावर स्विच बॉक्स। CLAUDE.md फ़ाइल कैबिनेट में "प्रोजेक्ट निर्देश मैनुअल" की तरह है—यह प्राकृतिक भाषा में लिखे गए समझौते हैं जो लोगों (यानी Claude) के देखने के लिए हैं, जैसे कि "हम pnpm का उपयोग करते हैं, npm का नहीं", "सबमिट करने से पहले टेस्ट चलाएं"। यह प्रत्येक सत्र में पृष्ठभूमि के रूप में पढ़ा जाता है। settings.json अलग है, यह आपके वर्कस्टेशन की दीवार पर पावर स्विच बॉक्स की तरह है—इसके अंदर विशिष्ट स्विच हैं: यह टूल अनुमत है या नहीं, डिफ़ॉल्ट रूप से कौन सा मॉडल चलाना है, फ़ाइल को संशोधित करने के बाद स्वचालित रूप से कौन सी स्क्रिप्ट ट्रिगर करनी है। फ़ाइल कैबिनेट "इसे सिखाए जाने वाले नियम" हैं, और पावर स्विच बॉक्स "इसके लिए निश्चित मशीन व्यवहार" है।

आधिकारिक तौर पर इसकी स्थिति बहुत स्पष्ट रूप से बताई गई है:

settings.json फ़ाइल स्तरित सेटिंग्स के माध्यम से Claude Code को कॉन्फ़िगर करने का आधिकारिक तंत्र है।

"आधिकारिक तंत्र" और "स्तरित" (hierarchical) इन दो शब्दों पर ध्यान दें, जो ठीक इस लेख की दो मुख्य विषयवस्तु हैं: यह Claude Code को कॉन्फ़िगर करने का आधिकारिक प्रवेश द्वार है (कमांड लाइन पर अस्थायी रूप से पैरामीटर टाइप करने के बजाय), और यह कई स्तरों में विभाजित है (उपयोगकर्ता, प्रोजेक्ट, स्थानीय)。

वास्तविक परिदृश्यों में, settings.json इन्हीं प्रकार के कार्यों का प्रबंधन करता है:

"इस प्रोजेक्ट में, rm -rf जैसे कमांड को पूरी तरह से ब्लॉक करें" — permissions.deny में लिखें
"यह प्रोजेक्ट डिफ़ॉल्ट रूप से Sonnet का उपयोग कर सकता है, हमेशा Opus का उपयोग करके कोटा बर्बाद न करें" — model में लिखें
"हर बार फ़ाइल को संशोधित करने के बाद स्वचालित रूप से स्वरूपण (formatting) चलाएं" — hooks में लिखें
"मैं चाहता हूँ कि टर्मिनल के नीचे की स्थिति पट्टी (status line) वर्तमान git शाखा प्रदर्शित करे" — statusLine में लिखें

这些都不是「讲给 Claude 听」的话，而是实打实改变它运行行为的开关。这就是 settings.json 跟 CLAUDE.md 的根本分工。

💡 一句话总结：CLAUDE.md 是「讲给 Claude 听的自然语言规矩」，settings.json 是「替它定死机器行为的开关总成」——前者管记住什么，后者管怎么干活，两套东西别混着用。

02 三个层级：主目录、项目里、还是只在你这台机器

settings.json 最该先搞懂的，不是有哪些字段，而是它有三个层级，同一个文件名摆在三个不同位置，作用范围天差地别。开头那个坑，根子就在没分清层级。

एनालॉजी: नोटिस पोस्ट करने के तीन स्थान। "काम के बाद एयर कंडीशनर बंद करना याद रखें" का एक ही नोटिस कंपनी के मुख्य द्वार पर पोस्ट किया जा सकता है (कंपनी में हर कोई इसे देखता है), इस विशिष्ट कार्यालय के दरवाजे पर पोस्ट किया जा सकता है (केवल इस प्रोजेक्ट के लोग इसे देखते हैं और इसे कार्यालय के नियमों में दर्ज किया जाता है), या आपके अपने मॉनिटर के बगल में एक स्टिकी नोट के रूप में (केवल आप इसे देखते हैं और अन्य लोग इसे नहीं जानते)—प्रभाव का दायरा पूरी तरह से अलग है। settings.json के तीन स्तर इन तीन प्रकार के पोस्टिंग तरीकों के समान हैं।

आधिकारिक तौर पर परिभाषित तीन स्तरों को इस तालिका में देखें (सर्वोच्च Managed स्तर को छोड़कर, जो उद्यम आईटी के लिए है और शुरुआती लोग आमतौर पर इसका सामना नहीं करते हैं, जिसे अगले अनुभाग में संक्षेप में बताया जाएगा):

स्तर	फ़ाइल पथ	किसे प्रभावित करता है	क्या यह git में जाता है	क्या रखा जाना चाहिए
उपयोगकर्ता-स्तर (User)	`~/.claude/settings.json`	आपको, आपके सभी प्रोजेक्ट्स में	नहीं (आपकी मुख्य निर्देशिका में)	व्यक्तिगत प्राथमिकताएं: आपका पसंदीदा मॉडल, थीम, वे टूल जो आप सभी प्रोजेक्ट्स में चाहते हैं
प्रोजेक्ट-स्तर (Project)	`.claude/settings.json`	इस रिपोजिटरी के सभी सहकर्मियों को	हाँ (git में सबमिट और साझा किया जाता है)	टीम समझौते: अनुमति नियम, Hook, साझा MCP
स्थानीय-स्तर (Local)	`.claude/settings.local.json`	आपको, केवल इस रिपोजिटरी में	नहीं (स्वचालित रूप से gitignored)	व्यक्तिगत ओवरराइड, क्रेडेंशियल्स के साथ प्रयोगात्मक कॉन्फ़िगरेशन

तीन स्तरों के बीच चयन करने के लिए इन तीन वाक्यों को याद रखना ही पर्याप्त है:

"मुझे यह मेरे सभी प्रोजेक्ट्स में चाहिए" → उपयोगकर्ता-स्तर (~/.claude/settings.json)। उदाहरण के लिए, "मुझे डिफ़ॉल्ट रूप से Sonnet का उपयोग करने की आदत है", "मेरी स्थिति पट्टी स्क्रिप्ट", इसे एक बार कॉन्फ़िगर करें और यह किसी भी प्रोजेक्ट में उपलब्ध होगी।
"पूरी टीम के पास यह होना चाहिए और यह रिपोजिटरी के साथ चलना चाहिए" → प्रोजेक्ट-स्तर (.claude/settings.json)। इसे git में सबमिट किया जाता है, ताकि टीम के सदस्यों के रिपोजिटरी खींचने पर उनके पास एक ही कॉन्फ़िगरेशन हो। यह "कोड के रूप में कॉन्फ़िगरेशन" है।
"केवल मेरे लिए, इस प्रोजेक्ट के लिए विशिष्ट, रिपोजिटरी में शामिल नहीं करना चाहते" → स्थानीय-स्तर (.claude/settings.local.json)。

这里有个特别贴心的细节，官方明说了：当你创建 .claude/settings.local.json 时，Claude Code 会自动帮你把它加进 git 忽略。

Claude Code 将在创建 .claude/settings.local.json 时配置 git 以忽略它。

इसे इस तरह क्यों डिज़ाइन किया गया है? इसके बारे में सोचें: स्थानीय-स्तर "व्यक्तिगत सामान" रखने के लिए है—आपके व्यक्तिगत प्रयोगात्मक कॉन्फ़िगरेशन, कुछ क्रेडेंशियल्स वाली चीजें, इन्हें कभी भी टीम के सदस्यों के वातावरण को दूषित करने के लिए रिपोजिटरी में सबमिट नहीं किया जाना चाहिए। अधिकारियों ने इस रक्षा पंक्ति को आपके लिए सुरक्षित कर दिया है, ताकि आप कभी गलती से git add . करके अपनी व्यक्तिगत सेटिंग्स सबमिट न कर दें। यह लेख 21 में चर्चा की गई मुख्य सुरक्षा पंक्ति के साथ भी प्रतिध्वनित होता है: संवेदनशील चीजें, शुरू से ही git में प्रवेश करने का अवसर नहीं मिलनी चाहिए。

व्यावहारिक रूप में इसे कैसे विभाजित करें: एक वास्तविक प्रोजेक्ट का त्रि-स्तरीय वितरण

केवल परिभाषाओं को याद रखना पर्याप्त नहीं है, आइए देखें कि एक वास्तविक प्रोजेक्ट में इन तीन स्तरों में क्या रखा गया है:

उपयोगकर्ता-स्तर (~/.claude/settings.json): कस्टम स्थिति पट्टी स्क्रिप्ट का वह सेट, डिफ़ॉल्ट मॉडल प्राथमिकताएं। ये किसी विशिष्ट प्रोजेक्ट से संबंधित नहीं हैं, बल्कि व्यक्तिगत आदतें हैं जो "आप जहाँ भी जाएँ, आपके साथ चलती हैं"。
प्रोजेक्ट-स्तर (.claude/settings.json): permissions.deny का एक सेट (curl को ब्लॉक करना, .env पढ़ने पर रोक लगाना), एक hook जो "सबमिट करने से पहले स्वचालित रूप से lint चलाता है"। ये पूरी टीम की सीमाएं और नियंत्रण बिंदु हैं, और इन्हें git में शामिल होना चाहिए ताकि प्रत्येक सहकर्मी के पास प्रोजेक्ट खींचने पर ये सेटिंग्स हों。
स्थानीय-स्तर (.claude/settings.local.json): कुछ कमांड्स जिन्हें व्यक्तिगत रूप से अस्थायी रूप से चलाने की अनुमति दी गई है (टीम को जानने की आवश्यकता नहीं है), एक hook जो अभी परीक्षण के अधीन है और टीम के सदस्यों के साथ साझा करने के लिए पर्याप्त परिपक्व नहीं है。

यह तय करने के लिए कि कोई कॉन्फ़िगरेशन किस स्तर पर जाना चाहिए, बस अपने दिमाग में प्रश्नों की एक श्रृंखला चलाएं: "क्या यह केवल मुझे चाहिए → उपयोगकर्ता-स्तर या स्थानीय-स्तर; क्या पूरी टीम को चाहिए → प्रोजेक्ट-स्तर", और आगे विभाजित करें: "क्या यह सभी प्रोजेक्ट्स पर लागू होता है और मेरे साथ चलता है → उपयोगकर्ता-स्तर; केवल इस प्रोजेक्ट के लिए है और git में शामिल नहीं करना चाहते → स्थानीय-स्तर"。

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

💡 一句话总结：三层一句话区分——跨所有项目放用户级 ~/.claude/settings.json、全队共享放项目级 .claude/settings.json（进 git）、私人覆盖放本地级 .claude/settings.local.json（自动 gitignored）；判断口诀「跟着我走 vs 跟着项目走」。

03 谁压谁：优先级，外加一个最反直觉的例外

एक ही फ़ील्ड को तीनों स्तरों पर लिखा जा सकता है। तो प्रश्न यह उठता है: यदि उपयोगकर्ता-स्तर Opus का उपयोग करने के लिए कहता है, और प्रोजेक्ट-स्तर Sonnet का उपयोग करने के लिए कहता है, तो किसकी बात मानी जाएगी? यह "प्राथमिकता" (precedence) का मामला है, और यह settings.json का सबसे भ्रमित करने वाला हिस्सा भी है。

先给官方的优先级排序，从高到低（高的压低的）：

प्राथमिकता	स्तर	सरल शब्द
1 (सर्वोच्च)	Managed (उद्यम आईटी परिनियोजन)	कंपनी द्वारा लॉक की गई नीतियां, जिन्हें कोई नहीं बदल सकता
2	कमांड लाइन पैरामीटर (`--settings` आदि)	आपके द्वारा स्टार्टअप पर अस्थायी रूप से लिया गया निर्णय, जो केवल वर्तमान सत्र पर लागू होता है
3	स्थानीय-स्तर `.claude/settings.local.json`	इस प्रोजेक्ट में आपका व्यक्तिगत ओवरराइड
4	प्रोजेक्ट-स्तर `.claude/settings.json`	टीम साझा प्रोजेक्ट सेटिंग्स
5 (न्यूनतम)	उपयोगकर्ता-स्तर `~/.claude/settings.json`	आपका वैश्विक डिफ़ॉल्ट, जो केवल तब लागू होता है जब कोई अन्य इसे ओवरराइड नहीं करता

यह "उच्च से निम्न" संबंध एक आरेख के रूप में अधिक सहजता से समझा जा सकता है—उच्च स्तर नीचे के स्तर पर रखी गई एक कागज़ की तरह है, जो नीचे लिखे गए समान फ़ील्ड के हिस्सों को ब्लॉक कर देता है:

Claude Code settings पांच-स्तरीय प्राथमिकता स्टैक: Managed > कमांड लाइन > स्थानीय > प्रोजेक्ट > उपयोगकर्ता

यह आरेख ऊपर से नीचे तक प्राथमिकता दिखाता है: ऊपर का स्तर नीचे के स्तर को ओवरराइड करता है (केवल एकल-मूल्य फ़ील्ड के लिए)। दूसरे शब्दों में, ऊपर का स्तर जितना अधिक "अस्थायी और विशिष्ट" होगा, नीचे का स्तर उतना ही अधिक "वैश्विक और डिफ़ॉल्ट" होगा—केवल तभी जब ऊपर के सभी स्तरों ने किसी विशिष्ट फ़ील्ड को छुआ न हो, नीचे का उपयोगकर्ता-स्तर डिफ़ॉल्ट प्रभावी होगा。

इस क्रम को याद रखने के लिए एक वाक्य: वर्तमान क्षण के लिए जितना अधिक "विशिष्ट" होगा, उसकी प्राथमिकता उतनी ही अधिक होगी; वैश्विक डिफ़ॉल्ट की प्राथमिकता उतनी ही कम होगी。कमांड लाइन पैरामीटर (केवल वर्तमान सत्र के लिए) स्थानीय को ओवरराइड करता है (केवल इस प्रोजेक्ट के लिए, केवल आपके लिए), स्थानीय प्रोजेक्ट को ओवरराइड करता है (पूरी टीम), और प्रोजेक्ट उपयोगकर्ता को ओवरराइड करता (वैश्विक)। आधिकारिक तौर पर दिया गया उदाहरण सबसे स्पष्ट है:

例如，如果您的用户设置允许 Bash(npm run *)，但项目的共享设置拒绝它，则项目设置优先，命令被阻止。

यानी—वह अनुमति जो आपने अपनी मुख्य निर्देशिका में स्वयं को दी है, किसी विशिष्ट प्रोजेक्ट में प्रवेश करने पर प्रोजेक्ट सेटिंग्स द्वारा ब्लॉक की जा सकती है。यह बिल्कुल पिछले लेख के अंत में छोड़ी गई उलझन की पुष्टि करता है: वही कॉन्फ़िगरेशन, आपकी मुख्य निर्देशिका में लिखने और आपके प्रोजेक्ट में लिखने पर, बिल्कुल विपरीत परिणाम दे सकता है。शुरुआत में defaultMode: "auto" की समस्या मूल रूप से स्तरों की समझ की कमी के कारण ही थी。

Managed स्तर को संक्षेप में स्पष्ट किया जा सकता है। 它企业 IT 通过 MDM、注册表或服务器统一下发的策略，优先级最高、用户和项目都覆盖不了，专门给公司强制执行安全合规用的（比如「全公司禁止 curl」）。你自己一个人用、或者小团队协作，基本碰不到它——知道有这么个「天花板层」存在就够了，真在受管控的公司环境里再去翻官方的 server-managed-settings 那页。

那个最反直觉的例外：数组是「合并」，不是「覆盖」

ऊपर चर्चा की गई "ओवरराइड प्राथमिकता" केवल एकल-मूल्य फ़ील्ड (जैसे model, जहाँ एक स्तर एक मान लिखता है और दूसरा स्तर दूसरा मान लिखता है, और उच्च प्राथमिकता वाला जीतता है) पर लागू होती है। लेकिन एक प्रकार का कॉन्फ़िगरेशन है जो इस नियम का बिल्कुल पालन नहीं करता, और शुरुआती लोग अक्सर इसमें गलती करते हैं—सरणी-प्रकार के कॉन्फ़िगरेशन (जैसे permissions.allow / deny) स्तरों के बीच "mर्ज" होते हैं, ओवरराइड नहीं。

啥意思？看官方原话：

数组设置跨作用域合并。 当相同的数组值设置出现在多个作用域中时，数组被连接和去重，而不是替换。

सरल शब्दों में कहें तो: आपके अनुमति नियम प्रोजेक्ट सेटिंग्स द्वारा "पूरी तरह से बदले" नहीं जाएंगे, बल्कि दोनों पक्षों के नियमों को "एक साथ मिलाकर" लागू किया जाएगा。

एक उदाहरण देखें जिससे आप तुरंत समझ जाएंगे:

परिदृश्य	अंतर्ज्ञान (गलत)	वास्तविक स्थिति (सही)
उपयोगकर्ता-स्तर `allow: ["Bash(npm run )"]`, प्रोजेक्ट-स्तर `allow: ["Bash(git diff )"]`	प्रोजेक्ट-स्तर की प्राथमिकता अधिक है, इसलिए केवल `git diff` बचेगा	दोनों नियम प्रभावी हैं: `npm run ` और `git diff ` दोनों की अनुमति है

यह एकल-मूल्य फ़ील्ड की "उच्च स्तर ओवरराइड निम्न स्तर" से पूरी तरह से अलग तर्क है, इसे अलग से याद रखना सुनिश्चित करें:

单值字段（如 model、defaultMode）：高优先级层整个盖掉低层。
数组字段（如 permissions.allow / deny、env 里的多个变量也类似拼装）：各层拼起来去重，谁都不会抹掉谁。

यह बिंदु आसानी से लोगों को भ्रमित कर सकता है: यह सोचना कि प्रोजेक्ट स्तर पर deny का एक सेट लिखने से उपयोगकर्ता स्तर के उदार allow सेट ओवरराइड हो जाएंगे, केवल यह जानने के लिए कि उपयोगकर्ता स्तर के allow नियम अभी भी प्रभावी हैं—क्योंकि वे मर्ज किए जाते हैं, बदले नहीं जाते。केवल इस नियम को समझकर ही आप यह सुनिश्चित कर सकते हैं कि "आप यह न सोचें कि कोई द्वार बंद कर दिया गया है, जबकि वह वास्तव में दूसरे स्तर से खुला हुआ है"。

💡 一句话总结：优先级口诀「越具体到当下的越大」（命令行>本地>项目>用户，Managed 封顶）；但数组类配置（尤其权限规则）是跨层合并去重、不是覆盖——这是最容易踩的反直觉点。

04 सबसे अधिक उपयोग की जाने वाली सेटिंग्स: वे किस स्तर पर जाती हैं और क्या करती हैं

अब जब स्तर और प्राथमिकताएं स्पष्ट हो गई हैं, तो आइए उन फ़ील्ड्स को देखें जिन्हें आप व्यवहार में सबसे अधिक बदलते हैं。settings.json 官方支持的键有上百个，但 90% 的人日常碰的就这么几个。我挑出来，每个讲清「干嘛的、放哪层最合适」。

पहले एक छोटा लेकिन व्यापक उदाहरण देखें, ताकि आपको इसकी संरचना का एक सामान्य विचार मिल सके (यह आधिकारिक उदाहरण का एक संक्षिप्त संस्करण है):

json

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "model": "claude-sonnet-4-6",
  "permissions": {
    "allow": ["Bash(npm run test *)"],
    "deny": ["Bash(curl *)", "Read(./.env)"]
  },
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1"
  }
}

हम दृढ़ता से अनुशंसा करते हैं कि आप पहली पंक्ति में $schema जोड़ें। यह आधिकारिक JSON स्कीमा (schema) को इंगित करता है। इसे जोड़ने के बाद, VS Code या Cursor जैसे संपादकों में कॉन्फ़िगरेशन लिखते समय स्वचालित पूर्णता (auto-complete) और वास्तविक समय सत्यापन (real-time validation) उपलब्ध होगा—यदि फ़ील्ड नाम गलत टाइप किया गया है या मान का प्रकार गलत है, तो संपादक तुरंत इसे लाल रंग से चिह्नित करेगा। शुरुआत में दस्तावेज़ के खिलाफ फ़ील्ड नामों की शब्द-दर-शब्द जांच करने में लगे बीस मिनटों को बचाया जा सकता था यदि पहली पंक्ति में $schema जोड़ा गया होता, क्योंकि संपादक ने पहले ही त्रुटि का संकेत दे दिया होता。官方原话：

将其添加到您的 settings.json 可在 VS Code、Cursor 和任何其他支持 JSON 架构验证的编辑器中启用自动完成和内联验证。

आइए इन उच्च-आवृत्ति फ़ील्ड्स को एक-एक करके समझें:

model：默认用哪个模型

model यह तय करता है कि इस स्तर पर डिफ़ॉल्ट रूप से कौन सा मॉडल चलाना है। मान में मॉडल आईडी दर्ज की जाती है (जैसे "claude-sonnet-4-6")。

किस स्तर पर जाता है: आपकी आवश्यकता पर निर्भर करता है। "मैं व्यक्तिगत रूप से एक विशिष्ट मॉडल का उपयोग करना पसंद करता हूँ" → उपयोगकर्ता-स्तर; "हम चाहते हैं कि हर कोई इस प्रोजेक्ट में कोटा बचाने के लिए Sonnet का उपयोग करे" → प्रोजेक्ट-स्तर。
一个要注意的点：model 跟大多数字段不同，它在会话启动时只读一次，改了要么重启、要么会话里用 /model 现切。--model 启动参数和 ANTHROPIC_MODEL 环境变量都能临时盖过它（模型相关详见第 5 篇）。

इस फ़ील्ड का एक बहुत ही व्यावहारिक उपयोग है: विभिन्न प्रोजेक्ट्स के लिए अलग-अलग डिफ़ॉल्ट मॉडल कॉन्फ़िगर करना。उदाहरण के लिए, एक दस्तावेज़ीकरण परियोजना के लिए जहाँ कार्य जटिल नहीं है, आप इसके प्रोजेक्ट-स्तर के settings.json में मॉडल को एक हल्के मॉडल के रूप में लिख सकते हैं; जबकि एक अन्य मुख्य कोड प्रोजेक्ट में इसे सेट न करके उपयोगकर्ता-स्तर के शक्तिशाली डिफ़ॉल्ट को बनाए रख सकते हैं। इस प्रकार, आप जिस प्रोजेक्ट में प्रवेश करेंगे, उसके अनुसार उपयुक्त मॉडल स्वचालित रूप से उपयोग किया जाएगा, बिना हर बार मैन्युअल रूप से /model बदलने की आवश्यकता के—यह सरल कार्यों के लिए शक्तिशाली मॉडल के कोटे को बर्बाद होने से बचाता है, और जटिल परियोजनाओं में प्रदर्शन से समझौता नहीं करता। यह "प्रोजेक्ट-स्तर उपयोगकर्ता-स्तर को ओवरराइड करता है" नियम का व्यावहारिक मूल्य है: प्रोजेक्ट-स्तर इस प्रोजेक्ट के लिए कस्टम सेटिंग्स प्रदान करता है, और उपयोगकर्ता-स्तर अन्य सभी प्रोजेक्ट्स के लिए डिफ़ॉल्ट के रूप में कार्य करता है。

permissions：准不准用某个工具 / 命令

यह लेख 20 में विस्तार से समझाया गया था—allow (अनुमति), ask (हर बार पूछें), deny (ब्लॉक करें) तीन नियम, टूल और कमांड द्वारा सटीक रूप से अधिकार नियंत्रण。

किस स्तर पर जाता है: सुरक्षा सीमाएं जिनका पूरी टीम को पालन करना चाहिए (जैसे "curl पर प्रतिबंध", ".env फ़ाइल पढ़ने पर रोक") → प्रोजेक्ट-स्तर, इसे git में डालें ताकि पूरी टीम के पास यह हो; यदि आप व्यक्तिगत सुविधा के लिए कुछ अतिरिक्त कमांड्स की अनुमति देना चाहते हैं → स्थानीय-स्तर या उपयोगकर्ता-स्तर。
धारा 03 के नियम को याद रखें: permissions एक सरणी है जो स्तरों के बीच मर्ज होती है—यह न सोचें कि एक स्तर पर deny लिखने से दूसरे स्तर के allow नियम ओवरराइड हो जाएंगे。

env：给会话注入环境变量

env में लिखे गए कुंजी-मान जोड़े पर्यावरण चर के रूप में प्रत्येक सत्र और Claude Code द्वारा चलाए जाने वाले सब-प्रोसेस (sub-processes) पर लागू होंगे。

एनालॉजी: कार्यशाला में प्रवेश करने से पहले जारी किए गए आईडी कार्ड और सुरक्षा उपकरण। 不管今天谁来上工，一进这个车间（会话）就自动配齐这套环境——env 就是这套「入场标配」，你在这儿声明的变量，会话里跑的每条命令、每个子进程都带着它。

विशिष्ट उपयोग: टेलीमेट्री सक्षम करना (CLAUDE_CODE_ENABLE_TELEMETRY), किसी टूलचेन के लिए एक निश्चित चर सेट करना。
किस स्तर पर जाता है: प्रोजेक्ट-विशिष्ट वातावरण (जैसे किसी सेवा का पता जिससे यह प्रोजेक्ट कनेक्ट होना चाहता है) → प्रोजेक्ट-स्तर; जो आप वैश्विक रूप से चाहते हैं → उपयोगकर्ता-स्तर。

hooks：在固定时机自动跑脚本

hooks उस "घटना-ट्रिगर स्वचालित क्रिया" का प्रवेश बिंदु है जिसका उल्लेख पिछले लेख में बार-बार किया गया है और जिसे लेख 33 में विस्तार से समझाया जाएगा—यह settings.json में कॉन्फ़िगर किया जाता है। जैसे कि "हर बार फ़ाइल को संशोधित करने के बाद स्वचालित रूप से स्वरूपण चलाना", "हर बार सत्र शुरू होने पर स्वागत करना"。

किस स्तर पर जाता है: नियंत्रण बिंदु जो पूरी टीम को चलाने चाहिए (जैसे "सबमिट करने से पहले स्वचालित lint") → प्रोजेक्ट-स्तर; आपकी व्यक्तिगत स्वचालन आदतें → उपयोगकर्ता-स्तर。
具体怎么写、能监听哪些事件，这里先知道「它的家在 settings.json」就行，第 33 篇展开。

statusLine：自定义底部状态栏

लेख 14 में इंटरफ़ेस के निचले भाग में स्थित "स्थिति पट्टी" की चर्चा की गई थी। statusLine आपको यह कस्टमाइज़ करने की अनुमति देता है कि यह क्या प्रदर्शित करे—उदाहरण के लिए, वर्तमान git शाखा, वर्तमान मॉडल और token उपयोग को वास्तविक समय में प्रदर्शित करने के लिए एक स्क्रिप्ट जोड़ना。

json

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh"
  }
}

किस स्तर पर जाता है: स्थिति पट्टी एक व्यक्तिगत दृश्य प्राथमिकता है, अधिकांश लोग इसे उपयोगकर्ता-स्तर पर रखते हैं (~/.claude/settings.json), इसे एक बार कॉन्फ़िगर करें और यह सभी प्रोजेक्ट्स में काम करेगी。

मैंने इन सामान्य फ़ील्ड्स के "किस स्तर पर जाने चाहिए" के अनुभव को एक तालिका में संकलित किया है, ताकि उलझन होने पर आप सीधे इसकी जांच कर सकें:

सेटिंग्स आइटम	यह क्या करता है	मेरा डिफ़ॉल्ट स्थान
`model`	डिफ़ॉल्ट मॉडल	व्यक्तिगत प्राथमिकता → उपयोगकर्ता-स्तर; प्रोजेक्ट के लिए → प्रोजेक्ट-स्तर
`permissions`	टूल / कमांड अनुमति	सुरक्षा सीमा → प्रोजेक्ट-स्तर (git में जाता है)
`env`	पर्यावरण चर इंजेक्ट करना	प्रोजेक्ट-विशिष्ट → प्रोजेक्ट-स्तर; वैश्विक → उपयोगकर्ता-स्तर
`hooks`	घटना-ट्रिगर स्वचालित क्रिया	टीम नियंत्रण बिंदु → प्रोजेक्ट-स्तर; व्यक्तिगत आदत → उपयोगकर्ता-स्तर
`statusLine`	कस्टम स्थिति पट्टी	व्यक्तिगत दृश्य प्राथमिकता → उपयोगकर्ता-स्तर

一个容易踩的混淆：不是所有配置都住在 settings.json 里

这点很多人不知道，往往是被报错教育才记住的。Claude Code 还有另一个配置文件 ~/.claude.json（注意，是主目录下的 .claude.json，跟 ~/.claude/settings.json 不是一个东西）。它装的是另一类东西：你的登录会话、用户/本地作用域的 MCP server 配置（第 22 篇提过 MCP 配置存这儿）、每个项目的信任状态、各种缓存。

मुख्य समस्या यह है—कुछ मुट्ठी भर सेटिंग्स हैं जिन्हें आधिकारिक नियमों के अनुसार केवल ~/.claude.json में ही रखा जा सकता है। यदि आप उन्हें settings.json में लिखते हैं, तो यह सीधे स्कीमा सत्यापन त्रुटि को ट्रिगर करेगा。आधिकारिक तौर पर उल्लिखित कुछ उदाहरणों में शामिल हैं: autoConnectIde (बाहरी टर्मिनल स्वचालित रूप से IDE से कनेक्ट होता है), teammateDefaultModel (टीम के साथियों का डिफ़ॉल्ट मॉडल) आदि।

एक विशिष्ट समस्या तब होती है जब आप "बाहरी टर्मिनल को VS Code से स्वचालित रूप से कनेक्ट करना" चाहते हैं और इसे सीधे settings.json में लिख देते हैं। इसके बाद $schema सत्यापन तुरंत त्रुटि प्रदर्शित करता है और /status भी विफल हो जाता है। दस्तावेज़ों को देखने पर पता चलता है कि यह फ़ील्ड वास्तव में ~/.claude.json में होनी चाहिए। इसलिए याद रखें: settings.json "व्यवहार स्विच" को प्रबंधित करता है, और ~/.claude.json "सत्र स्थिति / MCP / कैश" जैसे बैकस्टेज डेटा को प्रबंधित करता है——绝大多数时候你只碰前者，但偶尔有字段「死活写不进 settings.json」时，先想想它是不是该去 ~/.claude.json。

💡 一句话总结：高频字段就这几个——model（默认模型）、permissions（控权）、env（环境变量）、hooks（自动动作）、statusLine（状态栏）；「全队该有」放项目级进 git、「个人偏好」放用户级，加上 $schema 让编辑器替你查错；注意少数字段（如 autoConnectIde）住在 ~/.claude.json 而非 settings.json。

05 在哪编辑、改完啥时候生效、怎么确认它真的读到了

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

在哪编辑：直接改文件，或者用 `/config`

दो तरीके:

直接拿编辑器改那个 JSON 文件——按第 02 节的位置找到对应层级的文件改就行。本项目 CLAUDE.md 也建议「改文件优先用清晰的编辑」，比临时敲命令更可控。
会话里敲 /config——官方提供的交互式设置界面，能看状态、改一部分常用开关（主题、详细输出这类）。

एक आसान भ्रम का बिंदु जिसे आधिकारिक तौर पर स्पष्ट रूप से स्पष्ट किया गया है: /config में Config टैब आपकी settings.json फ़ाइल की सामग्री का एक पूरा दृश्य नहीं है, यह केवल कुछ निश्चित स्विचों (जैसे थीम, विस्तृत आउटपुट) के लिए एक संपादक है। /config में आपके द्वारा लिखी गई प्रत्येक सेटिंग को देखने की उम्मीद न करें——完整的还得去文件里看。

改完啥时候生效：大部分热加载，两个例外要重启

यह एक अच्छी खबर है—Claude Code आपकी सेटिंग्स फ़ाइल पर नज़र रखेगा, और अधिकांश सेटिंग्स को बदलने पर वे सक्रिय सत्र में सीधे प्रभावी हो जाएँगी, पुनरारंभ करने की आवश्यकता नहीं होगी。官方明说：

Claude Code 监视您的设置文件，并在它们更改时重新加载它们……这包括 permissions、hooks 和凭证助手。

लेकिन दो अपवाद हैं, जो "स्टार्टअप पर केवल एक बार पढ़े जाते हैं और उन्हें लागू करने के लिए पुनरारंभ आवश्यक है"?

फ़ील्ड	बदलने के बाद यह कैसे प्रभावी होता है
`model`	पुनरारंभ करें, या सत्र में स्विच करने के लिए `/model` का उपयोग करें
`outputStyle` (आउटपुट शैली, अगले लेख में चर्चा की जाएगी)	पुनरारंभ करें, या `/clear` के बाद फिर से बनाएं

इस नियम का व्यावहारिक महत्व: यदि आप permissions या hooks को बदलते हैं, तो वे फ़ाइल सहेजते ही प्रभावी हो जाते हैं; लेकिन यदि आप model बदलते हैं और कोई अंतर नहीं देखते हैं, तो यह न सोचें कि आपने गलत लिखा है—इसे प्रभावी होने के लिए पुनरारंभ करने की आवश्यकता होती है。开头那个坑要是发生在 permissions 上，本来存盘就能验出来，偏偏撞上了「层级被忽略」的特例，才多绕了那么久。

कैसे पुष्टि करें कि यह वास्तव में पढ़ा गया है: `/status` में "Setting sources" देखें

यह सबसे महत्वपूर्ण कदम है, जो इस समस्या का समाधान करता है कि "मुझे यकीन नहीं है कि आखिरकार कौन सी सेटिंग्स फ़ाइल लोड हुई है"。सत्र में /status टाइप करें, वहां आपको एक पंक्ति Setting sources मिलेगी, जो वर्तमान सत्र में वास्तव में लोड किए गए सेटिंग्स के स्तरों को सूचीबद्ध करती है—जैसे कि User settings, Project local settings (विशिष्ट टैग नाम वास्तविक इंटरफ़ेस पर आधारित होते हैं)。

官方对它的说明很实在：

Setting sources 行确认正在读取哪些源……仅当该源至少加载一个键时，该层才出现在列表中，因此空列表意味着未找到任何设置源。

यह जानकारी बहुत महत्वपूर्ण है, इसे विस्तार से समझें:

आपके द्वारा लिखा गया स्तर सूची में दिखाई देता है = फ़ाइल सफलतापूर्वक पढ़ ली गई है।
आपके द्वारा लिखा गया स्तर dिखाई नहीं देता = Claude Code को यह बिल्कुल नहीं मिला/पढ़ा (संभवतः गलत फ़ाइल पथ के कारण, जैसे कि .claude/settings.json को settings.json लिख देना)。
यदि फ़ाइल में सिंटैक्स त्रुटि है (JSON दूषित है, मान अमान्य है), तो /status सीधे त्रुटि प्रदर्शित करेगा, जिससे आपको अनुमान लगाने की आवश्यकता नहीं होगी。

इसलिए भविष्य में settings.json को कॉन्फ़िगर करने के बाद, पहला काम /status टाइप करके यह पुष्टि करना है कि वह स्तर वास्तव में सूची में है——这一步要是早知道，开头那二十分钟的弯路能省成两分钟。

配置不生效？照这张表排查

इस लेख की सभी समस्याओं को एक समस्या निवारण तालिका में संकलित किया गया है। अगली बार जब आपका कॉन्फ़िगरेशन प्रभावी न हो, तो सीधे सिंटैक्स पर संदेह न करें, बल्कि इस क्रम में जांच करें, आप निश्चित रूप से समस्या का पता लगा लेंगे:

लक्षण	❌ पहले इस पर संदेह न करें	✅ पहले इसकी जांच करें
बदलने के बाद कोई अंतर नहीं दिख रहा है	फ़ील्ड नाम गलत लिखा है?	`/status` में देखें कि आपका स्तर `Setting sources` में है या नहीं—यदि नहीं, तो फ़ाइल पथ गलत है
`model` बदलने पर भी नहीं बदला	कॉन्फ़िगरेशन दूषित है?	`model` केवल पुनरारंभ करने पर प्रभावी होता है (या स्विच करने के लिए `/model` का उपयोग करें), केवल फ़ाइल सहेजना पर्याप्त नहीं है
`defaultMode: "auto"` काम नहीं कर रहा है	वर्तनी (spelling) गलत है?	`auto` को प्रोजेक्ट/स्थानीय-स्तर पर अनदेखा कर दिया जाता है, इसे उपयोगकर्ता-स्तर पर जाना चाहिए (धारा 03)
`deny` लिखा है लेकिन कमांड अभी भी चल रही है	deny सही ढंग से नहीं लिखा?	अनुमतियाँ स्तरों के बीच मर्ज होती हैं, संभवतः किसी अन्य स्तर पर एक `allow` नियम है जिसे हटाया नहीं गया है (धारा 03)
कोई फ़ील्ड settings.json में नहीं लिखी जा रही है	JSON प्रारूप गलत है?	यह `~/.claude.json` में स्थित हो सकती है (जैसे `autoConnectIde`, धारा 04)

你看这张表里，真正属于「语法写错」的几乎没有——绝大多数「不生效」都是层级、生效时机、合并语义这几个概念没吃透。这也正是开头那个坑最想传给你的一句话：settings.json 难的从来不是怎么写，是搞清它那套分层规则。

💡 一句话总结：改文件或用 /config（后者只管少数开关）；permissions/hooks 存盘热加载、model/outputStyle 要重启；配完务必 /status 看「Setting sources」那行确认你那层真被读到了；不生效先查层级别查语法。

06 动手：写一份用户级 + 项目级配置，用 /status 验证它真生效

केवल देखना ही पर्याप्त नहीं है। नीचे हम दो स्तरों पर कॉन्फ़िगरेशन लिखेंगे और सत्यापित करने के लिए /status का उपयोग करेंगे——把这一篇的「写文件 → 分层 → 验证」整条链路跑通一遍。全程用最小示例，不依赖你已有的复杂环境。

पहला चरण: एक परीक्षण प्रोजेक्ट बनाएं (टर्मिनल में)

bash

mkdir settings-demo && cd settings-demo

दूसरा चरण: प्रोजेक्ट-स्तर कॉन्फ़िगरेशन लिखें

settings-demo/.claude/settings.json में निम्नलिखित सामग्री डालें (परीक्षण कमांड की अनुमति दें, curl को ब्लॉक करें)। पहली पंक्ति में $schema आपके संपादक को सत्यापन करने में मदद करेगा:

json

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": ["Bash(npm run test *)"],
    "deny": ["Bash(curl *)"]
  }
}

तीसरा चरण: स्थानीय-स्तर कॉन्फ़िगरेशन लिखें

अब settings-demo/.claude/settings.local.json में एक व्यक्तिगत अनुमति नियम जोड़ें जो केवल आपके लिए है और git में शामिल नहीं होगा:

json

{
  "permissions": {
    "allow": ["Bash(git status *)"]
  }
}

अपेक्षा: दोनों फ़ाइलें बनाने के बाद, आपके प्रोजेक्ट में एक ही समय में "प्रोजेक्ट-स्तर" और "स्थानीय-स्तर" दोनों कॉन्फ़िगरेशन होंगे। ध्यान दें—धारा 02 में बताए अनुसार, settings.local.json स्वचालित रूप से gitignore (अगले चरण में सत्यापित) किया जाएगा।

चौथा चरण: पुष्टि करें कि स्थानीय-स्तर वास्तव में git द्वारा अनदेखा किया गया है

bash

git init -q && git status --short

अपेक्षा: आउटपुट में आप .claude/settings.json (प्रोजेक्ट-स्तर, रिपोजिटरी में जोड़ने के लिए तैयार) देखेंगे, लेकिन नहीं देखेंगे .claude/settings.local.json—इसे स्वचालित रूप से अनदेखा कर दिया गया है। यह अंतर देखना = धारा 02 के "स्थानीय-स्तर स्वचालित रूप से gitignored" का आपके यहाँ सफल सत्यापन है।

五步：进会话，用 /status 验证两层都被读到

bash

claude

进去后敲：

text

/status

अपेक्षा: प्रदर्शित स्थिति जानकारी में Setting sources पंक्ति ढूंढें, इसमें Project local settings सूचीबद्ध होना चाहिए (साथ ही User settings भी हो सकती है जिसे आपने पहले कॉन्फ़िगर किया था), विशिष्ट लेबल नाम वास्तविक इंटरफ़ेस पर आधारित होते हैं। यह देखना कि आपके द्वारा लिखे गए स्तर सूची में हैं = कॉन्फ़िगरेशन सफलतापूर्वक लोड हो गया है। यदि कोई स्तर दिखाई नहीं देता है, तो धारा 02 पर वापस जाएं और फ़ाइल पथ की जांच करें।

छठा चरण: नियमों के प्रभावी होने की पुष्टि करने के लिए /permissions का उपयोग करें

text

/permissions

अपेक्षा: आप अभी लिखे गए नियम देख सकते हैं—npm run test * और git status * अनुमति सूची में हैं, और curl * अस्वीकार सूची में है। विशेष ध्यान दें: git status * स्थानीय-स्तर से आता है और अन्य दो नियम प्रोजेक्ट-स्तर से आते हैं, लेकिन वे सभी प्रभावी हैं—यह धारा 03 में चर्चा किए गए "अनुमति नियम स्तरों के बीच मर्ज होते हैं, ओवरराइड नहीं" का एक लाइव उदाहरण है।

इन छह चरणों को पूरा करने के बाद, आपने settings.json की सबसे मुख्य क्षमताओं का सीधे परीक्षण किया है: स्तरों में लिखना, व्यक्तिगत सेटिंग्स को स्वचालित रूप से अलग करना, लोड की पुष्टि करने के लिए /status का उपयोग करना, और मर्जर प्रभाव देखने के लिए /permissions का उपयोग करना। भविष्य में किसी भी स्तर या फ़ील्ड को कॉन्फ़िगर करना इसी प्रक्रिया पर आधारित होगा।

💡 一句话总结：动手就练「项目级 + 本地级两份配置 → git status 验本地级被忽略 → /status 看两层都加载 → /permissions 看规则合并」——亲手跑通这条链路，分层和合并这两个最绕的点立刻就通了。

07 सारांश

इस लेख में हमने Claude Code के "मुख्य नियंत्रण बोर्ड" settings.json को पूरी तरह से समझ लिया है—"यह क्या है" से लेकर "इसके कितने स्तर हैं, कौन किसे ओवरराइड करता है, और परिवर्तन के बाद सत्यापन कैसे करें" तक, कॉन्फ़िगरेशन को ठीक से व्यवस्थित किया गया है。

समीक्षा के लिए मुख्य बिंदुओं को एक साथ जोड़ें:

वह प्रश्न जो आप स्पष्ट करना चाहते हैं	उत्तर	एक-पंक्ति का मुख्य बिंदु
CLAUDE.md के साथ इसका क्या संबंध है	दो अलग-अलग प्रणालियाँ	CLAUDE.md "क्या याद रखना है" प्रबंधित करता है, और `settings.json` "काम कैसे करना है" प्रबंधित करता है
कितने स्तर हैं और वे कहाँ जाते हैं	तीन स्तर	उपयोगकर्ता-स्तर `~/.claude/`, प्रोजेक्ट-स्तर `.claude/` (git में जाता है), स्थानीय-स्तर `.claude/settings.local.json` (स्वचालित रूप से gitignore है)
विरोध होने पर किसकी बात मानी जाती है	अधिक विशिष्ट की प्राथमिकता अधिक	कमांड लाइन > स्थानीय > प्रोजेक्ट > उपयोगकर्ता, Managed सर्वोच्च
सबसे विपरीत-सहज बिंदु	सरणी विलय	अनुमति नियम जैसी सरणियाँ स्तरों के बीच जोड़ी जाती हैं और डुप्लिकेट हटाए जाते हैं, ओवरराइड नहीं
सबसे अधिक उपयोग की जाने वाली सेटिंग्स	पांच सेटिंग्स	`model`/`permissions`/`env`/`hooks`/`statusLine`
परिवर्तन के बाद सत्यापन कैसे करें	`/status`	"Setting sources" पंक्ति में पुष्टि करें कि आपका स्तर लोड हो गया है

अब आपको यह करने में सक्षम होना चाहिए: settings.json और CLAUDE.md के बीच के अंतर को समझना, यह जानना कि कोई कॉन्फ़िगरेशन उपयोगकर्ता-स्तर पर जाना चाहिए या प्रोजेक्ट-स्तर पर, प्राथमिकता क्रम और "सरणी विलय" के अपवाद को समझना, model/permissions/env/hooks/statusLine जैसी उच्च-आवृत्ति सेटिंग्स को पहचानना, और कॉन्फ़िगर करने के बाद /status से इसके प्रभावी होने की पुष्टि करना। यह "स्तरित कॉन्फ़िगरेशन" क्षमता वह उपकरण है जिसके माध्यम से आप Claude Code को अपनी और अपनी टीम के कार्यप्रवाह के अनुकूल बना सकते हैं।

शुरुआत में बर्बाद हुए बीस मिनटों का मूल कारण केवल एक वाक्य में था—"यह स्पष्ट न होना कि किस स्तर पर लिखना है"。इस लेख को पढ़ने के बाद, आप बहुत समय बचा सकते हैं: जब कॉन्फ़िगरेशन प्रभावी न हो, तो सिंटैक्स पर संदेह करने के बजाय पहले सोचें "क्या मैंने इसे गलत स्तर पर रखा है", और फिर जांचने के लिए /status का उपयोग करें。

अगला लेख 32 "आउटपुट शैलियाँ (Output Styles)" — आपने अभी-अभी settings.json में एक विशिष्ट outputStyle फ़ील्ड देखा है, याद रखें कि यह उन दो अपवादों में से एक है जो "स्टार्टअप पर केवल एक बार पढ़े जाते हैं और उन्हें लागू करने के लिए पुनरारंभ आवश्यक है"? अगले लेख में हम इसी के बारे में चर्चा करेंगे: Claude की "बोलने की शैली और सिस्टम संकेतों" को कैसे अनुकूलित करें, ताकि इसे डिफ़ॉल्ट "कार्य सहायक" से अधिक व्याख्यात्मक, शैक्षणिक या अन्य शैलियों में बदला जा सके। इसके बारे में सोचें: वही Claude, एक अलग आउटपुट शैली के साथ, आपको मिलने वाले उत्तरों की शैली में कितना अंतर ला सकता है?

settings.json: 用户级 / 项目级配置 ​

01 पहले समझें: settings.json क्या है और CLAUDE.md के साथ इसका क्या विभाजन है ​

02 三个层级：主目录、项目里、还是只在你这台机器 ​

व्यावहारिक रूप में इसे कैसे विभाजित करें: एक वास्तविक प्रोजेक्ट का त्रि-स्तरीय वितरण ​

03 谁压谁：优先级，外加一个最反直觉的例外 ​

那个最反直觉的例外：数组是「合并」，不是「覆盖」 ​

04 सबसे अधिक उपयोग की जाने वाली सेटिंग्स: वे किस स्तर पर जाती हैं और क्या करती हैं ​

model：默认用哪个模型 ​

permissions：准不准用某个工具 / 命令 ​

env：给会话注入环境变量 ​

hooks：在固定时机自动跑脚本 ​

statusLine：自定义底部状态栏 ​

一个容易踩的混淆：不是所有配置都住在 settings.json 里 ​

05 在哪编辑、改完啥时候生效、怎么确认它真的读到了 ​

在哪编辑：直接改文件，或者用 /config ​

改完啥时候生效：大部分热加载，两个例外要重启 ​

कैसे पुष्टि करें कि यह वास्तव में पढ़ा गया है: /status में "Setting sources" देखें ​

配置不生效？照这张表排查 ​

06 动手：写一份用户级 + 项目级配置，用 /status 验证它真生效 ​

07 सारांश ​

अनुशंसित पठन ​

settings.json: 用户级 / 项目级配置

01 पहले समझें: settings.json क्या है और CLAUDE.md के साथ इसका क्या विभाजन है

02 三个层级：主目录、项目里、还是只在你这台机器

व्यावहारिक रूप में इसे कैसे विभाजित करें: एक वास्तविक प्रोजेक्ट का त्रि-स्तरीय वितरण

03 谁压谁：优先级，外加一个最反直觉的例外

那个最反直觉的例外：数组是「合并」，不是「覆盖」

04 सबसे अधिक उपयोग की जाने वाली सेटिंग्स: वे किस स्तर पर जाती हैं और क्या करती हैं

model：默认用哪个模型

permissions：准不准用某个工具 / 命令

env：给会话注入环境变量

hooks：在固定时机自动跑脚本

statusLine：自定义底部状态栏

一个容易踩的混淆：不是所有配置都住在 settings.json 里

05 在哪编辑、改完啥时候生效、怎么确认它真的读到了

在哪编辑：直接改文件，或者用 `/config`

改完啥时候生效：大部分热加载，两个例外要重启

कैसे पुष्टि करें कि यह वास्तव में पढ़ा गया है: `/status` में "Setting sources" देखें

配置不生效？照这张表排查

06 动手：写一份用户级 + 项目级配置，用 /status 验证它真生效

07 सारांश

अनुशंसित पठन