गैर-इंटरैक्टिव मोड codex exec: इसे स्क्रिप्ट और CI में चलाना
📚 सीरीज नेविगेशन: पिछला लेख [27 स्वचालन और CI/CD] आपको CI पाइपलाइन में Codex का उपयोग करने का ढांचा और विवरण समझाता है। यह लेख उस स्वचालन इंजन की मुख्य कमांड—
codex exec—को गहराई से समझाता है, जो बिना किसी चैट इंटरफ़ेस के केवल निर्देश देने पर स्वतः काम करके सत्र समाप्त कर देती है। अगला लेख [29 Slack / Linear और SDK इंटीग्रेशन] यह समझाएगा कि कैसे Codex को चैट ऐप्स (Slack) और टास्क मैनेजमेंट सिस्टम (Linear) से जोड़कर सीधे काम लिया जाए।
दोस्तों, आज हम एक ऐसी कमांड के बारे में बात करेंगे जिसका आप स्क्रिप्ट्स और स्वचालन में सबसे अधिक उपयोग करेंगे—codex exec।
हमने कोडिंग CLI (लेख 08) में इसका संक्षिप्त विवरण देखा था, जहाँ इसे "होम डिलीवरी" की तरह बताया गया था: आप केवल ऑर्डर (निर्देश) देते हैं, और पृष्ठभूमि में काम पूरा होकर सीधे परिणाम मिल जाता है, आपको वहाँ उपस्थित रहने की आवश्यकता नहीं होती। इस लेख में हम इसकी आंतरिक सेटिंग्स और विवरणों को समझेंगे ताकि आप इसका उपयोग कस्टमाइज़्ड स्क्रिप्ट्स में कर सकें।
हमें इसे अलग से समझने की आवश्यकता क्यों है? क्योंकि सामान्य इंटरैक्टिव मोड (जहाँ आप codex कमांड चलाकर चैट स्क्रीन खोलते हैं) का एक बड़ा नियम है: यह मानता है कि मशीन के सामने कोई व्यक्ति उपलब्ध है—जो निर्देश दे रहा है, अनुमतियों के पॉप-अप को स्वीकृत कर रहा है, और परिणाम देख रहा है। लेकिन जब आप "दैनिक सुबह स्वचालित रूप से रिपोर्ट तैयार करना", "CI विफल होने पर स्वतः फिक्स करना", या "लॉग्स को पढ़कर समरी तैयार करना" जैसे कार्यों को स्वचालित करना चाहते हैं—तो वहाँ मशीन के सामने कोई व्यक्ति नहीं होता। ऐसे समय में इंटरैक्टिव मोड क्रेडेंशियल्स अनुमोदन के पॉप-अप पर ही अटका रहेगा। codex exec का जन्म इसी समस्या को हल करने के लिए हुआ है।
सरल शब्दों में, codex exec को ठीक से समझना आपको Codex को केवल एक उपकरण की तरह उपयोग करने से ऊपर उठाकर, उसे अपने कोडिंग वर्कफ़्लो के एक स्वचालित पुर्जे के रूप में एकीकृत करने की क्षमता देता है।
इस लेख को पढ़ने के बाद, आपको मिलेगा:
codex execऔर सामान्य चैट मोड में क्या मुख्य अंतर है, और यह किन "बिना यूज़र वाली" स्थितियों के लिए सबसे उपयुक्त है।- इसका मुख्य डिज़ाइन: प्रोसेसिंग विवरण stderr पाइप में और अंतिम परिणाम stdout पाइप में जाता है—डेटा प्रवाह का यह अलगाव क्यों उपयोगी है।
--json(मशीन रीडेबल लॉग्स) और-o/--output-last-message(अंतिम परिणाम फ़ाइल में सहेजना) का एक साथ उपयोग।- गैर-इंटरैक्टिव मोड में सैंडबॉक्स डिफ़ॉल्ट रूप से read-only होता है, बदलाव के लिए इसे सक्षम करने के नियम।
- stdin पाइप के दो मुख्य तरीके: निर्देश के साथ डेटा पास करना, या पूरे निर्देश के रूप में stdin का उपयोग करना (
codex exec -)। - व्यावहारिक अभ्यास: एक सरल कोडिंग निर्देश चलाना, परिणाम फ़ाइल में सहेजना, और शेल लूप में इसका उपयोग करना।
⚠️ इस लेख में वर्णित कमांड विकल्प Codex आधिकारिक दस्तावेज़ों (noninteractive) पर आधारित हैं।
01 गैर-इंटरैक्टिव मोड का महत्व
निष्कर्ष: codex exec का उपयोग तब किया जाता है जब कोडिंग के समय यूज़र इंटरफ़ेस में इनपुट देने के लिए कोई व्यक्ति उपलब्ध नहीं होता—जैसे CI पाइपलाइन या टाइमर आधारित स्क्रिप्ट्स में, जहाँ कोड स्वतः निष्पादित होना चाहिए और परिणाम अगले प्रोग्राम को पास होना चाहिए।
इंटरैक्टिव मोड के लिए आपकी उपस्थिति आवश्यक होती है। जबकि निम्नलिखित तीन क्षेत्रों में स्वचालन आवश्यक है:
1. नियमित और बार-बार होने वाले कोडिंग कार्य: जैसे "पिछले 10 कमिट्स को पढ़कर समरी रिपोर्ट तैयार करना"। यह नियमबद्ध कार्य है, और आप इसे रोज़ मैन्युअल रूप से नहीं करना चाहेंगे।
2. बिना विज़ुअल टर्मिनल वाले सर्वर वातावरण: जैसे CI/CD रनर, क्लाउड सर्वर या Docker कंटेनर, जहाँ विज़ुअल चैट स्क्रीन खोलने की कोई सुविधा नहीं होती।
3. आउटपुट को अगले प्रोग्राम में इनपुट के रूप में भेजना: जैसे लॉग्स की समरी तैयार करके उसे सीधे Git PR कमेंट में पोस्ट करना। इसके लिए परिणाम का फ़ॉर्मेट साफ़ होना आवश्यक है, जिसमें चैट का इतिहास न हो।
自动售货机 (वेंडिंग मशीन) और होटल काउंटर से तुलना। इंटरैक्टिव मोड होटल काउंटर की तरह है—जहाँ वेटर आपके निर्देशों के अनुसार ऑर्डर तैयार करता है और बीच में राय ले सकता है। codex exec वेंडिंग मशीन की तरह है—आप बटन दबाते हैं (कमांड रन करते हैं), मशीन स्वतः प्रोसेसिंग करती है, और उत्पाद सीधे बाहर आ जाता है (stdout पर परिणाम), वहाँ कोई वेटर नहीं होता और न ही कोई आपसे दुबारा पूछता है। यह स्वचालन के लिए सर्वश्रेष्ठ है।
इसके सामान्य उपयोग:
- "CI एरर होने पर स्वतः कोड की जाँच करना और पैच तैयार करना"—पूरी तरह स्वचालित।
- "दैनिक कमिट इतिहास से रिलीज़ नोट्स तैयार करना"—स्क्रिप्ट द्वारा स्वचालित।
- "त्रुटि लॉग्स को इसके पास भेजकर त्वरित समाधान प्राप्त करना"—बिना कॉपी-पेस्ट किए सीधे टर्मिनल कमांड द्वारा।
💡 संक्षेप में:
codex execका उपयोग "बिना यूज़र वाले" कोडिंग कार्यों, सर्वर वातावरण और आउटपुट को अगले टूल्स में भेजने के लिए किया जाता है; यह पृष्ठभूमि स्वचालन का आधार है।
02 बुनियादी उपयोग
codex exec का बुनियादी रूप बहुत सरल है—कमांड के बाद डबल कोट में अपना निर्देश लिखें, और रन करें:
codex exec "इस रिपोजिटरी के ढांचे को संक्षेप में समझाएं"यह निर्देशिका को पढ़ेगा, योजना बनाएगा, और अंत में परिणाम को स्क्रीन पर प्रिंट करके सत्र स्वतः बंद कर देगा—बिना यूज़र से कोई सवाल पूछे।
तुलना: टास्क ईमेल भेजने से। इंटरैक्टिव मोड फोन कॉल की तरह है जहाँ बातचीत जारी रहती है। codex exec ईमेल भेजने के समान है—आप अपनी सभी आवश्यकताएं एक बार में लिखकर भेज देते हैं, और प्राप्तकर्ता काम पूरा करके रिपोर्ट वापस भेज देता है। आप बीच में बदलाव नहीं कर सकते, इसलिए निर्देश स्पष्ट होना चाहिए।
इसके कुछ कोडिंग रूप:
# शार्ट नाम codex e का उपयोग (codex exec के समान)
codex e "समझाएं कि यह प्रोजेक्ट किस बारे में है"# इस बार की कोडिंग के लिए विशिष्ट मॉडल का उपयोग
codex exec -m gpt-5.5 "वर्तमान बदलावों की समीक्षा करें"# बातचीत का इतिहास स्थानीय डिस्क पर न सहेजने के लिए --ephemeral फ़्लैग
codex exec --ephemeral "त्वरित कोडिंग सलाह दें"सबसे महत्वपूर्ण अंतर: चैट मोड में Codex बदलाव करने से पहले अनुमोदन माँगता है; जबकि codex exec में वह अनुमोदन के लिए नहीं रुकता। वह सीधे काम करता है, इसलिए सुरक्षा के लिए सैंडबॉक्स अनुमतियों का ध्यान रखें (धारा 04)।
⚠️ Git रिपोजिटरी नियम: Codex कमांड्स को केवल Git रिपोजिटरी के भीतर ही चलाने की अनुमति देता है (ताकि अनजाने में बिना वर्शन कंट्रोल वाले कोड का नुकसान न हो)। इसे बायपास करने के लिए आप
--skip-git-repo-checkफ़्लैग का उपयोग कर सकते हैं, लेकिन आधिकारिक चेतावनी के अनुसार ऐसा केवल पूरी तरह सुरक्षित वातावरण में ही करें।
💡 संक्षेप में:
codex exec "instruction"का उपयोग बिना विज़ुअल चैट के सीधे कोडिंग करने के लिए किया जाता है; यह अनुमोदन के लिए नहीं रुकता; और यह केवल Git रिपोजिटरी के भीतर ही काम करता है (बायपास के लिए--skip-git-repo-checkका उपयोग करें)।
03 डेटा प्रवाह का अलगाव: stderr और stdout
यह codex exec की कोडिंग स्क्रिप्ट्स में सबसे उपयोगी विशेषता है।
जब Codex काम करता है, तो वह कई विवरण दिखाता है—जैसे वह क्या सोच रहा है, कौन सी फ़ाइल पढ़ रहा है आदि। लेकिन कोडिंग स्क्रिप्ट को केवल अंतिम परिणाम की आवश्यकता होती है। यदि सभी विवरण आपस में मिल जाएंगे, तो परिणाम को पढ़ना मुश्किल हो जाएगा।
Codex इसके लिए दो स्वतंत्र आउटपुट पाइप का उपयोग करता है:
कार्य प्रगति के विवरण
stderr(Standard Error) पाइप पर भेजे जाते हैं, और अंतिम परिणामstdout(Standard Output) पाइप पर भेजा जाता है।
शेल में > या पाइप | डिफ़ॉल्ट रूप से केवल stdout के डेटा को प्राप्त करते हैं। इसलिए अंतिम परिणाम को फ़िल्टर करना बहुत आसान हो जाता है।
तुलना: कंस्ट्रक्शन साइट पर शोर और तैयार बिल्डिंग से। बिल्डिंग बनने के दौरान धूल उड़ती है और शोर होता है (यह stderr है, जो आवश्यक है लेकिन अंतिम उत्पाद नहीं है)। काम पूरा होने पर आपको साफ़-सुथरी बिल्डिंग मिलती है (यह stdout है)। दोनों का मार्ग अलग होने से आपको साफ़ परिणाम मिलता है।
उदाहरण: परिणाम को फ़ाइल में सहेजना (प्रगति विवरण स्क्रीन पर दिखाई देंगे लेकिन फ़ाइल में नहीं जाएंगे):
codex exec "पिछले कमिट्स की समरी तैयार करें" | tee release-notes.mdअपेक्षित परिणाम: स्क्रीन पर आपको काम की प्रगति (stderr) दिखाई देगी, और release-notes.md में केवल साफ़ कोडिंग रिपोर्ट सहेजी जाएगी।
शेल नियंत्रण के अन्य तरीके:
| कार्य | शेल कमांड | विवरण |
|---|---|---|
| केवल अंतिम परिणाम फ़ाइल में सहेजना | codex exec "..." > out.md | stderr स्क्रीन पर दिखेगा, out.md में केवल परिणाम जाएगा |
| परिणाम सहेजना और स्क्रीन पर देखना | codex exec "..." | tee out.md | tee टूल दोनों काम करता है |
| परिणाम क्लिपबोर्ड पर कॉपी करना | codex exec "..." | pbcopy | क्लिपबोर्ड पर केवल परिणाम कॉपी होगा |
| प्रगति लॉग्स भी सहेजना | codex exec "..." > out.md 2> log.txt | 2> stderr को log.txt में सहेजता है |
सुरक्षा चेतावनी: शेल में 2>&1 का उपयोग करने से stderr और stdout आपस में मिल जाते हैं, जिससे स्क्रिप्ट को परिणाम पार्स करने में एरर आ सकता है। इसका उपयोग करने से बचें।
💡 संक्षेप में:
codex execप्रोसेसिंग विवरणों को stderr पर और अंतिम परिणाम को stdout पर भेजता है; जिससे पाइप|और रिडायरेक्शन>स्वतः ही केवल साफ़ परिणाम को प्राप्त करते हैं।
04 सुरक्षा सेटिंग्स: गैर-इंटरैक्टिव मोड डिफ़ॉल्ट रूप से "Read-Only" होता है
सुरक्षा की दृष्टि से एक महत्वपूर्ण डिफ़ॉल्ट नियम:
गैर-इंटरैक्टिव मोड में
codex execडिफ़ॉल्ट रूप से read-only सैंडबॉक्स में काम करता है।
इसका अर्थ है कि वह कोड पढ़ सकता है, विश्लेषण कर सकता है, लेकिन डिफ़ॉल्ट रूप से फ़ाइलों को संपादित नहीं कर सकता और न ही नेटवर्क कमांड चला सकता है। बदलाव के लिए आपको अनुमतियाँ देनी होंगी।
चूँकि इस मोड में कोई कोडर अनुमोदन देने के लिए उपलब्ध नहीं होता, इसलिए सुरक्षा सुनिश्चित करने के लिए यह कड़ा नियम लागू किया गया है।
तुलना: मैकेनिक को घर की चाबी देने से। यदि आप घर पर नहीं हैं और मैकेनिक को काम के लिए चाबी देते हैं, तो आप उसे केवल उस रूम की चाबी देते हैं जहाँ काम करना है (Minimal Permissions), न कि पूरे घर की तिजोरी की।
सैंडबॉक्स अनुमतियों के स्तर (--sandbox या -s फ़्लैग):
| सैंडबॉक्स स्तर | अनुमतियाँ | उपयोग का समय |
|---|---|---|
read-only (डिफ़ॉल्ट) | केवल पढ़ने की अनुमति, फ़ाइल संपादन प्रतिबंधित | कोड समीक्षा, रिपोर्ट तैयार करना |
workspace-write | प्रोजेक्ट निर्देशिका के भीतर फ़ाइल संपादन की अनुमति | बग फिक्स करना, कोड फ़ॉर्मेट करना |
danger-full-access | मशीन पर पूर्ण अधिकार (कोई प्रतिबंध नहीं) | केवल पूरी तरह पृथक CI रनर या सुरक्षित कंटेनर में |
कमांड उदाहरण:
# डिफ़ॉल्ट read-only: केवल रिपोर्ट देगा, फ़ाइलें सुरक्षित रहेंगी
codex exec "कोड की समीक्षा करें"# बदलाव की अनुमति: प्रोजेक्ट के भीतर कोड सुधारेगा
codex exec --sandbox workspace-write "टेस्ट एरर को ठीक करें"# पूर्ण अनुमति: केवल पृथक रनर पर ही उपयोग करें
codex exec --sandbox danger-full-access "सिस्टम डिपेंडेंसी अपडेट करें"सुरक्षा सावधानियाँ:
- पुराना विकल्प
--full-autoअब समर्थित नहीं है; सैंडबॉक्स अनुमतियों के लिए हमेशा--sandbox workspace-writeका उपयोग करें। - कड़े स्वचालन के लिए आप
--ignore-user-config(स्थानीय config फ़ाइलें लोड न करना) और--ignore-rules(सुरक्षा नीतियों की जाँच को बायपास करना) का उपयोग कर सकते हैं ताकि विभिन्न मशीनों पर Action का व्यवहार एक जैसा रहे।
💡 संक्षेप में: गैर-इंटरैक्टिव मोड डिफ़ॉल्ट रूप से read-only होता है; कोड बदलने के लिए हमेशा
--sandbox workspace-writeका उपयोग करें; औरdanger-full-accessका उपयोग केवल पृथक सर्वर पर ही करें।
05 मशीन रीडेबल आउटपुट: --json और -o का उपयोग
यदि कोडिंग स्क्रिप्ट को परिणाम को पार्स करना है, तो सामान्य टेक्स्ट की तुलना में JSON फॉर्मेट अधिक उपयुक्त होता है। Codex इसके लिए दो विकल्प प्रदान करता है:
1. --json (लॉग इवेंट्स प्राप्त करना): इसके द्वारा stdout पर सामान्य टेक्स्ट के स्थान पर JSON Lines (JSONL - प्रत्येक लाइन एक स्वतंत्र JSON ऑब्जेक्ट) प्रारूप में घटनाक्रम प्राप्त होता है।
तुलना: लाइव वीडियो देखने के स्थान पर इवेंट लॉग्स सूची प्राप्त करने से। इसमें प्रत्येक गतिविधि (जैसे फ़ाइल खोलना, कमांड रन करना) की टाइमस्टैम्प के साथ एंट्री होती है।
कमांड उदाहरण:
codex exec --json "प्रोजेक्ट की जाँच करें" | jqआउटपुट फॉर्मेट:
{"type":"thread.started","thread_id":"0199a213-81c0-7800-8aa1-bbab2a035a53"}
{"type":"turn.started"}
{"type":"item.completed","item":{"id":"item_3","type":"agent_message","text":"प्रोजेक्ट में तीन मुख्य निर्देशिकाएं हैं।"}}
{"type":"turn.completed","usage":{"input_tokens":24763,"output_tokens":122}}स्क्रिप्ट्स के लिए इस फॉर्मेट को पढ़ना और त्रुटियों की जाँच करना बहुत आसान होता है।
2. -o या --output-last-message (केवल परिणाम सहेजना): यदि आप प्रोसेसिंग लॉग्स नहीं चाहते और केवल अंतिम कोडिंग उत्तर को फ़ाइल में सहेजना चाहते हैं, तो इस विकल्प का उपयोग करें:
codex exec "प्रोजेक्ट समरी लिखें" -o ./summary.mdयह परिणाम को फ़ाइल में भी लिखेगा और stdout पर भी प्रिंट करेगा ताकि पाइप चेन टूटे नहीं।
दोनों विकल्पों का उपयोग:
| लक्ष्य | विकल्प | विवरण |
|---|---|---|
| स्क्रिप्ट द्वारा घटनाओं का विश्लेषण | --json | stdout JSONL प्रारूप में बदल जाता है |
| अंतिम परिणाम फ़ाइल में सहेजना | -o <path> | परिणाम फ़ाइल में जाता है और stdout पर भी रहता है |
| CI पाइपलाइन के लिए दोनों आवश्यक | --json और -o दोनों | लॉग्स स्क्रिप्ट के लिए और परिणाम फ़ाइल रिपोर्ट के लिए |
💡 संक्षेप में:
--jsonआउटपुट को JSONL प्रारूप में बदलता है जिससे कोडिंग स्क्रिप्ट्स के लिए इसे पढ़ना आसान हो जाता है, और-oअंतिम परिणाम को सीधे फ़ाइल में लिखता है; स्वचालन में दोनों का एक साथ उपयोग किया जाता है।
06 stdin पाइप द्वारा डेटा इनपुट देना
हमने आउटपुट पाइप देखा, अब इनपुट का मार्ग समझते हैं: पिछले टूल के आउटपुट को codex exec में इनपुट के रूप में कैसे भेजें?
यह तब उपयोगी होता है जब आपके पास पहले से कोई डेटा (जैसे त्रुटि लॉग या JSON आउटपुट) हो और आप उस पर Codex से काम कराना चाहते हैं।
इसके दो मुख्य तरीके हैं:
तुलना: सहायक को काम सौंपने के दो तरीकों से। पहला, जहाँ आप निर्देश देते हैं "इस दस्तावेज़ की त्रुटियाँ ठीक करें" और साथ में दस्तावेज़ पकड़ाते हैं—निर्देश आपके पास है और दस्तावेज़ इनपुट है (निर्देश + पाइप)। दूसरा, जहाँ आप उसे एक लिखित पत्र देते हैं जिस पर काम और डेटा दोनों लिखे हैं और कहते हैं "इसे पढ़ें और करें"—काम और डेटा दोनों इनपुट में हैं (codex exec -).
तरीका 1: निर्देश + इनपुट पाइप (डेटा को संदर्भ के रूप में देना)
यदि निर्देश आप स्वयं लिख रहे हैं और केवल डेटा को इनपुट के रूप में पास कर रहे हैं:
यदि stdin पाइप द्वारा इनपुट आ रहा है और साथ में निर्देश (prompt) दिया गया है, तो Codex निर्देश को कार्य मानेगा और पाइप डेटा को कोडिंग संदर्भ (Context)।
उदाहरण के लिए, टेस्ट एरर लॉग्स को सीधे Codex को भेजना:
npm test 2>&1 \
| codex exec "इस टेस्ट एरर का समाधान बताएं" \
| tee test-summary.mdयह एरर लॉग को पढ़कर समाधान तैयार कर देगा, बिना कॉपी-पेस्ट किए।
या किसी लॉग फ़ाइल का विश्लेषण करना:
tail -n 200 app.log \
| codex exec "इस त्रुटि का मुख्य कारण बताएं" \
> log-triage.mdतरीका 2: codex exec - (stdin ही निर्देश है)
यदि निर्देश और डेटा दोनों पहले से एक फ़ाइल या स्क्रिप्ट आउटपुट में लिखे हैं और आप उन्हें सीधे रन करना चाहते हैं। इसके लिए - सिंबल का उपयोग किया जाता है:
# फ़ाइल में लिखे निर्देशों को सीधे रन करना
cat prompt.txt | codex exec -# शेल स्क्रिप्ट द्वारा निर्देश तैयार करके भेजना
printf "इस कोड में त्रुटि खोजें:\n\n%s\n" "$(cat app.py)" \
| codex exec -यह निर्देशों को फ़ाइल (Templates) में लिखकर सहेजने और स्क्रिप्ट्स द्वारा उपयोग करने के लिए बहुत उपयोगी है।
💡 संक्षेप में: इनपुट के लिए—यदि निर्देश आप लिख रहे हैं तो सामान्य पाइप का उपयोग करें (पाइप डेटा संदर्भ बन जाएगा); और यदि निर्देश पहले से इनपुट में लिखे हैं तो
codex exec -का उपयोग करें।
07 सत्र जारी रखना: codex exec resume
गैर-इंटरैक्टिव मोड में भी आप पिछले सत्र के काम को आगे बढ़ा सकते हैं—जैसे पहले चरण में विश्लेषण करना, और दूसरे में सुधार करना। इसके लिए resume कमांड का उपयोग किया जाता है।
तुलना: रिले रेस (Relay Race) में बैटन ट्रांसफर से। धावक जहाँ दौड़ समाप्त करता है, अगला वहीं से शुरू करता है—शुरुआत से दौड़ने की आवश्यकता नहीं होती।
उदाहरण:
# चरण 1: कोड में सुरक्षा खामियों की जाँच करना
codex exec "इस कोड में सुरक्षा खामियाँ खोजें"
# चरण 2: पिछले सत्र के निष्कर्षों के आधार पर कोड ठीक करना
codex exec resume --last "खोजी गई सुरक्षा खामियों को ठीक करें"--last का अर्थ वर्तमान निर्देशिका में हाल ही में चले सत्र से है। विशिष्ट सत्र से जोड़ने के लिए सत्र आईडी पास करें:
codex exec resume <SESSION_ID> "काम जारी रखें"ध्यान रखें कि यदि आपने पहले चरण में --ephemeral (इतिहास न सहेजना) फ़्लैग का उपयोग किया था, तो आप उसे resume नहीं कर पाएंगे क्योंकि उसका इतिहास डिस्क पर उपलब्ध नहीं होगा।
💡 संक्षेप में:
codex exec resume --lastपिछले सत्र के इतिहास को लोड करके काम आगे बढ़ाता है; यह बहु-चरण कोडिंग कार्यों के लिए उपयोगी है।
08 अभ्यास: गैर-इंटरैक्टिव कमांड्स का परीक्षण
आइए स्थानीय टर्मिनल पर इन कमांड्स को चलाकर इनका अभ्यास करें। इसके लिए एक Git प्रोजेक्ट फ़ोल्डर की आवश्यकता होगी।
चरण 1: एक बुनियादी निर्देश रन करें
codex exec "इस प्रोजेक्ट की मुख्य भाषा कौन सी है"अपेक्षित परिणाम: यह प्रोजेक्ट फ़ाइलों की जाँच करेगा, और उत्तर देकर टर्मिनल पर वापस आ जाएगा।
चरण 2: रिडायरेक्शन की जाँच करें (stdout और stderr)
codex exec "इस प्रोजेक्ट की मुख्य भाषा कौन सी है" > output.txtअपेक्षित परिणाम: स्क्रीन पर आपको प्रोसेसिंग प्रोग्रेस (stderr) दिखाई देगी, और output.txt में केवल एक लाइन का उत्तर सहेजा जाएगा।
चरण 3: JSONL आउटपुट प्राप्त करें
codex exec --json "इस प्रोजेक्ट की फ़ाइलें दिखाएं"अपेक्षित परिणाम: स्क्रीन पर सामान्य उत्तर के स्थान पर JSON लाइनों की सूची दिखाई देगी।
चरण 4: परिणाम फ़ाइल में सहेजें
codex exec "इस प्रोजेक्ट की फ़ाइलें दिखाएं" -o files.mdअपेक्षित परिणाम: परिणाम स्क्रीन पर भी प्रिंट होगा और files.md में भी सहेजा जाएगा।
चरण 5: शेल लूप में स्वचालन
सभी markdown फ़ाइलों की समरी तैयार करने का शेल लूप (Windows पर Git Bash का उपयोग करें):
for f in *.md; do
echo "--- File: $f ---"
codex exec --ignore-user-config "इस फ़ाइल $f का एक वाक्य में विवरण दें"
doneअपेक्षित परिणाम: यह प्रत्येक फ़ाइल के लिए बारी-बारी से Codex चलाकर विवरण प्रिंट करेगा। यह बिना मानवीय हस्तक्षेप के काम करता है।
अभ्यास के बाद बनाई गई टेस्ट फ़ाइलें डिलीट कर दें।
💡 संक्षेप में: अभ्यास के चरण हैं—सरल कमांड रन करना → रिडायरेक्शन की जाँच → JSON आउटपुट देखना →
-oका उपयोग → शेल लूप में स्वचालन परीक्षण।
09 सारांश
इस लेख में हमने गैर-इंटरैक्टिव मोड codex exec को गहराई से समझा है।
मुख्य बिंदुओं का सारांश:
| कार्य | कमांड विकल्प | मुख्य बिंदु |
|---|---|---|
| कमांड रन करना | codex exec "..." | बिना विज़ुअल चैट के रन होता है; क्रेडेंशियल्स अनुमोदन के लिए नहीं रुकता |
| परिणाम फ़िल्टर | stdout / stderr | प्रोग्रेस विवरण stderr पर और उत्तर stdout पर जाता है |
| फ़ाइल संपादन | --sandbox workspace-write | डिफ़ॉल्ट रूप से read-only होता है, बदलाव के लिए इसे सक्षम करना आवश्यक है |
| JSON इवेंट्स | --json | उत्तर को मशीन रीडेबल JSONL प्रारूप में बदलता है |
| परिणाम सहेजना | -o <path> | अंतिम परिणाम को फ़ाइल में लिखता है |
| इनपुट पाइप | codex exec - | पिछले कमांड के आउटपुट को निर्देश के रूप में ग्रहण करना |
| सत्र रीस्टार्ट | codex exec resume --last | पिछले सत्र के काम को आगे बढ़ाना |
अब आप यह कर सकते हैं: गैर-इंटरैक्टिव मोड के महत्व को समझाना, डेटा पाइप्स का सही उपयोग करना, सैंडबॉक्स सेटिंग्स कॉन्फ़िगर करना, JSONL आउटपुट प्राप्त करना, इनपुट पाइप्स का उपयोग करना, और सत्र जारी रखना।
अगला लेख [29 Slack / Linear और SDK इंटीग्रेशन]—इस लेख में हमने स्क्रिप्ट्स में Codex के उपयोग की बात की। अगले लेख में हम देखेंगे कि कैसे Codex को चैट ऐप Slack और टास्क मैनेजर Linear से जोड़कर सीधे काम लिया जाता है, और प्रोग्रामिंग कोड में SDK का उपयोग कैसे किया जाता है।