4 फ़रवरी 2026

Codex हार्नेस को अनलॉक करना: हमने ऐप सर्वर कैसे बनाया

Celia Chen, तकनीकी स्टाफ की सदस्य

लोड किया जा रहा है...

OpenAI का कोडिंग एजेंट Codex कई अलग-अलग सतहों पर मौजूद है: वेब ऐप⁠(एक नई विंडो में खुलेगा), CLI⁠(एक नई विंडो में खुलेगा), IDE एक्सटेंशन⁠(एक नई विंडो में खुलेगा), और नये Codex macOS ऐप. अंदरूनी तौर पर, ये सभी एक ही Codex हार्नेस द्वारा संचालित होते हैं—वह एजेंट लूप और लॉजिक जो सभी Codex अनुभवों के आधार में है. उनके बीच का महत्वपूर्ण संबंध क्या है? Codex App Server⁠(एक नई विंडो में खुलेगा), एक उपयोगकर्ता-अनुकूल, द्विदिश JSON-RPC¹ API.

इस पोस्ट में, हम Codex App Server के बारे में बताएंगे; हम Codex की क्षमताओं को आपके प्रोडक्ट में लाने के सबसे अच्छे तरीकों के बारे में अब तक की अपनी सीख शेयर करेंगे ताकि आपके यूज़र्स अपने वर्कफ़्लो को सुपरचार्ज कर सकें। हम App Server की आर्किटेक्चर और प्रोटोकॉल को कवर करेंगे और यह विभिन्न Codex सतहों के साथ कैसे एकीकृत होता है, साथ ही Codex का लाभ उठाने के लिए सुझाव भी देंगे, चाहे आप Codex को एक कोड समीक्षक, एक SRE एजेंट, या एक कोडिंग सहायक में बदलना चाहते हों.

App Server की उत्पत्ति

आर्किटेक्चर में गहराई से जाने से पहले, App Server की पृष्ठभूमि जानना सहायक होता है. शुरुआत में, App Server एक व्यावहारिक तरीका था जिससे विभिन्न उत्पादों में Codex harness का पुन: उपयोग किया जा सकता था, जो धीरे-धीरे हमारे मानक प्रोटोकॉल में विकसित हो गया.

Codex CLI की शुरुआत एक TUI (टर्मिनल यूजर इंटरफेस) के रूप में हुई थी, जिसका अर्थ है कि Codex को टर्मिनल के माध्यम से एक्सेस किया जाता है. जब हमने VS कोड एक्सटेंशन (Codex एजेंट के साथ इंटरैक्ट करने का एक ज़्यादा IDE-फ्रेंडली तरीका) बनाया, तो हमें उसी हार्नेस का इस्तेमाल करने का एक तरीका चाहिए था ताकि हम उसे दोबारा बनाए बिना IDE UI से उसी एजेंट लूप को चला सकें। इसका मतलब था request/response से आगे बढ़कर समृद्ध इंटरैक्शन पैटर्न्स का समर्थन करना, जैसे वर्कस्पेस का अन्वेषण करना, एजेंट के तर्क करते समय प्रगति को स्ट्रीम करना, और अंतर निकालना. हमने पहले Codex को MCP सर्वर के रूप में प्रस्तुत करने⁠(एक नई विंडो में खुलेगा) का प्रयास किया, लेकिन VS Code के लिए उपयुक्त तरीके से MCP सेमांटिक्स को बनाए रखना कठिन साबित हुआ. इसके बजाय, हमने एक JSON-RPC प्रोटोकॉल पेश किया जो TUI लूप को प्रतिबिंबित करता था, जो ऐप सर्वर का अनौपचारिक पहला संस्करण⁠(एक नई विंडो में खुलेगा) बन गया. उस समय, हमें यह उम्मीद नहीं थी कि अन्य ग्राहक App Server पर निर्भर होंगे, इसलिए इसे एक स्थिर API के रूप में डिज़ाइन नहीं किया गया था.

