config.toml कॉन्फ़िगरेशन विवरण: एक फ़ाइल से सभी सेटिंग्स नियंत्रित करें

📚 सीरीज नेविगेशन: पिछला लेख 17 · कंप्यूटर उपयोग और ब्राउज़र (Computer Use) Codex को सक्षम बनाता है—स्क्रीन देखने, डेस्कटॉप पर क्लिक करने और ब्राउज़र खोलने की अनुमति देता है। यह लेख ग्राफिकल इंटरफ़ेस से वापस एक सरल टेक्स्ट फ़ाइल—config.toml पर जाता है। पिछले लेखों में आपने इसे कई बार देखा है (सैंडबॉक्स सेट करना, Memory सक्षम करना, मॉडल सेट करना)। इस लेख में हम इसे विस्तार से समझेंगे: यह फ़ाइल कहाँ होती है, कैसी दिखती है, कौन सी सेटिंग क्या नियंत्रित करती है, और एक से अधिक फ़ाइलें होने पर किसकी प्राथमिकता होती है।

अक्सर कहा जाता है कि कॉन्फ़िगरेशन फ़ाइलें "इंस्टॉल करने के बाद देखी जाने वाली" चीजें होती हैं, जब तक चल रहा हो तब तक उन्हें न छुएं—लेकिन सच कहें तो, Codex के संदर्भ में यह बात पूरी तरह से उल्टी है।

मेरा अपना अनुभव इस प्रकार है: जब मैंने 2026 के मार्च में शुरुआत की, तो मैंने config.toml को बिल्कुल नहीं छुआ। मैं हर बार Codex खोलते समय मैन्युअल रूप से /model द्वारा मॉडल बदलता था, /permissions द्वारा अनुमतियाँ सेट करता था, और नेटवर्क सक्षम करने के लिए --search चलाता था। एक ही काम दिन में सात-आठ बार करना पड़ता था। एक दिन मैंने गिना—केवल "मजबूत मॉडल पर स्विच करना + वर्कस्पेस लिखने की अनुमति देना" के लिए ही मैंने सप्ताह में तीस से अधिक बार मैन्युअल रूप से कमांड चलाई थी। उस समय मुझे समझ आया: मैंने एक ऐसी चीज़ को जो 'एक बार लिखकर हमेशा के लिए लागू' की जा सकती थी, उसे बार-बार करने वाला काम बना दिया था।

config.toml का महत्व यही है—यह केवल उन्नत उपयोगकर्ताओं के लिए नहीं है, बल्कि उन सभी के लिए है जो काम आसान बनाना चाहते हैं। आप जितना कम हर बार कॉन्फ़िगर करना चाहते हैं, आपको इसे समझने में उतने ही दस मिनट देने चाहिए।

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

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

• एक सरल विवरण कि config.toml क्या है, और यह AGENTS.md से किस प्रकार अलग है।
• उपयोगकर्ता स्तर (User-level) ~/.codex/config.toml और प्रोजेक्ट स्तर (Project-level) .codex/config.toml कहाँ होते हैं, किसे नियंत्रित करते हैं और उनमें क्या लिखा जाना चाहिए।
• प्राथमिकता का नियम, और एक सुरक्षा सीमा जिसे शुरुआती लोगों को अवश्य जानना चाहिए (प्रोजेक्ट कॉन्फ़िगरेशन में कुछ सेटिंग्स काम नहीं करतीं)।
• अक्सर उपयोग किए जाने वाले सात-आठ कॉन्फ़िगरेशन विकल्प (model, approval_policy, sandbox_mode, web_search, [features]...) क्या करते हैं और उनके डिफ़ॉल्ट मान क्या हैं।
• एक उदाहरण कॉन्फ़िगरेशन + -c द्वारा अस्थायी रूप से बदलने की कमांड + --profile द्वारा एकाधिक कॉन्फ़िगरेशन स्विच करने का व्यावहारिक अनुभव।

---

01 पहले समझें: config.toml क्या है, और AGENTS.md से इसका क्या संबंध है

निष्कर्ष यह है: config.toml Codex के लिए "व्यवहार नियंत्रण केंद्र" है—यह TOML प्रारूप का उपयोग करके मॉडल, अनुमोदन, सैंडबॉक्स, MCP और विभिन्न सुविधाओं को नियंत्रित करता है; यह AGENTS.md से अलग है, जहाँ एक यह तय करता है कि "कैसे काम करना है" और दूसरा यह कि "क्या याद रखना है"।

बहुत से लोग शुरुआत में इन दोनों में भ्रमित हो जाते हैं। आपने 11 · AGENTS.md में प्रोजेक्ट विवरण लिखे थे, और 15 · अनुमतियाँ सैंडबॉक्स और अनुमोदन में सैंडबॉक्स सेटिंग्स की थीं—पहला AGENTS.md में जाता है, और दूसरा config.toml में। दोनों में बहुत भिन्न जानकारी होती है।

