४ फेब्रुवारी, २०२६

Codex हार्नेस अनलॉक करणे: आम्ही App Server कसा तयार केला

सेलिया चेन, तांत्रिक कर्मचारी सदस्य द्वारे

लोड होत आहे...

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 हा Codex हार्नेस विविध उत्पादनांमध्ये पुन्हा वापरण्याचा एक व्यावहारिक मार्ग होता, जो हळूहळू विकसित होऊन आमच्या मानक प्रोटोकॉलमध्ये रूपांतरित झाला.

Codex CLI ची सुरुवात TUI (टर्मिनल युजर इंटरफेस) म्हणून झाली आहे, म्हणजे Codex ला टर्मिनलद्वारे प्रवेश करता येतो. जेव्हा आम्ही VS Code एक्स्टेंशन (Codex एजंट्सशी संवाद साधण्यासाठी अधिक IDE-फ्रेंडली मार्ग) तयार केले, तेव्हा आम्हाला त्याच हार्नेसचा वापर करण्याचा एक मार्ग हवा होता, जेणेकरून IDE UI मधून तोच एजंट लूप चालवता येईल आणि तो पुन्हा अंमलात आणावा लागू नये. याचा अर्थ request/response पलीकडील समृद्ध परस्परसंवाद पॅटर्न्सना समर्थन देणे, जसे की वर्कस्पेस एक्सप्लोर करणे, एजंट विचार करत असताना प्रगती प्रवाहित करणे, आणि फरक उत्सर्जित करणे. आम्ही प्रथम Codex ला MCP सर्व्हर म्हणून⁠(नवीन विंडोमध्ये उघडेल) उघड करण्याचा प्रयोग केला, परंतु VS Code साठी अर्थपूर्ण वाटेल अशा पद्धतीने MCP सेमॅंटिक्स राखणे कठीण ठरले. त्याऐवजी, आम्ही TUI लूपचे प्रतिबिंब असलेला JSON-RPC प्रोटोकॉल सादर केला, जो अ‍ॅप सर्व्हरची अनौपचारिक पहिली आवृत्ती⁠(नवीन विंडोमध्ये उघडेल) बनला. त्या वेळी, इतर ग्राहक अ‍ॅप सर्व्हरवर अवलंबून राहतील अशी आम्हाला अपेक्षा नव्हती, त्यामुळे तो स्थिर 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 core हे एक लायब्ररी आहे जिथे सर्व एजंट कोड असतो आणि एक runtime देखील आहे, जो एजंट लूप चालवण्यासाठी आणि एका Codex थ्रेड (संवाद) ची स्थिरता व्यवस्थापित करण्यासाठी सुरू करता येतो.

उपयुक्त ठरण्यासाठी, Codex हार्नेस क्लायंट्ससाठी सहज उपलब्ध असणे आवश्यक आहे. तेथेच App Server कामी येतो.

“App server process flow” शीर्षक असलेला आरेख. एक क्लायंट JSON-RPC संदेश stdio रीडरला पाठवतो, जो विनंत्या Codex संदेश प्रोसेसरकडे पाठवतो. प्रोसेसर लुकअप थ्रेड्स, थ्रेड हँडल्स, सबमिट केलेल्या विनंत्या आणि इव्हेंट्स/अपडेट्सद्वारे थ्रेड व्यवस्थापक आणि कोर थ्रेडशी संवाद साधतो, आणि नंतर क्लायंटकडे प्रतिसाद परत पाठवतो.

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

एका क्लायंटच्या विनंतीमुळे अनेक इव्हेंट अपडेट्स होऊ शकतात, आणि हे तपशीलवार इव्हेंट्स आम्हाला App Server वर समृद्ध UI तयार करण्यास सक्षम करतात. याव्यतिरिक्त, stdio रीडर आणि Codex संदेश प्रोसेसर क्लायंट आणि Codex कोअर थ्रेड्स यांच्यातील अनुवाद स्तर म्हणून कार्य करतात. ते क्लायंट JSON-RPC विनंत्यांचे Codex core ऑपरेशन्समध्ये भाषांतर करतात, Codex core च्या अंतर्गत इव्हेंट स्ट्रीमला ऐकतात, आणि नंतर त्या लो-लेव्हल इव्हेंट्सना स्थिर, UI-रेडी JSON-RPC नोटिफिकेशन्सच्या छोट्या संचात रूपांतर करतात.

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