अगले कुछ महीनों में जैसे-जैसे Codex का उपयोग बढ़ा, आंतरिक टीमों और बाहरी साझेदारों को अपने उपयोगकर्ताओं के सॉफ़्टवेयर विकास वर्कफ़्लो को तेज़ करने के लिए उसी हार्नेस को अपने उत्पादों में एम्बेड करने की क्षमता चाहिए थी. उदाहरण के लिए, JetBrains और Xcode एक IDE-स्तरीय एजेंट अनुभव चाहते थे, जबकि Codex डेस्कटॉप ऐप को समानांतर में कई Codex एजेंट्स को व्यवस्थित करने की आवश्यकता थी. उन मांगों ने हमें एक ऐसा प्लेटफ़ॉर्म सतह डिज़ाइन करने के लिए प्रेरित किया, जिस पर हमारे उत्पाद और साझेदार इंटीग्रेशन समय के साथ सुरक्षित रूप से निर्भर कर सकें. इसे इंटीग्रेट करना आसान होना चाहिए था और पिछली संगतता भी होनी चाहिए थी, यानी हम मौजूदा क्लाइंट्स को बाधित किए बिना प्रोटोकॉल को विकसित कर सकते थे.

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

Codex हार्नेस के अंदर

सबसे पहले, आइए Codex हार्नेस के अंदर क्या है और Codex App Server इसे क्लाइंट्स को कैसे प्रस्तुत करता है, इस पर ध्यान दें. हमारे पिछले Codex ब्लॉग में, हमने कोर एजेंट लूप का विश्लेषण किया जो उपयोगकर्ता, मॉडल और टूल्स के बीच इंटरैक्शन को व्यवस्थित करता है. यह Codex हार्नेस का मुख्य तर्क है, लेकिन पूरे एजेंट अनुभव में और भी बहुत कुछ शामिल है:

1. थ्रेड लाइफसायकल और स्थायित्व. एक थ्रेड एक उपयोगकर्ता और Codex एजेंट के बीच की बातचीत है. Codex थ्रेड्स बनाता है, उन्हें फिर से शुरू करता है, फोर्क करता है, और आर्काइव करता है, और ईवेंट हिस्ट्री को स्थायी रूप से सहेजता है ताकि क्लाइंट्स फिर से कनेक्ट कर सकें और एक सुसंगत टाइमलाइन प्रस्तुत कर सकें.

2. कॉन्फ़िग और ऑथ. Codex कॉन्फ़िगरेशन लोड करता है, डिफ़ॉल्ट्स को प्रबंधित करता है, और “Sign in with ChatGPT” जैसे प्रमाणीकरण प्रवाह चलाता है, जिसमें क्रेडेंशियल स्थिति भी शामिल होती है.

3. टूल निष्पादन और विस्तार. Codex शेल/फ़ाइल टूल्स को एक सैंडबॉक्स में निष्पादित करता है और MCP सर्वर्स और स्किल्स जैसी इंटीग्रेशन्स को जोड़ता है ताकि वे एक सुसंगत नीति मॉडल के तहत एजेंट लूप में भाग ले सकें.

यहां हमने जिस भी एजेंट लॉजिक का उल्लेख किया है, जिसमें कोर एजेंट लूप भी शामिल है, वह Codex CLI कोडबेस के एक हिस्से में रहता है, जिसे “Codex Core⁠(एक नई विंडो में खुलेगा)” कहा जाता है. Codex कोर एक लाइब्रेरी है जहाँ सभी एजेंट कोड रहते हैं और यह एक रनटाइम भी है जिसे एजेंट लूप चलाने और एक Codex थ्रेड (वार्तालाप) की स्थिरता को प्रबंधित करने के लिए चालू किया जा सकता है.

उपयोगी होने के लिए, Codex हार्नेस को ग्राहकों के लिए सुलभ होना चाहिए. यहीं पर App Server का उपयोग होता है.

“App server process flow” शीर्षक वाला आरेख. एक क्लाइंट JSON-RPC संदेश stdio रीडर को भेजता है, जो अनुरोधों को Codex संदेश प्रोसेसर को भेजता है. प्रोसेसर lookup threads, thread handles, submitted requests, और events/updates के माध्यम से थ्रेड मैनेजर और कोर थ्रेड के साथ इंटरैक्ट करता है, फिर प्रतिक्रियाएँ क्लाइंट को लौटाता है.

App Server क्लाइंट और सर्वर के बीच JSON-RPC प्रोटोकॉल है और यह एक लंबी अवधि तक चलने वाली प्रक्रिया है जो Codex कोर थ्रेड्स को होस्ट करती है. जैसा कि हम ऊपर दिए गए डायग्राम से देख सकते हैं, एक App Server प्रक्रिया के चार मुख्य घटक होते हैं: stdio रीडर, Codex संदेश प्रोसेसर, थ्रेड प्रबंधक, और कोर थ्रेड्स. थ्रेड मैनेजर प्रत्येक थ्रेड के लिए एक कोर सेशन शुरू करता है, और फिर Codex संदेश प्रोसेसर सीधे प्रत्येक कोर सेशन के साथ संवाद करता है ताकि क्लाइंट अनुरोध सबमिट कर सके और अपडेट प्राप्त कर सके.