तुलना: कार के "यूज़र मैनुअल" और "डैशबोर्ड बटन्स" से। AGENTS.md कार के ग्लव बॉक्स में रखे यूज़र मैनुअल की तरह है—जिसमें लिखा होता है कि "इस कार में 95 ऑक्टेन पेट्रोल डालें" या "सर्दियों में शुरू करने से पहले थोड़ा गर्म होने दें"। यह इंसान (या Codex) के समझने के लिए सामान्य भाषा में निर्देश होते हैं, जिन्हें काम शुरू करने से पहले पढ़ा जाता है। config.toml अलग है, यह डैशबोर्ड पर बने बटन्स की तरह है—एसी का तापमान कितना रखना है, सीट हीटिंग चालू करनी है या नहीं, स्पोर्ट मोड रखना है या इकोनॉमी मोड। ये स्पष्ट निर्देश होते हैं जिन्हें सिस्टम सीधे निष्पादित करता है। मैनुअल "समझने के निर्देश" है, और बटन्स "व्यवहार सेटिंग्स" हैं।

TOML (Tom's Obvious Minimal Language) इस फ़ाइल का प्रारूप है, जो इस प्रकार दिखता है: सबसे ऊपर key = value होता है, और ग्रुपिंग के लिए [table_name] का उपयोग किया जाता है। एक उदाहरण देखें:

# ~/.codex/config.toml
model = "gpt-5.5"
approval_policy = "on-request"
sandbox_mode = "workspace-write"

आधिकारिक तौर पर इसकी स्थिति को इस प्रकार स्पष्ट किया गया है:

Codex stores user-level configuration at ~/.codex/config.toml. (Codex उपयोगकर्ता स्तर की कॉन्फ़िगरेशन को ~/.codex/config.toml में सहेजता है।)

दैनिक उपयोग में config.toml निम्नलिखित चीज़ों को नियंत्रित करता है:

• "मैं हर बार एक विशिष्ट मॉडल का उपयोग करना चाहता हूँ, मुझे बार-बार बदलना न पड़े"—model सेट करें।
• "इस मशीन पर डिफ़ॉल्ट रूप से मुझे वर्कस्पेस में लिखने की अनुमति हो और सीमा से बाहर जाने पर ही पूछा जाए"—sandbox_mode + approval_policy सेट करें।
• "वेब सर्च हमेशा लाइव हो, कैश का उपयोग न किया जाए"—web_search सेट करें।
• "किसी प्रयोगात्मक सुविधा को चालू या बंद करना"—[features] सेट करें।

ये Codex को केवल "समझाने के निर्देश" नहीं हैं, बल्कि इसके काम करने के तरीके को सीधे प्रभावित करने वाले विकल्प हैं। यही config.toml और AGENTS.md के बीच का मुख्य अंतर है।

💡 संक्षेप में: AGENTS.md "Codex के समझने के लिए निर्देश" है, और config.toml "इसके व्यवहार को नियंत्रित करने वाले विकल्पों का समूह" है—पहला यह तय करता है कि क्या याद रखना है, और दूसरा यह कि काम कैसे करना है।

---

02 फ़ाइल कहाँ होती है: उपयोगकर्ता स्तर और प्रोजेक्ट स्तर पर

config.toml में सेटिंग्स को समझने से पहले यह जानना आवश्यक है कि यह दो स्थानों पर हो सकती है: एक आपकी होम निर्देशिका में (ग्लोबल), और दूसरी प्रोजेक्ट निर्देशिका के भीतर (केवल उस प्रोजेक्ट के लिए)।

तुलना: घर के मुख्य बिजली बोर्ड बनाम कमरे के स्विच बोर्ड से। आपके घर में एक मुख्य बिजली बोर्ड होता है (आमतौर पर मुख्य द्वार के पास), जो पूरे घर के लिए डिफ़ॉल्ट सेट करता है—जैसे "रात के समय बिजली की सीमा तय करना"। इसके अलावा, प्रत्येक कमरे में अपना स्विच बोर्ड होता है, जो केवल उस कमरे को नियंत्रित करता है और उसकी प्राथमिकता अधिक होती है—यदि आप स्टडी रूम में तेज लाइट जलाना चाहते हैं, तो स्टडी रूम का स्विच दबाएं, इससे अन्य कमरों पर कोई प्रभाव नहीं पड़ेगा। config.toml भी ठीक वैसा ही है: होम निर्देशिका वाली फ़ाइल मुख्य बिजली बोर्ड है, और प्रोजेक्ट डायरेक्टरी वाली फ़ाइल कमरे का स्विच बोर्ड है।

इनके स्थानों का विवरण इस तालिका में देखें:

स्तर	फ़ाइल का स्थान	प्रभाव	उपयोग	शर्त
उपयोगकर्ता स्तर (User)	~/.codex/config.toml	आपके सभी प्रोजेक्ट्स पर	ग्लोबल डिफ़ॉल्ट: पसंदीदा मॉडल, सुरक्षा स्तर, MCP, सूचनाएं	कोई नहीं
प्रोजेक्ट स्तर (Project)	<repo>/.codex/config.toml	केवल वर्तमान प्रोजेक्ट पर	प्रोजेक्ट विशिष्ट: प्रोजेक्ट के लिए उपयुक्त मॉडल, सैंडबॉक्स नियम	प्रोजेक्ट पर भरोसा (trust) होने पर ही लागू

यहाँ शुरुआती लोगों के लिए तीन महत्वपूर्ण नियम दिए गए हैं:

पहला, उपयोगकर्ता स्तर की फ़ाइल का पथ निश्चित है: ~/.codex/config.toml। यह ~/.codex निर्देशिका CODEX_HOME कहलाती है, जहाँ Codex की सभी स्थानीय चीज़ें (कॉन्फ़िगरेशन, लॉगिन क्रेडेंशियल्स, इतिहास, लॉग) संग्रहीत होती हैं। यदि फ़ाइल मौजूद नहीं है, तो आप इसे बना सकते हैं।

दूसरा, प्रोजेक्ट स्तर की फ़ाइल को प्रोजेक्ट के भीतर .codex/ निर्देशिका में रखा जाना चाहिए (ध्यान रखें कि यह .codex/config.toml है, जो एक छिपी हुई निर्देशिका है)। यह केवल तभी लागू होती है जब आप उस प्रोजेक्ट पर काम कर रहे हों।

तीसरा, और सबसे महत्वपूर्ण—प्रोजेक्ट स्तर की कॉन्फ़िगरेशन केवल तभी लोड होती है जब "प्रोजेक्ट पर भरोसा" किया गया हो। यह Codex का सुरक्षा डिज़ाइन है ताकि कोई भी क्लोन किया गया अपरिचित प्रोजेक्ट चुपके से अनुमतियाँ न बढ़ा सके। आधिकारिक विवरण:

If you mark a project as untrusted, Codex skips project-scoped .codex/ layers, including project-local config, hooks, and rules. (यदि आप किसी प्रोजेक्ट को अनट्रस्टेड के रूप में चिह्नित करते हैं, तो Codex प्रोजेक्ट-स्तरीय .codex/ परतों को छोड़ देता है, जिसमें प्रोजेक्ट-लोकल कॉन्फ़िगरेशन, हुक्स और नियम शामिल हैं।)

सरल शब्दों में: यदि प्रोजेक्ट पर भरोसा नहीं किया गया है, तो .codex/config.toml में लिखी गई कोई भी सेटिंग लागू नहीं होगी—लेकिन होम डायरेक्टरी वाली फ़ाइल हमेशा लागू रहेगी। यदि प्रोजेक्ट सेटिंग्स काम नहीं कर रही हैं, तो पहले यह जाँचें कि क्या आपने प्रोजेक्ट पर भरोसा (Trust) करने की पुष्टि की है या नहीं।

व्यवहार में कैसे तय करें: कॉन्फ़िगरेशन कहाँ लिखनी चाहिए

यह तय करने के लिए स्वयं से एक सवाल पूछें: "क्या यह सेटिंग केवल मुझसे संबंधित है, या इस विशिष्ट प्रोजेक्ट से?"

• "मैं इसे सभी प्रोजेक्ट्स में उपयोग करना चाहता हूँ" → उपयोगकर्ता स्तर (~/.codex/config.toml) पर लिखें। जैसे "मैं हमेशा डिफ़ॉल्ट रूप से gpt-5.5 का उपयोग करना चाहता हूँ" या "मेरा MCP सर्वर"। यह सेट करने पर सभी प्रोजेक्ट्स में लागू रहेगा।
• "यह केवल इस विशिष्ट प्रोजेक्ट के लिए है" → प्रोजेक्ट स्तर (<repo>/.codex/config.toml) पर लिखें। जैसे "इस प्रोजेक्ट में एक विशिष्ट मॉडल का उपयोग करना है" या "इस प्रोजेक्ट को हमेशा रीड-ओनली रखना है"। यह प्रोजेक्ट के साथ रहेगा और टीम के अन्य सदस्यों के लिए भी लागू होगा (यदि वे भी प्रोजेक्ट पर भरोसा करते हैं)।

मेरा व्यक्तिगत तरीका सरल है: मैं उपयोगकर्ता स्तर की फ़ाइल में अपनी आदतें लिखता हूँ, और प्रोजेक्ट स्तर की फ़ाइल को खाली रखता हूँ—केवल तभी उपयोग करता हूँ जब किसी प्रोजेक्ट के लिए विशेष नियम की आवश्यकता हो (जैसे किसी क्लाइंट के संवेदनशील कोडबेस के लिए, जहाँ मैं .codex/config.toml में sandbox_mode = "read-only" लिख देता हूँ)। इससे यह नियम अन्य प्रोजेक्ट्स को प्रभावित नहीं करता।

💡 संक्षेप में: उपयोगकर्ता स्तर ~/.codex/config.toml (सभी प्रोजेक्ट्स के लिए) और प्रोजेक्ट स्तर <repo>/.codex/config.toml (केवल वर्तमान प्रोजेक्ट के लिए, भरोसा होने पर ही लोड) होते हैं।

---

03 किसकी प्राथमिकता होती है: प्राथमिकता नियम और सुरक्षा सीमाएँ

दोनों फ़ाइलों में एक ही सेटिंग लिखी हो सकती है। तो सवाल उठता है: यदि उपयोगकर्ता स्तर पर मॉडल gpt-5.5 लिखा है और प्रोजेक्ट स्तर पर कुछ और, तो किसका नियम लागू होगा? इसे प्राथमिकता (precedence) कहते हैं।

वास्तव में इसमें कुल छह स्तर होते हैं (कमांड लाइन पैरामीटर, --profile विकल्प, और सिस्टम सेटिंग्स को मिलाकर)। प्राथमिकता का क्रम उच्च से निम्न (उच्च प्राथमिकता वाले नियम पहले लागू होते हैं) इस प्रकार है:

प्राथमिकता	स्रोत	विवरण
1 (उच्चतम)	कमांड लाइन पैरामीटर / --config	वर्तमान सत्र के लिए किया गया तात्कालिक बदलाव
2	प्रोजेक्ट स्तर <repo>/.codex/config.toml	प्रोजेक्ट विशिष्ट सेटिंग्स (प्रोजेक्ट पर भरोसा होने पर, फ़ाइल के जितने निकट होगा प्राथमिकता उतनी ही अधिक होगी)
3	--profile द्वारा चुनी गई कॉन्फ़िगरेशन ~/.codex/<name>.config.toml	नाम के अनुसार निर्दिष्ट सेटिंग्स का समूह
4	उपयोगकर्ता स्तर ~/.codex/config.toml	आपका ग्लोबल डिफ़ॉल्ट
5	सिस्टम स्तर /etc/codex/config.toml (Unix सिस्टम पर)	सिस्टम एडमिनिस्ट्रेटर द्वारा निर्धारित सेटिंग्स
6 (निम्नतम)	सिस्टम डिफ़ॉल्ट मान	यदि कहीं कोई सेटिंग न हो, तो लागू होने वाले डिफ़ॉल्ट मान

इस प्राथमिकता को इस आरेख से समझें—ऊपर की परतें नीचे की परतों में लिखी गई समान सेटिंग्स को ओवरराइड करती हैं:

यह आरेख छह परतों को प्राथमिकता के क्रम में दिखाता है: सबसे ऊपर "कमांड लाइन पैरामीटर / --config" है, जिसके बाद प्रोजेक्ट स्तर, --profile प्रोफ़ाइल, उपयोगकर्ता स्तर, सिस्टम स्तर और सबसे नीचे सिस्टम डिफ़ॉल्ट मान हैं। ऊपर की सेटिंग्स नीचे की समान सेटिंग्स को ओवरराइड करती हैं।

नियम सरल है: जो सेटिंग वर्तमान सत्र के जितनी अधिक विशिष्ट होगी, उसकी प्राथमिकता उतनी ही अधिक होगी। कमांड लाइन प्रोजेक्ट से ऊपर है, प्रोजेक्ट प्रोफ़ाइल से ऊपर है, प्रोफ़ाइल उपयोगकर्ता स्तर से ऊपर है, और उपयोगकर्ता स्तर सिस्टम से ऊपर है। आधिकारिक सलाह:

Use that precedence to set shared defaults in config.toml and keep profile files focused on the values that differ. (इस प्राथमिकता का उपयोग करके सामान्य सेटिंग्स को config.toml में रखें, और प्रोफ़ाइल फ़ाइलों को केवल उन सेटिंग्स तक सीमित रखें जो अलग हैं।)

यानी—होम डायरेक्टरी में सामान्य सेटिंग्स रखें, प्रोफ़ाइल फ़ाइल में विशिष्ट बदलावों को रखें, और कमांड लाइन का उपयोग केवल अस्थायी परिवर्तनों के लिए करें। यह स्टार्टअप पर लागू होने वाली सेटिंग्स का सही तरीका है।

सुरक्षा सीमा: कुछ सेटिंग्स प्रोजेक्ट स्तर पर काम नहीं करतीं

हालांकि प्रोजेक्ट स्तर की प्राथमिकता उपयोगकर्ता स्तर से अधिक होती है, लेकिन सुरक्षा कारणों से कुछ सेटिंग्स को प्रोजेक्ट स्तर की फ़ाइल में लिखने पर Codex उन्हें अनदेखा कर देता है और स्टार्टअप पर एक चेतावनी दिखाता है।

क्यों? यदि कोई अवांछित प्रोजेक्ट आपके क्रेडेंशियल्स, डोमेन एड्रेस या नोटिफिकेशन कमांड्स को बदल दे, तो यह सुरक्षा के लिए बड़ा खतरा बन सकता है। इसलिए सिस्टम स्तर की संवेदनशील सेटिंग्स को केवल उपयोगकर्ता स्तर की फ़ाइल तक ही सीमित रखा गया है। आधिकारिक विवरण:

Codex ignores openai_base_url, chatgpt_base_url, apps_mcp_product_sku, model_provider, model_providers, notify, profile, profiles, experimental_realtime_ws_base_url, and otel when they appear in a project-local .codex/config.toml.

सरल शब्दों में, निम्नलिखित सेटिंग्स केवल उपयोगकर्ता स्तर पर ही लिखी जा सकती हैं, प्रोजेक्ट स्तर पर इन्हें अनदेखा कर दिया जाएगा:

विकल्प	विवरण	सुरक्षा का कारण
model_provider / model_providers	मॉडल प्रदाता, एपीआई एड्रेस	अवांछित प्रोजेक्ट्स को आपके डेटा को अन्य डोमेन पर भेजने से रोकने के लिए
openai_base_url / chatgpt_base_url	एपीआई का बेस URL	ऊपर की तरह ही, डेटा गंतव्य को बदलने से रोकने के लिए
notify	कार्य पूरा होने पर चलने वाली कमांड	मशीन पर अनधिकृत कमांड्स को निष्पादित होने से रोकने के लिए
otel	टेलीमेट्री / लॉग एक्सपोर्ट	आपके प्रोजेक्ट डेटा को बाहर जाने से रोकने के लिए
profile / profiles	प्रोफ़ाइल चयन	प्रोफ़ाइल को कमांड लाइन से ही चुना जा सकता है, प्रोजेक्ट फ़ाइल से नहीं

इसलिए याद रखें: मॉडल प्रोवाइडर, नोटिफिकेशन, टेलीमेट्री जैसी सेटिंग्स को हमेशा होम डायरेक्टरी वाली फ़ाइल में लिखें; प्रोजेक्ट स्तर की फ़ाइल में केवल model, sandbox_mode, approval_policy जैसी स्थानीय सेटिंग्स का ही उपयोग करें। यदि आप प्रोजेक्ट फ़ाइल में model_providers लिखते हैं और वह काम नहीं करता, तो इसका कारण यही सुरक्षा सीमा है।

💡 संक्षेप में: प्राथमिकता का क्रम "कमांड लाइन > प्रोजेक्ट > प्रोफ़ाइल > उपयोगकर्ता > सिस्टम > डिफ़ॉल्ट" है; लेकिन प्रोजेक्ट स्तर की फ़ाइल में model_provider, notify, otel जैसी सेटिंग्स काम नहीं करतीं, वे केवल उपयोगकर्ता स्तर पर ही लागू होती हैं।

---

04 अक्सर उपयोग किए जाने वाले कॉन्फ़िगरेशन विकल्प

प्राथमिकता को समझने के बाद, आइए उन सेटिंग्स पर नज़र डालते हैं जिनका अक्सर उपयोग किया जाता है। वैसे तो Codex में कई सेटिंग्स होती हैं, लेकिन अधिकांश समय केवल निम्नलिखित सेटिंग्स का ही उपयोग किया जाता है। डिफ़ॉल्ट मानों को समझना आवश्यक है ताकि आपको पता रहे कि क्या लिखने की आवश्यकता है और क्या नहीं।

कॉन्फ़िगरेशन विकल्प	विवरण	डिफ़ॉल्ट मान	उदाहरण
model	डिफ़ॉल्ट मॉडल	Codex डिफ़ॉल्ट	model = "gpt-5.5"
approval_policy	अनुमोदन नीति	on-request	approval_policy = "on-request"
sandbox_mode	सैंडबॉक्स मोड	workspace-write (Git प्रोजेक्ट में)	sandbox_mode = "workspace-write"
model_reasoning_effort	रीजनिंग तीव्रता	मॉडल के अनुसार	model_reasoning_effort = "high"
web_search	वेब सर्च मोड	cached (कैश का उपयोग)	web_search = "live"
personality	बोलने का लहजा	friendly	personality = "pragmatic"
file_opener	फ़ाइल लिंक खोलने के लिए संपादक	vscode	file_opener = "cursor"

सैंडबॉक्स मोड डिफ़ॉल्ट मान: डिफ़ॉल्ट रूप से, Git रिपोजिटरी में यह workspace-write पर रहता है (लिखने की अनुमति), और बिना Git वाली निर्देशिका में यह read-only रहता है।

कुछ सेटिंग्स का विवरण:

model / model_reasoning_effort / approval_policy / sandbox_mode

इन सेटिंग्स के बारे में पिछले लेखों में विस्तार से बात की गई है: मॉडल चयन के लिए 05 · थर्ड-पार्टी मॉडल, और सुरक्षा अनुमतियों के लिए 15 · अनुमतियाँ सैंडबॉक्स और अनुमोदन। इन्हें config.toml में लिखने से ये स्टार्टअप पर ही डिफ़ॉल्ट रूप से लागू हो जाते हैं, और आपको हर बार सेट करने की आवश्यकता नहीं होती।

model_reasoning_effort रीजनिंग की तीव्रता तय करता है, जिसके विकल्प minimal | low | medium | high | xhigh हैं। सरल कार्यों के लिए इसे कम रखा जा सकता है ताकि समय और token बचे, और कठिन कार्यों के लिए high का उपयोग करें।

web_search: वेब सर्च (ध्यान रखें कि डिफ़ॉल्ट रूप से यह "कैश" है, लाइव नहीं)

इस सेटिंग का डिफ़ॉल्ट मान महत्वपूर्ण है। डिफ़ॉल्ट रूप से वेब सर्च चालू रहती है, लेकिन यह cached मोड का उपयोग करती है—यानी यह पहले से सहेजे गए वेब पेजों के डेटाबेस से परिणाम देती है, लाइव इंटरनेट से तुरंत डेटा प्राप्त नहीं करती। सुरक्षा की दृष्टि से प्रॉम्प्ट इंजेक्शन हमलों को रोकने के लिए ऐसा किया गया है।

यदि आपको लाइव जानकारी की आवश्यकता है, तो इसे बदलें:

web_search = "live"   # लाइव सर्च का उपयोग, कमांड लाइन पर --search के समान
# web_search = "cached"   # डिफ़ॉल्ट: कैश डेटाबेस का उपयोग
# web_search = "disabled" # वेब सर्च को पूरी तरह बंद करना

अपवाद: यदि आप पूर्ण एक्सेस (--yolo) का उपयोग करते हैं, तो web_search स्वचालित रूप से live पर स्विच हो जाती है।

personality: बात करने का लहजा बदलना

personality बात करने का लहजा तय करता है, जिसके विकल्प none | friendly | pragmatic हैं। चैट के दौरान इसे /personality द्वारा भी बदला जा सकता है। मैं व्यक्तिगत रूप से pragmatic का उपयोग करता हूँ ताकि काम की बात सीधे हो सके।

file_opener: फ़ाइल लिंक खोलना

Codex आउटपुट में अक्सर फ़ाइल लिंक (जैसे filename.py:42) होते हैं। file_opener यह तय करता है कि इन लिंक्स पर क्लिक करने पर उन्हें किस कोड एडिटर में खोला जाए, जिसके विकल्प vscode | vscode-insiders | windsurf | cursor | none हैं। यदि आप Cursor का उपयोग करते हैं, तो इसे cursor पर सेट करें।

TOML प्रारूप की विशेषता: मुख्य सेटिंग्स हमेशा तालिकाओं (tables) से पहले होनी चाहिए

यह config.toml लिखते समय होने वाली एक आम गलती है। TOML नियमों के अनुसार: सभी मुख्य key = value सेटिंग्स को तालिका अनुभागों [table] से पहले लिखा जाना चाहिए।

गलत और सही तरीका इस प्रकार है:

❌ गलत तरीका (मुख्य सेटिंग्स तालिका के बाद)	✅ सही तरीका (मुख्य सेटिंग्स पहले, तालिकाएँ बाद में)
[features] hooks = true model = "gpt-5.5" (एरर)	model = "gpt-5.5" [features] hooks = true

नियम: पहले उन सेटिंग्स को लिखें जिनमें [] नहीं होता (जैसे model, approval_policy), और उसके बाद [features] जैसी तालिकाओं को लिखें। यदि क्रम सही नहीं होगा, तो TOML एरर दिखाएगा।

💡 संक्षेप में: अक्सर उपयोग किए जाने वाले विकल्प model, approval_policy, sandbox_mode, model_reasoning_effort, web_search (डिफ़ॉल्ट रूप से कैश), personality और file_opener हैं; TOML नियमों के अनुसार मुख्य सेटिंग्स को हमेशा तालिकाओं से पहले लिखें।

---

05 [features]: सुविधाओं को चालू या बंद करना

यह अनुभाग [features] तालिका के बारे में है, जो Codex में सभी वैकल्पिक और प्रयोगात्मक सुविधाओं का मुख्य स्विच बोर्ड है। Memory, hooks या उप-एजेंट जैसी सुविधाएँ यहीं से नियंत्रित होती हैं।

यह कार या फोन में मिलने वाले "प्रयोगात्मक विकल्प (Developer Options)" की तरह है, जहाँ कुछ सेटिंग्स डिफ़ॉल्ट रूप से चालू होती हैं और कुछ को मैन्युअल रूप से सक्षम करना होता है। [features] में प्रत्येक सुविधा के लिए true (चालू) या false (बंद) सेट किया जा सकता है।

इसे लिखने का तरीका:

[features]
memories = true          # Memory चालू करना
shell_snapshot = true    # रिपीट कमांड्स को तेज़ करने के लिए shell स्नैपशॉट
hooks = false            # hooks बंद करना

मुख्य सुविधाओं का विवरण इस प्रकार है:

सुविधा	डिफ़ॉल्ट मान	स्थिति	कार्य
hooks	true	स्थिर	लाइफसाइकिल hooks (इवेंट आधारित स्क्रिप्ट्स)
multi_agent	true	स्थिर	उप-एजेंट्स के बीच कार्य साझा करना
shell_snapshot	true	स्थिर	shell स्नैपशॉट द्वारा कार्य तेज़ करना
fast_mode	true	स्थिर	तेज़ी से प्रतिक्रिया देने का मोड
shell_tool	true	स्थिर	टर्मिनल में कमांड चलाने की क्षमता
personality	true	स्थिर	बात करने का लहजा बदलने की अनुमति
memories	false	स्थिर	Memory सिस्टम (अगले लेख में विवरण)
codex_git_commit	false	प्रयोगात्मक	Git कमिट संदेशों को स्वचालित रूप से लिखना
apps	false	प्रयोगात्मक	ChatGPT Apps सहायता
undo	false	स्थिर	git ghost द्वारा बदलावों को वापस लेना (Undo)

⚠️ प्रयोगात्मक सुविधाएँ समय के साथ बदल सकती हैं। प्रयोगात्मक चिह्नित सुविधाओं के डिफ़ॉल्ट मान भविष्य में बदल सकते हैं, इसलिए आधिकारिक संदर्भ का पालन करें।

एक बात ध्यान रखें: कुछ पुराने नाम (जैसे codex_hooks = true) अब समर्थित नहीं हैं—आधिकारिक तौर पर अब इसे केवल hooks लिखा जाता है।

सुविधाओं को बदलने के तीन तरीके हैं:

• config.toml फ़ाइल में: [features] के तहत name = true (या false) लिखें।
• कमांड लाइन पर अस्थायी रूप से: codex --enable feature_name का उपयोग करें।
• बंद करना: फ़ाइल में संबंधित विकल्प को false पर सेट करें।

सलाह: शुरुआत में सभी प्रयोगात्मक सुविधाओं को चालू न करें। केवल आवश्यक होने पर ही (जैसे Memory के लिए memories = true) चालू करें और बाकी को डिफ़ॉल्ट पर रहने दें।

💡 संक्षेप में: [features] विभिन्न सुविधाओं का नियंत्रण बोर्ड है, जहाँ true/false सेट किया जाता है। पुराने नामों (जैसे codex_hooks) की जगह नए नाम उपयोग करें।

---

06 अस्थायी रूप से बदलना और कॉन्फ़िगरेशन बदलना: -c और --profile

यदि आप केवल वर्तमान सत्र के लिए किसी सेटिंग को बदलना चाहते हैं, या एकाधिक सेटिंग्स के समूहों के बीच स्विच करना चाहते हैं, तो Codex निम्नलिखित दो विकल्प प्रदान करता है:

अस्थायी रूप से बदलना: -c / --config (फ़ाइल में बदलाव किए बिना)

फ़ाइल को बदले बिना, कमांड लाइन से ही किसी सेटिंग को बदलें:

# मॉडल बदलने के लिए सीधे फ़्लैग का उपयोग करें
codex --model gpt-5.4

# अन्य सेटिंग्स के लिए -c / --config का उपयोग करें (मूल्य TOML प्रारूप में होना चाहिए)
codex --config model='"gpt-5.4"'
codex -c log_dir=./.codex-log

ध्यान देने योग्य बातें:

• -c का मान TOML प्रारूप के अनुसार होना चाहिए। इसलिए स्ट्रिंग मान के लिए डबल कोट आवश्यक हैं (जैसे model='"gpt-5.4"' जहाँ बाहर सिंगल कोट और भीतर डबल कोट हैं)।
• नेस्टेड (Nested) सेटिंग्स के लिए डॉट का उपयोग करें, जैसे codex -c mcp_servers.context7.enabled=false।

यह तरीका किसी सेटिंग का परीक्षण करने के लिए उपयुक्त है—संतुष्ट होने पर आप इसे फ़ाइल में लिख सकते हैं।

सेटिंग्स के समूह बदलना: --profile (प्रोफ़ाइल)

प्रोफ़ाइल का अर्थ है CODEX_HOME में एक अलग कॉन्फ़िगरेशन फ़ाइल, जिसका नाम <name>.config.toml होता है:

# ~/.codex/deep-review.config.toml
model = "gpt-5.5"
model_reasoning_effort = "xhigh"
approval_policy = "on-request"

इसे उपयोग करने के लिए --profile विकल्प का उपयोग करें:

codex --profile deep-review
codex exec --profile deep-review "इस बदलाव की समीक्षा करें"

यह इस प्रकार काम करता है: Codex पहले मुख्य फ़ाइल ~/.codex/config.toml लोड करता है, और फिर प्रोफ़ाइल फ़ाइल ~/.codex/deep-review.config.toml की सेटिंग्स को उस पर लागू करता है। इसलिए प्रोफ़ाइल फ़ाइल में केवल उन्हीं सेटिंग्स को लिखने की आवश्यकता होती है जो मुख्य फ़ाइल से भिन्न हैं।

संस्करण परिवर्तन संबंधी चेतावनी:

⚠️ Codex 0.134.0 और उसके बाद के संस्करणों में, --profile अब मुख्य config.toml में लिखी गई [profiles.name] सेटिंग्स का समर्थन नहीं करता। पुरानी सेटिंग्स को अब अलग फ़ाइल ~/.codex/name.config.toml में लिखना होगा। आपके संस्करण के अनुसार व्यवहार अलग हो सकता है।

मैं स्वयं दो प्रोफ़ाइल का उपयोग करता हूँ: एक quick (कमज़ोर मॉडल + रीड-ओनली, कोड देखने के लिए) और दूसरी build (मजबूत मॉडल + लिखने की अनुमति, काम करने के लिए)। codex --profile build चलाने पर सभी आवश्यक सेटिंग्स एक साथ लागू हो जाती हैं।

💡 संक्षेप में: अस्थायी रूप से बदलने के लिए -c key=value का उपयोग करें, और सेटिंग्स के समूह को बदलने के लिए प्रोफ़ाइल फ़ाइल बनाकर --profile से कॉल करें।

---

07 अभ्यास: कॉन्फ़िगरेशन फ़ाइल बनाना, अस्थायी रूप से बदलना, और प्रोफ़ाइल स्विच करना

आइए इन सभी नियमों का एक व्यावहारिक अभ्यास करके देखें। यह एक सरल अभ्यास है।

चरण 1: जाँचें कि आपकी उपयोगकर्ता स्तर की फ़ाइल कहाँ है

टर्मिनल में चलाएं:

ls -la ~/.codex/config.toml

अपेक्षित परिणाम: फ़ाइल दिखाई देगी या एरर आएगा कि फ़ाइल मौजूद नहीं है। यदि मौजूद नहीं है, तो अगले चरण में इसे बनाएंगे।

चरण 2: एक सरल कॉन्फ़िगरेशन फ़ाइल लिखें

निम्नलिखित विवरण को ~/.codex/config.toml में लिखें (मुख्य सेटिंग्स पहले और तालिकाएँ बाद में):

# ~/.codex/config.toml
model = "gpt-5.5"
approval_policy = "on-request"
web_search = "cached"

[features]
memories = false

अपेक्षित परिणाम: यह आपकी ग्लोबल डिफ़ॉल्ट सेटिंग्स बन जाएगी।

चरण 3: Codex शुरू करें और स्थिति देखें

codex

सत्र में प्रवेश करने के बाद चलाएं:

/status

अपेक्षित परिणाम: स्थिति विवरण में आपको वही मॉडल और सेटिंग्स दिखाई देंगी जो आपने फ़ाइल में लिखी थीं।

चरण 4: -c का उपयोग करके अस्थायी रूप से सेटिंग बदलें

सत्र से बाहर आएं, और वेब सर्च को लाइव करने के लिए चलाएं:

codex -c web_search='"live"'

सत्र में जाकर दुबारा /status चलाएं।

अपेक्षित परिणाम: इस सत्र के लिए वेब सर्च live दिखाई देगी, लेकिन फ़ाइल में लिखी गई web_search = "cached" सेटिंग नहीं बदलेगी। सत्र से बाहर आकर सामान्य रूप से शुरू करने पर यह फिर से cached हो जाएगी। यह अस्थायी बदलाव के नियम की पुष्टि करता है।

चरण 5: एक प्रोफ़ाइल बनाएं और स्विच करके देखें

एक नई फ़ाइल ~/.codex/quick.config.toml बनाएं (केवल भिन्न सेटिंग्स लिखें):

# ~/.codex/quick.config.toml
model = "gpt-5.5"
sandbox_mode = "read-only"
approval_policy = "untrusted"

इसे उपयोग करके स्टार्टअप करें:

codex --profile quick

सत्र में जाकर /status से पुष्टि करें।

अपेक्षित परिणाम: इस सत्र के लिए सुरक्षा अनुमतियाँ अधिक सख्त (रीड-ओनली और untrusted) दिखाई देंगी क्योंकि प्रोफ़ाइल सेटिंग्स लागू हो गई हैं। यह प्रोफ़ाइल स्विच करने के नियम की पुष्टि करता है। सामान्य रूप से शुरू करने पर फिर से ग्लोबल सेटिंग्स लागू होंगी।

इस प्रकार आपने कॉन्फ़िगरेशन फ़ाइल लिखने, स्थिति जाँचने, अस्थायी रूप से बदलने और प्रोफ़ाइल स्विच करने की पूरी प्रक्रिया को व्यावहारिक रूप से समझ लिया है।

💡 संक्षेप में: अभ्यास के चरण हैं—ग्लोबल फ़ाइल लिखना → /status द्वारा जाँच → -c द्वारा अस्थायी बदलाव → --profile द्वारा प्रोफ़ाइल बदलना।

---

08 सारांश

इस लेख में हमने Codex की मुख्य कॉन्फ़िगरेशन फ़ाइल config.toml को समझा है—कि यह कहाँ होती है, प्राथमिकता का नियम क्या है, संवेदनशील सेटिंग्स की सीमाएँ क्या हैं और इसे कैसे उपयोग किया जाता है।

मुख्य बिंदुओं का सारांश:

विषय	विवरण	मुख्य बिंदु
AGENTS.md से अंतर	दो अलग चीजें	AGENTS.md "क्या याद रखना है" के लिए है, और config.toml "काम कैसे करना है" के लिए है
फ़ाइल के स्थान	दो स्थान	उपयोगकर्ता स्तर ~/.codex/config.toml और प्रोजेक्ट स्तर <repo>/.codex/config.toml
प्राथमिकता	विशिष्टता के अनुसार	कमांड लाइन > प्रोजेक्ट > प्रोफ़ाइल > उपयोगकर्ता > सिस्टम > डिफ़ॉल्ट
सुरक्षा सीमा	प्रोजेक्ट स्तर पर प्रतिबंध	model_provider, notify, otel जैसी सेटिंग्स केवल उपयोगकर्ता स्तर पर काम करती हैं
मुख्य सेटिंग्स	अक्सर उपयोग होने वाली	model, approval_policy, sandbox_mode, web_search (डिफ़ॉल्ट रूप से कैश), [features]
बदलाव	अस्थायी और समूह	-c द्वारा अस्थायी बदलाव, और --profile द्वारा प्रोफ़ाइल स्विच करना

अब आप यह कर सकते हैं: config.toml और AGENTS.md में अंतर बताना; फ़ाइल को होम डायरेक्टरी या प्रोजेक्ट में लिखने के नियम को समझना; प्राथमिकता के नियमों और सुरक्षा सीमाओं को जानना; मुख्य सेटिंग्स और उनके डिफ़ॉल्ट मानों को याद रखना; और अस्थायी परिवर्तनों तथा प्रोफ़ाइलों का उपयोग करना। यह समझ आपको Codex को अपनी आवश्यकताओं के अनुसार व्यवस्थित करने में मदद करती है।

बार-बार एक ही प्रकार की कमांड चलाने के बजाय, आवश्यक सेटिंग्स को कॉन्फ़िगरेशन फ़ाइल में सहेजें ताकि स्टार्टअप पर वे सीधे लागू हो सकें।

---

अगला लेख 19 "स्मरण शक्ति तंत्र (Memories और Chronicle)"—इस लेख में आपने [features] में डिफ़ॉल्ट रूप से बंद memories स्विच देखा था। अगले लेख में हम इस स्मरण शक्ति तंत्र को विस्तार से समझेंगे: कि कैसे Codex आपकी आदतों और प्रोजेक्ट के संदर्भों को याद रखता है, जिससे यह आपके काम को बेहतर ढंग से समझ सकता है। एक सवाल: पिछले लेख में हमने इसे "देखने की क्षमता" दी, और इस लेख में "याद रखने की क्षमता"—ये दोनों इसे आपके काम में कितना सहायक बनाते हैं?

---

अनुशंसित पठन

• Codex ट्यूटोरियल
• Worktrees समानांतर काम: विभिन्न कार्यों को अलग रखकर एक साथ चलाना
• Codex मुख्य अवधारणाएँ