संवाद प्रिमिटिव्ह्स

यानंतर, आम्ही App Server प्रोटोकॉलचे मूलभूत घटक असलेल्या संभाषण प्रिमिटिव्ह्जचे विश्लेषण करू. एजंट लूपसाठी API डिझाइन करणे कठीण आहे कारण वापरकर्ता/एजंट परस्परसंवाद साध्या विनंती/प्रतिसादासारखा नसतो. एका वापरकर्त्याची विनंती क्लायंटला प्रामाणिकपणे दर्शवण्याची गरज असलेल्या कृतींच्या संरचित क्रमात उलगडू शकते: वापरकर्त्याचा इनपुट, एजंटची टप्प्याटप्प्याने प्रगती, आणि मार्गात तयार होणारी कलाकृती (उदा., फरक). त्या परस्परसंवाद प्रवाहाला UI मध्ये एकत्रित करणे सोपे आणि लवचिक बनवण्यासाठी, आम्ही स्पष्ट सीमा आणि जीवनचक्रांसह तीन मुख्य मूलभूत घटकांवर स्थिरावलो:

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

item/started आयटम सुरू होताच
पर्यायी item/*/delta इव्हेंट्स सामग्री प्रवाह म्हणून (स्ट्रीमिंग आयटम प्रकारांसाठी)
item/completed जेव्हा आयटम त्याच्या अंतिम पेलोडसह पूर्ण होते

हा जीवनचक्र क्लायंट्सना started वर त्वरित रेंडरिंग सुरू करण्यास अनुमती देतो, delta वर वाढीव अपडेट्स प्रवाहित करण्यास अनुमती देतो, आणि completed वर अंतिम रूप देतो.

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

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

आता, तुम्ही ग्राहक आणि एजंट यांच्यातील एका साध्या संभाषणाकडे पाहू, जिथे संभाषण मूलभूत घटकांद्वारे दर्शवले आहे:

‘क्लायंट-सर्व्हर प्रोटोकॉल संदेश प्रवाह: प्रारंभिक हँडशेक’ असे लेबल असलेला आकृती. एक ग्राहक clientInfo सह सर्व्हरला प्रारंभ विनंती पाठवतो. सर्व्हर “my_client/1.0” userAgent स्ट्रिंगसह परिणाम इव्हेंटसह प्रतिसाद देतो.

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

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/start आणि turn/start विनंत्या पाठवतो. सर्व्हर इव्हेंट्स उत्सर्जित करतो—thread/started, turn/started, item/started, आणि item/completed—जेथे वापरकर्त्याचा संदेश “run tests and summarize failures.” असलेला एक टर्न दर्शविला जातो.

जेव्हा क्लायंट नवीन विनंती करतो, तेव्हा तो प्रथम एक थ्रेड आणि नंतर एक टर्न तयार करतो. सर्व्हर प्रगतीसाठी सूचना परत पाठवेल (thread/started आणि turn/started)। हे आयटम्स म्हणून नोंदवलेले इनपुट्सही परत पाठवेल, जसे इथे वापरकर्त्याचा संदेश.

“Client-server protocol message flow: Tool execution with optional approval.” शीर्षक असलेला आरेख. टूल कॉल दरम्यान, सर्व्हर item/started उत्सर्जित करतो, त्यानंतर कारणासह item/commandExecution/requestApproval (“run tests”) पाठवतो. ग्राहक मंजुरी इव्हेंट (allow/deny) परत करतो. त्यानंतर सर्व्हर आदेश अंमलबजावणी दर्शवणारे item/completed उत्सर्जित करतो ("pnpm test").

टूल कॉल्स देखील आयटम्स म्हणून क्लायंटकडे परत पाठवले जातात. याव्यतिरिक्त, सर्व्हर सर्व्हर रिक्वेस्ट पाठवून एखादी कृती चालवण्यापूर्वी क्लायंटची मंजुरी मागू शकतो. क्लायंट “allow” किंवा “deny” यापैकी कोणतेही उत्तर देईपर्यंत मंजुरीमुळे टर्न थांबेल. VS Code एक्स्टेंशनमध्ये मंजुरीचा प्रवाह असा दिसतो:

गडद थीम असलेल्या इंटरफेसमधील परवानगी प्रॉम्प्ट विचारतो, “तुम्ही मला या वर्कस्पेससाठी pnpm test चालवण्याची परवानगी द्याल का?” यात पर्याय सूचीबद्ध आहेत: 1) Yes, 2) Yes and don’t ask again for commands starting with pnpm test, आणि 3) No, आणि तळाशी Submit बटण आहे.

“क्लायंट-सर्व्हर प्रोटोकॉल संदेश प्रवाह: स्ट्रीमिंग एजंट संदेश प्रवाह” असे शीर्षक असलेला आरेख. सर्व्हर सहाय्य संदेश भागांमध्ये प्रवाहित करतो: item/started, two agentMessage/delta events (“ran 3 tests.”, “all passed”), then item/completed. टर्न/पूर्ण झाले ने संपतो.

शेवटी, सर्व्हर एक एजंट संदेश पाठवतो आणि नंतर turn/completed सह फेरी समाप्त करतो. एजंट संदेश डेल्टा इव्हेंट्स संदेशाचे तुकडे परत प्रवाहित करतात, जोपर्यंत संदेश item/completed सह अंतिम होत नाही.

आकृतीतील संदेश वाचनीयतेसाठी सोपे केलेले आहेत. जर तुम्हाला पूर्ण टर्नसाठी JSON पाहायचे असेल, तर तुम्ही Codex CLI रेपोमधून टेस्ट क्लायंट चालवू शकता:

Bash

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

ग्राहकांसोबत एकत्रीकरण करणे

आता, App Server द्वारे विविध क्लायंट सरफेसेस Codex कसे एम्बेड करतात ते पाहूया. आम्ही तीन पॅटर्न्स कव्हर करू: लोकल अ‍ॅप्स आणि IDEs, Codex वेब रनटाइम, आणि TUI.

“Codex harness सोबत app server द्वारे एकत्रित केलेले Codex clients” नावाचा डायग्राम. फर्स्ट-पार्टी क्लायंट्स (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

Codex एक्स्टेंशन चालू असलेल्या VS Code चा स्क्रीनशॉट. एक Rust चाचणी फाईल उघडी आहे, आणि तिच्या खाली Codex पॅनेल फक्त fmt आणि cargo test -p codex-app-server चालवण्याचे वर्णन करते, फॉरमॅटिंग आणि चाचण्या प्रगतीपथावर असल्याचे अहवाल देते, आणि अंतिम पास/फेल निकालाची प्रतीक्षा करत आहे.

स्थानिक क्लायंट्स सहसा प्लॅटफॉर्म-विशिष्ट App Server बायनरी बंडल करतात किंवा प्राप्त करतात, त्यास दीर्घकाळ चालणाऱ्या चाइल्ड प्रोसेस म्हणून सुरू करतात, आणि JSON-RPC साठी द्विदिशात्मक stdio चॅनेल उघडे ठेवतात. आमच्या VS Code extension आणि Desktop App मध्ये, उदाहरणार्थ, वितरित केलेल्या आर्टिफॅक्टमध्ये प्लॅटफॉर्म-विशिष्ट Codex बायनरी समाविष्ट असते आणि ती चाचणी केलेल्या आवृत्तीला पिन केलेली असते, त्यामुळे ग्राहक नेहमी आम्ही सत्यापित केलेले नेमकेच बिट्स चालवतात.

प्रत्येक एकत्रीकरणासाठी क्लायंट अद्यतने वारंवार पाठवणे शक्य नसते. Xcode सारखे काही भागीदार ग्राहक स्थिर ठेवून आणि गरज पडल्यास त्याला नवीन App Server बायनरीकडे निर्देश करू देऊन प्रकाशन चक्र वेगळे करतात. अशा प्रकारे ते सर्व्हर-साइड सुधारणा (उदाहरणार्थ, Codex core मधील अधिक चांगले ऑटो-कॉम्पॅक्शन किंवा नव्याने समर्थित कॉन्फिग कीज) स्वीकारू शकतात आणि क्लायंट रिलीझची वाट न पाहता बग फिक्सेस रीलिझ करू शकतात. App Server च्या JSON-RPC पृष्ठभागाला मागील आवृत्त्यांशी सुसंगत ठेवण्यासाठी डिझाइन केले आहे, त्यामुळे जुने क्लायंट्स नवीन सर्व्हर्सशी सुरक्षितपणे संवाद साधू शकतात.

Codex वेब

Codex वेब Codex हार्नेस वापरते, परंतु ते कंटेनर वातावरणात चालवते. एक कामगार checked-out वर्कस्पेससह एक कंटेनर तयार करतो, त्यात App Server बायनरी सुरू करतो, आणि 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” client होता जो एजंट loop सोबत त्याच process मध्ये चालत असे आणि app-server protocol ऐवजी थेट Rust core types शी संवाद साधत असे. त्यामुळे प्रारंभीचे पुनरावर्तन जलद झाले, परंतु त्यामुळे 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⁠(नवीन विंडोमध्ये उघडेल) चालवा आणि stdio सर्व्हर्सना समर्थन देणाऱ्या कोणत्याही MCP क्लायंटमधून कनेक्ट करा (उदा., OpenAI Agents SDK⁠(नवीन विंडोमध्ये उघडेल)). हे एक चांगले पर्याय आहे जर तुमच्याकडे आधीच MCP-आधारित वर्कफ्लो असेल आणि तुम्हाला Codex ला कॉल करण्यायोग्य साधन म्हणून इनव्होक करायचे असेल. कमतरता अशी आहे की तुम्हाला फक्त MCP जे उघड करते तेच मिळते, त्यामुळे अधिक समृद्ध सत्र सेमॅंटिक्सवर (उदा., diff अपडेट्स) अवलंबून असलेले Codex-विशिष्ट इंटरॅक्शन्स MCP एंडपॉइंट्समधून स्वच्छपणे मॅप होऊ शकत नाहीत.

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

काही इकोसिस्टम्स पोर्टेबल इंटरफेस ऑफर करतात, जो अनेक मॉडेल प्रदाते आणि रनटाइम्सना लक्ष्य करू शकतो. जर तुम्हाला अनेक एजंट्सचे समन्वय साधणारे एकच अब्स्ट्रॅक्शन हवे असेल, तर हे एक चांगले पर्याय ठरू शकते. तडजोड अशी आहे की हे प्रोटोकॉल्स अनेकदा क्षमतांच्या सामान्य उपसंचावर एकत्र येतात, ज्यामुळे अधिक समृद्ध परस्परसंवादांचे प्रतिनिधित्व करणे कठीण होऊ शकते, विशेषतः जेव्हा प्रदाता-विशिष्ट साधने आणि सत्र सेमॅंटिक्स महत्त्वाचे असतात. हे क्षेत्र वेगाने विकसित होत आहे, आणि आम्हाला अपेक्षा आहे की वास्तविक जगातील एजंट वर्कफ्लोजचे प्रतिनिधित्व करण्यासाठी सर्वोत्तम मूलभूत घटक शोधताना अधिक सामान्य मानके उदयास येतील (skills⁠(नवीन विंडोमध्ये उघडेल) हे याचे एक चांगले उदाहरण आहे).

Codex ॲप सर्व्हर

पूर्ण Codex हार्नेस स्थिर, UI-फ्रेंडली इव्हेंट प्रवाह म्हणून उघड करायचा असेल तेव्हा App Server निवडा. तुम्हाला एजंट लूपची संपूर्ण कार्यक्षमता तसेच Sign in with ChatGPT, मॉडेल डिस्कव्हरी, आणि कॉन्फिगरेशन व्यवस्थापन यांसारखी इतर सहाय्यक वैशिष्ट्ये मिळतात. मुख्य खर्च समाकलनाच्या कामाचा आहे, कारण तुम्हाला तुमच्या भाषेत क्लायंट-साइड JSON-RPC बाइंडिंग तयार करावी लागेल. प्रत्यक्षात, मात्र, तुम्ही JSON स्कीमा आणि दस्तऐवजीकरण दिल्यास Codex बरेचसे कठीण काम करू शकतो. आम्ही ज्या अनेक संघांसोबत काम केले, त्यांनी Codex वापरून लवकरच कार्यरत एकत्रीकरण साध्य केले.

Codex एम्बेड करण्याचे इतर मार्ग

Codex Exec⁠(नवीन विंडोमध्ये उघडेल)

एकदाच करायच्या कामांसाठी आणि CI रनसाठी हलका, स्क्रिप्टेबल CLI मोड. हे ऑटोमेशन आणि पाइपलाइन्ससाठी योग्य आहे, जिथे तुम्हाला एकच कमांड नॉन-इंटरॅक्टिव्ह पद्धतीने पूर्ण होईपर्यंत चालवायची असते, लॉग्ससाठी स्ट्रक्चर्ड आउटपुट्स प्रवाहित करायचे असते, आणि स्पष्ट यश किंवा अपयश सिग्नलसह बाहेर पडायचे असते.

कोडेक्स SDK⁠(नवीन विंडोमध्ये उघडेल)

तुमच्या स्वतःच्या अनुप्रयोगातून स्थानिक Codex एजंट्सना प्रोग्रामॅटिक पद्धतीने नियंत्रित करण्यासाठी TypeScript लायब्ररी. स्वतंत्र JSON-RPC क्लायंट न बनवता सर्व्हर-साइड टूल्स आणि वर्कफ्लोजसाठी तुम्हाला नेटीव्ह लायब्ररी इंटरफेस हवा असेल तेव्हा हे सर्वोत्तम आहे. ते App Server पेक्षा आधी शिप झाले असल्याने, सध्या ते कमी भाषांना आणि कमी कार्यक्षेत्राला समर्थन करते. जर विकसकांना रस असेल, तर आम्ही App Server प्रोटोकॉलला wrap करणारे अतिरिक्त SDKs जोडू शकतो, ज्यामुळे टीम्सना JSON-RPC bindings न लिहिता harness surface चा अधिक भाग कव्हर करता येईल.

हे पुढे नेणे

या पोस्टमध्ये, आम्ही एजंट्सशी संवाद साधण्यासाठी नवीन मानक डिझाइन करण्याची आमची पद्धत आणि Codex हार्नेसला स्थिर, ग्राहक-अनुकूल प्रोटोकॉलमध्ये रूपांतरित करण्याची प्रक्रिया कशी आहे हे सामायिक केले. आम्ही स्पष्ट केले की App Server Codex core कसा प्रदर्शित करतो, क्लायंट्सना पूर्ण एजंट लूप चालवण्याची परवानगी देतो, आणि TUI, स्थानिक IDE एकत्रीकरणे, आणि वेब रनटाइम यांसारख्या विविध पृष्ठभागांना सामर्थ्य देतो.

जर यामुळे तुमच्या स्वतःच्या कार्यप्रवाहांमध्ये Codex एकत्रित करण्याच्या कल्पना सुचल्या असतील, तर App Server वापरून पाहणे फायदेशीर ठरेल. सर्व स्रोत कोड Codex CLI ओपन-सोर्स repo⁠(नवीन विंडोमध्ये उघडेल) मध्ये आहे. तुमचा अभिप्राय आणि वैशिष्ट्य विनंत्या शेअर करण्यास मोकळे आहात. तुमच्याकडून ऐकायला आम्हाला आनंद होईल आणि एजंट्स प्रत्येकासाठी अधिक प्रवेशयोग्य बनवण्यासाठी आम्ही प्रयत्नशील आहोत.

लेखक

Celia Chen

आभार

या पोस्टमध्ये योगदान दिल्याबद्दल Michael Bolin, Owen Lin, Eric Traut, आणि Rasmus Rygaard यांचे विशेष आभार, तसेच App Server वर काम केलेल्या संपूर्ण Codex टीमचे आभार.

फूटनोट्स

1
आम्ही “JSON‑RPC lite” प्रकार वापरतो: तो request/response/notification चे स्वरूप कायम ठेवतो, परंतु "jsonrpc": "2.0" वगळतो header आणि strict JSON‑RPC 2.0 ऐवजी stdio वर JSONL म्हणून फ्रेम केलेले आहे.
2
“stdio” कंटेनरच्या आत असलेल्या ॲप-सर्व्हरच्या stdin/stdout ला संदर्भित करते. होस्टेड सेटअप्समध्ये, त्या स्ट्रीम्स अनेकदा स्थिर नेटवर्क कनेक्शन (उदा., WebSocket सारखे) वरून कंटेनर रनटाइमकडे टनेल केल्या जातात—म्हणून ते literal local pipe नसले तरी stdio सारखे वागतात.

वाचत राहा

सर्व पहा

Codex सह स्वतः सुधारणारे कर एजंट तयार करणे

इंजिनिअरिंग२७ मे, २०२६

Windows वर Codex सक्षम करण्यासाठी सुरक्षित, प्रभावी सँडबॉक्स तयार करणे

इंजिनिअरिंग१३ मे, २०२६

गॉब्लिन्स कुठून आले

इंजिनिअरिंग५ मे, २०२६