एक क्लाइंट अनुरोध से कई इवेंट अपडेट्स हो सकते हैं, और ये विस्तृत इवेंट्स हमें App Server पर एक समृद्ध UI बनाने में सक्षम बनाते हैं. इसके अलावा, stdio रीडर और Codex संदेश प्रोसेसर क्लाइंट और Codex कोर थ्रेड्स के बीच अनुवाद परत के रूप में कार्य करते हैं. वे क्लाइंट JSON-RPC अनुरोधों को Codex कोर ऑपरेशंस में अनुवादित करते हैं, Codex कोर की आंतरिक इवेंट स्ट्रीम को सुनते हैं, और फिर उन निम्न-स्तरीय इवेंट्स को स्थिर, UI-रेडी JSON-RPC सूचनाओं के एक छोटे सेट में रूपांतरित करते हैं.

क्लाइंट और App Server के बीच JSON-RPC प्रोटोकॉल पूरी तरह से द्विदिश है. एक सामान्य थ्रेड में एक क्लाइंट अनुरोध और कई सर्वर सूचनाएं होती हैं. इसके अलावा, सर्वर अनुरोध शुरू कर सकता है जब एजेंट को इनपुट की आवश्यकता हो, जैसे अनुमोदन, और फिर क्लाइंट के जवाब देने तक टर्न को रोक सकता है.

वार्तालाप प्रिमिटिव्‍स

अगला, हम बातचीत के मूलभूत तत्वों को विस्तार से समझेंगे, जो App Server प्रोटोकॉल के निर्माण खंड हैं. एजेंट लूप के लिए एक API डिज़ाइन करना चुनौतीपूर्ण है क्योंकि उपयोगकर्ता/एजेंट इंटरैक्शन एक साधारण अनुरोध/प्रतिक्रिया नहीं है. एक यूज़र रिक्वेस्ट एक स्ट्रक्चर्ड सीक्वेंस ऑफ़ एक्शन्स में अनफोल्ड हो सकती है, जिसे क्लाइंट को ईमानदारी से रिप्रेसेंट करने की ज़रूरत होती है: यूज़र का इनपुट, एजेंट की इन्क्रिमेंटल प्रोग्रेस, और रास्ते में बने आर्टिफ़ैक्ट्स (e.g., diffs). उस इंटरैक्शन स्ट्रीम को UIs में आसानी से इंटीग्रेट करने और उसे विभिन्न UIs में मजबूत बनाए रखने के लिए, हमने स्पष्ट सीमाओं और जीवनचक्रों के साथ तीन मुख्य प्रिमिटिव्स पर सहमति बनाई:

1. आइटम: Codex में आइटम इनपुट/आउटपुट की मूलभूत इकाई है. आइटम टाइप किए जाते हैं (उदा., उपयोगकर्ता संदेश, एजेंट संदेश, टूल निष्पादन, अनुमोदन अनुरोध, अंतर) और प्रत्येक का एक स्पष्ट जीवनचक्र होता है:

item/started जब आइटम शुरू होता है
optional item/*/delta इवेंट्स को कंटेंट स्ट्रीम्स के रूप में (स्ट्रीमिंग आइटम प्रकारों के लिए)
item/completed जब आइटम अपने अंतिम पेलोड के साथ पूरा हो जाता है

यह लाइफ़साइकल क्लाइंट्स को started पर तुरंत रेंडरिंग शुरू करने, delta पर इन्क्रिमेंटल अपडेट्स स्ट्रीम करने, और completed पर अंतिम रूप देने की अनुमति देता है.

2. टर्न: एक टर्न यूज़र इनपुट से शुरू होने वाला एजेंट के काम की एक इकाई है. यह तब शुरू होता है जब क्लाइंट कोई इनपुट सबमिट करता है (उदाहरण के लिए, “टेस्ट्स रन करें और फेल्यर्स का सारांश तैयार करें”) और तब समाप्त होता है जब एजेंट उस इनपुट के लिए आउटपुट्स तैयार करना पूरा कर लेता है. एक टर्न में उन आइटम्स की एक सीक्वेंस होती है जो बीच के स्टेप्स और रास्ते में तैयार किए गए आउटपुट्स को दर्शाती है.

3. थ्रेड: थ्रेड यूज़र और एजेंट के बीच चल रहे Codex सेशन के लिए एक टिकाऊ कंटेनर होता है. इसमें कई टर्न शामिल हैं. थ्रेड्स बनाए जा सकते हैं, फिर से शुरू किए जा सकते हैं, फोर्क किए जा सकते हैं, और आर्काइव किए जा सकते हैं. थ्रेड इतिहास को स्थायी रूप से सहेजा जाता है ताकि ग्राहक फिर से कनेक्ट कर सकें और एक सुसंगत टाइमलाइन प्रस्तुत कर सकें.

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

“Client-server protocol message flow: Initialization handshake.” लेबल वाला डायग्राम. एक क्लाइंट clientInfo के साथ सर्वर को एक इनिशियलाइज़ अनुरोध भेजता है. सर्वर “my_client/1.0.” userAgent स्ट्रिंग के साथ एक परिणाम इवेंट भेजता है.

वार्तालाप की शुरुआत में, क्लाइंट और सर्वर को initialize हैंडशेक स्थापित करना होता है. क्लाइंट को किसी भी अन्य मेथड से पहले एक initialize रिक्वेस्ट भेजनी चाहिए, और सर्वर एक प्रतिक्रिया के साथ इसकी पुष्टि करता है. यह सर्वर को अपनी क्षमताएँ प्रदर्शित करने का अवसर देता है और वास्तविक कार्य शुरू होने से पहले दोनों पक्षों को प्रोटोकॉल संस्करण, फीचर फ्लैग्स और डिफ़ॉल्ट्स पर सहमति बनाने की अनुमति देता है. OpenAI के VS Code एक्सटेंशन से एक उदाहरण payload:

JSON

1{
2  "method": "initialize",
3  "id": 0,
4  "params": {
5    "clientInfo": {
6      "name": "codex_vscode",
7      "title": "Codex VS Code Extension",
8      "version": "0.1.0"
9    }
10  }
11}

यह सर्वर द्वारा लौटाया गया है:

JSON

1{
2  "id": 0,
3  "result": {
4    "userAgent": "codex_vscode/0.94.0-alpha.7 (Mac OS 26.2.0; arm64) vscode/2.4.22 (codex_vscode; 0.1.0)"
5  }
6}

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

जब कोई क्लाइंट एक नई रिक्वेस्ट करता है, तो यह पहले एक थ्रेड बनाएगा और फिर एक टर्न बनाएगा. सर्वर प्रगति के लिए सूचनाएं वापस भेजेगा (thread/started और turn/started). यह उन इनपुट्स को भी वापस भेजेगा जिन्हें यह आइटम्स के रूप में रजिस्टर करता है, जैसे यहाँ यूज़र संदेश.

‘क्लाइंट-सर्वर प्रोटोकॉल संदेश प्रवाह: वैकल्पिक अनुमोदन के साथ टूल निष्पादन’ शीर्षक वाला आरेख. टूल कॉल के दौरान, सर्वर item/started को प्रसारित करता है, फिर item/commandExecution/requestApproval को एक कारण (“run tests”) के साथ प्रसारित करता है. क्लाइंट एक अनुमोदन इवेंट (अनुमति/अस्वीकृति) लौटाता है. इसके बाद सर्वर कमांड निष्पादन ("pnpm test") को दिखाते हुए item/completed एमिट करता है.

टूल कॉल्स भी आइटम्स के रूप में क्लाइंट को वापस भेजे जाते हैं. इसके अलावा, सर्वर किसी एक्शन को रन करने से पहले सर्वर रिक्वेस्ट भेजकर क्लाइंट की अप्रूवल माँग सकता है. अनुमोदन तब तक रुका रहेगा जब तक ग्राहक 'अनुमति दें' या 'अस्वीकार करें' में से किसी एक के साथ जवाब नहीं देता. VS Code एक्सटेंशन में अनुमोदन प्रवाह इस प्रकार दिखता है:

डार्क-थीम वाले इंटरफ़ेस में एक अनुमति प्रॉम्प्ट पूछ रहा है, “क्या आप मुझे इस वर्कस्पेस के लिए pnpm test चलाने की अनुमति देना चाहते हैं?” यह विकल्प सूचीबद्ध करता है: 1) हाँ, 2) हाँ और pnpm test से शुरू होने वाले कमांड्स के लिए फिर से न पूछें, और 3) नहीं, नीचे एक सबमिट बटन के साथ.

“Client-server protocol message flow: Streaming एजेंट message flow.” शीर्षक वाला आरेख. सर्वर सहायक संदेश को भागों में स्ट्रीम करता है: item/started, दो agentMessage/delta घटनाएँ (“तीन परीक्षण चलाए.”, “सभी पास हो गए”), फिर आइटम/पूर्ण हुआ. टर्न turn/completed के साथ समाप्त होता है.

अंत में, सर्वर एक एजेंट संदेश भेजता है और फिर turn/completed के साथ टर्न समाप्त करता है. एजेंट संदेश डेल्टा इवेंट्स संदेश के टुकड़ों को तब तक स्ट्रीम करते रहते हैं जब तक कि संदेश item/completed के साथ अंतिम रूप से पूरा नहीं हो जाता.

डायग्राम में दिए गए मैसेज पढ़ने में आसानी के लिए सरल बनाए गए हैं. अगर आप पूरे टर्न का JSON देखना चाहते हैं, तो आप Codex CLI repo से टेस्ट क्लाइंट रन कर सकते हैं:

Bash

1codex debug app-server send-message-v2 "run tests and summarize failures"

क्लाइंट्स के साथ एकीकरण करना

अब, आइए देखें कि विभिन्न क्लाइंट सरफेसेज़ App Server के माध्यम से Codex को कैसे एम्बेड करती हैं. हम तीन पैटर्न कवर करेंगे: लोकल ऐप्स और IDEs, Codex वेब रनटाइम, और TUI.

“Codex हार्नेस के साथ ऐप सर्वर के माध्यम से इंटीग्रेट किए गए Codex क्लाइंट्स” शीर्षक वाला आरेख. फर्स्ट-पार्टी क्लाइंट्स (Codex Desktop App, TUI/CLI, Web Runtime) और थर्ड-पार्टी इंटीग्रेशन्स (JetBrains IDEs, VS Code, Xcode) JSON-RPC कॉल्स के जरिए Codex हार्नेस के साथ संवाद करते हैं.

सभी तीनों में, ट्रांसपोर्ट JSON-RPC stdio (JSONL) पर है. JSON-RPC आपकी पसंद की भाषा में क्लाइंट बाइंडिंग्स बनाना सरल बनाता है. Codex सरफेस और पार्टनर इंटीग्रेशन ने Go, Python, TypeScript, Swift, और Kotlin जैसी भाषाओं में App Server क्लाइंट्स को लागू किया है. TypeScript के लिए, तुम Rust प्रोटोकॉल से सीधे परिभाषाएँ जनरेट कर सकते हो, इसे चलाकर:

Bash

1codex app-server generate-ts

दूसरी भाषाओं के लिए, आप एक JSON स्कीमा बंडल जेनरेट कर सकते हैं और उसे अपने पसंदीदा कोड जेनरेटर में इस तरह डाल सकते हैं:

Bash

1codex app-server generate-json-schema

लोकल ऐप्स और IDEs

VS Code का स्क्रीनशॉट जिसमें Codex एक्सटेंशन चल रहा है. एक Rust टेस्ट फ़ाइल खुली है, और उसके नीचे Codex पैनल केवल fmt और cargo test -p codex-app-server चलाने का वर्णन करता है, यह रिपोर्ट करते हुए कि फ़ॉर्मैटिंग और परीक्षण प्रगति पर हैं और अंतिम पास/फेल परिणाम का इंतज़ार किया जा रहा है.

लोकल क्लाइंट आमतौर पर एक प्लेटफ़ॉर्म-स्पेसिफिक ऐप सर्वर बाइनरी को बंडल करते हैं या फ़ेच करते हैं, उसे एक लॉन्ग-रनिंग चाइल्ड प्रोसेस के तौर पर लॉन्च करते हैं, और JSON-RPC के लिए एक बाईडायरेक्शनल stdio चैनल खुला रखते हैं. हमारे VS Code एक्सटेंशन और डेस्कटॉप ऐप में, उदाहरण के लिए, शिप किया गया आर्टिफैक्ट प्लेटफ़ॉर्म-विशिष्ट Codex बाइनरी को शामिल करता है और इसे एक परीक्षण किए गए संस्करण पर पिन किया जाता है ताकि क्लाइंट हमेशा वही सटीक बिट्स चला सके जिन्हें हमने सत्यापित किया है.

हर एकीकरण बार-बार क्लाइंट अपडेट्स जारी नहीं कर सकता. Xcode जैसे कुछ पार्टनर client को स्थिर रखकर और ज़रूरत पड़ने पर उसे नए App Server binary की ओर पॉइंट करने की अनुमति देकर release cycles को अलग करते हैं. इस तरह वे सर्वर-साइड सुधारों को अपना सकते हैं (जैसे Codex कोर में बेहतर ऑटो-कॉम्पैक्शन या नए समर्थित कॉन्फ़िग कीज़) और क्लाइंट रिलीज़ का इंतज़ार किए बिना बग फिक्सेस जारी कर सकते हैं. ऐप सर्वर का JSON-RPC इंटरफ़ेस पिछली संगतता के लिए डिज़ाइन किया गया है, ताकि पुराने क्लाइंट्स नए सर्वर्स से सुरक्षित रूप से संवाद कर सकें.

Codex web

Codex वेब इंटरफ़ेस का स्क्रीनशॉट जिसमें “Update login success message” शीर्षक वाला एक अपडेट दिखाया गया है. बायाँ पैनल बदलावों, परीक्षणों, और संशोधित फ़ाइलों का सारांश प्रस्तुत करता है, जबकि दायाँ पैनल login.rs के लिए कोड अंतर दिखाता है, जिसमें लॉगिन सफलता संदेश की वाक्य रचना अपडेट की गई है.

Codex Web, Codex हार्नेस का उपयोग करता है, लेकिन इसे कंटेनर वातावरण में चलाता है. एक worker checked-out वर्कस्पेस के साथ एक कंटेनर तैयार करता है, उसके अंदर ऐप सर्वर बाइनरी लॉन्च करता है, और stdio² चैनल पर एक लंबे समय तक चलने वाला JSON-RPC बनाए रखता है. वेब ऐप (यूज़र के ब्राउज़र टैब में चल रहा) HTTP और SSE के माध्यम से Codex बैकएंड से संवाद करता है, जो वर्कर द्वारा उत्पन्न टास्क इवेंट्स को स्ट्रीम करता है. यह ब्राउज़र-साइड UI को हल्का बनाए रखता है, जबकि यह हमें डेस्कटॉप और वेब पर एक समान रनटाइम प्रदान करता है.

क्योंकि वेब सेशन कुछ समय के लिए होते हैं (टैब बंद हो जाते हैं, नेटवर्क ड्रॉप हो जाते हैं), इसलिए वेब ऐप लंबे समय तक चलने वाले कामों के लिए भरोसेमंद सोर्स नहीं हो सकता. सर्वर पर स्थिति और प्रगति बनाए रखने का अर्थ है कि काम तब भी जारी रहता है, भले ही टैब गायब हो जाए. स्ट्रीमिंग प्रोटोकॉल और सेव किए गए थ्रेड सेशन नए सेशन को दोबारा कनेक्ट करना, जहां से छोड़ा था वहीं से शुरू करना, और क्लाइंट में स्टेट को दोबारा बनाए बिना कैच अप करना आसान बनाते हैं.

TUI/Codex CLI

Codex CLI चला रहे एक टर्मिनल का स्क्रीनशॉट. यह मॉडल gpt-5.2-codex के साथ OpenAI Codex बैनर दिखाता है मध्यम, एक यूज़र कमांड “explain app server to me,” और एक “Working” स्थिति. नीचे एक सुझाव दिखाई देता है: “@filename के लिए टेस्ट लिखो,” जिसमें शॉर्टकट के विकल्प होते हैं.

ऐतिहासिक रूप से, TUI एक “native” क्लाइंट था जो एजेंट लूप के साथ उसी प्रक्रिया में चलता था और ऐप-सर्वर प्रोटोकॉल के बजाय सीधे रस्ट कोर प्रकारों से बात करता था. इससे शुरुआती इटरेशन तेज़ हुआ, लेकिन इसने TUI को एक विशेष मामला सतह भी बना दिया.

अब जब App Server मौजूद है, हम इसे उपयोग करने के लिए TUI को पुनर्गठित करने⁠(एक नई विंडो में खुलेगा) की योजना बना रहे हैं ताकि यह किसी अन्य क्लाइंट की तरह कार्य करे: एक App Server चाइल्ड प्रोसेस लॉन्च करे, stdio पर JSON-RPC का उपयोग करे, और वही स्ट्रीमिंग इवेंट्स और अनुमोदन प्रस्तुत करे. यह वर्कफ़्लो को सक्षम बनाता है जहाँ TUI किसी रिमोट मशीन पर चल रहे Codex सर्वर से जुड़ सकता है, जिससे एजेंट कंप्यूट के पास रहता है और लैपटॉप के स्लीप होने या डिस्कनेक्ट होने पर भी काम जारी रखता है, जबकि स्थानीय रूप से लाइव अपडेट और नियंत्रण प्रदान करता है.

सही प्रोटोकॉल का चयन करना

Codex App Server आगे चलकर हमारे द्वारा बनाए रखा जाने वाला प्रथम श्रेणी का इंटीग्रेशन तरीका होगा, लेकिन कुछ अन्य तरीके भी हैं जिनकी कार्यक्षमता सीमित है. डिफ़ॉल्ट रूप से, हम सुझाव देंगे कि ग्राहक Codex के साथ एकीकृत करने के लिए Codex App Server का उपयोग करें, लेकिन विभिन्न एकीकरण विधियों पर विचार करना और उनके लाभ और हानियों को समझना भी महत्वपूर्ण है. नीचे Codex को चलाने के सबसे आम तरीके दिए गए हैं और बताया गया है कि कौन सा तरीका कब सही रहेगा.

JSON-RPC प्रोटोकॉल

Codex को MCP सर्वर के रूप में

codex mcp-server⁠(एक नई विंडो में खुलेगा) चलाओ और किसी भी MCP क्लाइंट से कनेक्ट करो जो stdio सर्वर को सपोर्ट करता हो (जैसे, OpenAI Agents SDK⁠(एक नई विंडो में खुलेगा)). यह एक अच्छा विकल्प है अगर आपके पास पहले से MCP-आधारित वर्कफ़्लो है और आप Codex को एक कॉल करने योग्य टूल के रूप में उपयोग करना चाहते हैं. नुकसान यह है कि आपको केवल वही मिलता है जो MCP उजागर करता है, इसलिए Codex-विशिष्ट इंटरैक्शन जो अधिक समृद्ध सत्र सेमांटिक्स (जैसे, डिफ अपडेट्स) पर निर्भर करते हैं, वे MCP एंडपॉइंट के माध्यम से स्पष्ट रूप से मैप नहीं हो सकते.

क्रॉस-प्रोवाइडर एजेंट हार्नेस प्रोटोकॉल्स

कुछ इकोसिस्टम एक पोर्टेबल इंटरफ़ेस प्रदान करते हैं जो कई मॉडल प्रदाताओं और रनटाइम्स को लक्षित कर सकता है. अगर तुम एक ऐसा एब्स्ट्रैक्शन चाहते हो जो कई एजेंट्स को समन्वयित करे, तो यह एक अच्छा फ़िट हो सकता है. इसका नुकसान यह है कि ये प्रोटोकॉल अक्सर क्षमताओं के कॉमन सबसेट पर कन्वर्ज होते हैं, जिससे ज़्यादा रिच इंटरैक्शन को दिखाना मुश्किल हो जाता है, खासकर जब प्रोवाइडर-स्पेसिफिक टूल और सेशन सिमेंटिक्स मायने रखते हैं. यह क्षेत्र तेजी से विकसित हो रहा है, और हमें उम्मीद है कि जैसे-जैसे हम वास्तविक दुनिया के एजेंट वर्कफ़्लोज़ को दर्शाने के लिए सर्वोत्तम प्रिमिटिव्स का पता लगाते हैं, वैसे-वैसे अधिक सामान्य मानक उभरेंगे (skills⁠(एक नई विंडो में खुलेगा) इसका एक अच्छा उदाहरण है).

Codex ऐप सर्वर

जब तुम चाहते हो कि पूरा Codex harness एक स्थिर, UI-फ्रेंडली इवेंट स्ट्रीम के रूप में प्रकट हो, तब App Server चुनो. तुम्हें एजेंट लूप की पूरी कार्यक्षमता के साथ-साथ Sign in with ChatGPT, मॉडल डिस्कवरी और कॉन्फ़िगरेशन मैनेजमेंट जैसी अन्य सहायक सुविधाएँ भी मिलती हैं. मुख्य लागत इंटीग्रेशन कार्य है, क्योंकि तुम्हें अपनी भाषा में client-side JSON-RPC binding बनानी होगी. व्यवहार में, हालांकि, Codex बहुत सारा भारी काम कर सकता है, अगर तुम उसे JSON स्कीमा और डाक्यूमेंटेशन देते हो. हमने जिन कई टीमों के साथ काम किया, वे Codex का उपयोग करके जल्दी ही एक कार्यशील इंटीग्रेशन बना सकीं.

Codex को एम्बेड करने के अन्य तरीके

Codex Exec⁠(एक नई विंडो में खुलेगा)

एक हल्का, स्क्रिप्ट करने योग्य CLI मोड जो एक-बार के कार्यों और CI रन के लिए उपयुक्त है. यह ऑटोमेशन और पाइपलाइन के लिए एक अच्छा विकल्प है, जहाँ आप चाहते हैं कि एक ही कमांड बिना किसी इंटरैक्शन के पूरा चले, लॉग के लिए स्ट्रक्चर्ड आउटपुट स्ट्रीम करे, और सफलता या विफलता का स्पष्ट सिग्नल देकर एग्जिट हो जाए.

Codex SDK⁠(एक नई विंडो में खुलेगा)

आपके अपने एप्लिकेशन के भीतर से स्थानीय Codex एजेंट्स को प्रोग्रामेटिक रूप से नियंत्रित करने के लिए एक TypeScript लाइब्रेरी. यह तब सबसे अच्छा होता है जब तुम अलग से JSON-RPC क्लाइंट बनाए बिना सर्वर-साइड टूल्स और वर्कफ़्लो के लिए एक नेटिव लाइब्रेरी इंटरफ़ेस चाहते हो. चूंकि यह ऐप सर्वर से पहले भेजा गया था, इसलिए यह वर्तमान में कम भाषाओं और छोटे कार्यक्षेत्र का समर्थन करता है. अगर डेवलपर्स की दिलचस्पी होगी, तो हम और SDKs जोड़ सकते हैं जो ऐप सर्वर प्रोटोकॉल को रैप करेंगे ताकि टीमें JSON-RPC बाइंडिंग लिखे बिना हार्नेस सरफेस के ज़्यादा हिस्से को कवर कर सकें.

इसे आगे ले जाना

इस पोस्ट में, हमने बताया कि हम एजेंट्स के साथ इंटरैक्ट करने के लिए एक नया मानक कैसे डिज़ाइन करते हैं और Codex हार्नेस को एक स्थिर, ग्राहक-अनुकूल प्रोटोकॉल में कैसे बदलते हैं. हमने चर्चा की कि App Server Codex core को कैसे उजागर करता है, क्लाइंट्स को पूरा एजेंट लूप संचालित करने की अनुमति देता है, और TUI, स्थानीय IDE इंटीग्रेशन, और वेब रनटाइम सहित विभिन्न सतहों को शक्ति प्रदान करता है.

अगर इससे आपके अपने वर्कफ़्लो में Codex को इंटीग्रेट करने के लिए विचार उत्पन्न हुए हैं, तो App Server को आज़माना लाभदायक होगा. सारा सोर्स कोड Codex CLI ओपन-सोर्स रेपो⁠(एक नई विंडो में खुलेगा) में है. आप अपना फीडबैक और फीचर रिक्वेस्ट बेझिझक साझा करें. हम आपसे सुनने के लिए उत्सुक हैं और एजेंट्स को सभी के लिए अधिक सुलभ बनाते रहने के लिए उत्साहित हैं.

लेखक

Celia Chen

स्वीकृतियां

Michael Bolin, Owen Lin, Eric Traut, और Rasmus Rygaard, जिन्होंने इस पोस्ट में योगदान दिया, और App Server पर काम करने वाली पूरी Codex टीम को विशेष धन्यवाद.

फ़ुटनोट

1
हम “JSON‑RPC lite” का एक संस्करण उपयोग करते हैं: यह अनुरोध/प्रतिक्रिया/सूचना का स्वरूप बनाए रखता है, लेकिन "jsonrpc": "2.0" को छोड़ देता है हेडर और इसे strict JSON‑RPC 2.0 के बजाय stdio पर JSONL के रूप में तैयार किया गया है.
2
“stdio” कंटेनर के अंदर ऐप-सर्वर के stdin/stdout को संदर्भित करता है. होस्टेड सेटअप्स में, उन स्ट्रीम्स को अक्सर एक स्थायी नेटवर्क कनेक्शन (जैसे, WebSocket जैसा) के माध्यम से कंटेनर रनटाइम तक टनल किया जाता है—इसलिए यह stdio की तरह व्यवहार करता है, भले ही यह कोई शाब्दिक लोकल पाइप न हो.

पढ़ते रहें

सभी देखें

Codex के साथ स्व-सुधार करने वाले टैक्स एजेंट बनाना

इंजीनियरिंग27 मई 2026

Windows पर Codex सक्षम करने के लिए एक सुरक्षित, प्रभावी सैंडबॉक्स बनाना

इंजीनियरिंग13 मई 2026

Supercomputer networking to accelerate large scale AI training

इंजीनियरिंग5 मई 2026