- Codex को अपने प्रोडक्ट में इंटीग्रेट करने के लिए OpenAI ने मानकीकृत App Server आर्किटेक्चर और JSON-RPC प्रोटोकॉल बनाया और उपलब्ध कराया
- शुरुआत में यह CLI-केंद्रित TUI harness से शुरू हुआ, लेकिन JSON-RPC प्रोटोकॉल अपनाने के बाद IDE, web और local app जैसे कई clients एक ही agent loop साझा कर सकते हैं
- App Server एक long-running process है जो Codex core library को host करता है, और thread lifecycle management, configuration/authentication, tool execution जैसी पूरी agent experience को client के सामने expose करता है
- item, turn और thread नाम की तीन conversation primitives के जरिए agent loop की जटिल interactions को structure किया जा सकता है और समृद्ध UI बनाया जा सकता है
- VS Code, JetBrains, Xcode, desktop apps और web runtime जैसे अलग-अलग surfaces पर एक ही harness दोबारा इस्तेमाल किया जा सकता है, और Go, Python, TypeScript, Swift, Kotlin जैसी भाषाओं के लिए multi-language client bindings भी उपलब्ध हैं
- MCP server, CLI mode और TypeScript SDK जैसे वैकल्पिक integration तरीके भी मौजूद हैं, लेकिन App Server ही प्राथमिक integration standard बन चुका है
- OpenAI, App Server को Codex integration का डिफ़ॉल्ट रास्ता बनाए रखेगा, और open source CLI repo के ज़रिए किसी को भी अपने workflow में Codex इंटीग्रेट करने में मदद देगा
App Server की बुनियादी पृष्ठभूमि
- शुरुआत में यह कई प्रोडक्ट्स में Codex harness को reuse करने का एक व्यावहारिक तरीका था, लेकिन धीरे-धीरे यह standard protocol में बदल गया
- Codex CLI की शुरुआत TUI (terminal user interface) के रूप में हुई थी, और VS Code extension बनाते समय उसी harness को IDE UI में चलाने का तरीका चाहिए था
- इसके लिए workspace exploration, reasoning progress streaming, diff output जैसी request/response से आगे की interaction patterns का समर्थन ज़रूरी था
- शुरू में Codex को MCP server के रूप में expose करने की कोशिश की गई, लेकिन VS Code के लिए उपयुक्त तरीके से MCP semantics बनाए रखना मुश्किल था
- इसके विकल्प के रूप में TUI loop को दर्शाने वाला JSON-RPC protocol अपनाया गया, जो App Server का अनौपचारिक पहला version बना
- उस समय यह नहीं सोचा गया था कि दूसरे clients भी इस पर निर्भर होंगे, इसलिए इसे stable API की तरह डिज़ाइन नहीं किया गया था
- Codex का उपयोग बढ़ने के साथ internal teams और external partners (JetBrains, Xcode आदि) ने अपने प्रोडक्ट्स में harness embed करने की क्षमता मांगी
- इसके लिए backward compatibility बनाए रखते हुए protocol को विकसित करने लायक platform surface डिज़ाइन करना ज़रूरी था
Codex harness की आंतरिक संरचना
- Codex core एक library है जिसमें पूरा agent code शामिल है, और यह वह runtime भी है जो agent loop चलाता है और एक Codex thread (conversation) की persistence संभालता है
- मुख्य agent loop के अलावा तीन प्रमुख functional areas हैं:
- thread lifecycle और persistence: thread बनाना, resume करना, fork करना, archive करना, और event record बनाए रखना ताकि client दोबारा connect होकर consistent timeline render कर सके
- configuration और authentication: config load करना, defaults manage करना, credentials state संभालना, और "ChatGPT से login" जैसी auth flows चलाना
- tool execution और extensibility: sandbox में shell/file tools चलाना, MCP servers और skills जैसी integrations को जोड़ना ताकि वे consistent policy model के तहत agent loop में भाग ले सकें
App Server आर्किटेक्चर
- App Server, client और server के बीच का JSON-RPC protocol है, और यह Codex core threads को host करने वाली long-running process भी है
- इसके चार मुख्य components हैं:
- stdio reader: client से input पढ़ता है
- Codex message processor: हर core session से सीधे बात करता है, client requests submit करता है और updates प्राप्त करता है
- thread manager: हर thread के लिए एक core session शुरू करता है
- core thread: वास्तविक agent loop चलाता है
- एक client request से कई event updates पैदा हो सकते हैं, और इन्हीं विस्तृत events के आधार पर rich UI बनाया जा सकता है
- stdio reader और Codex message processor, client JSON-RPC requests को Codex core operations में बदलते हैं, और internal event stream को स्थिर तथा UI-उपयोगी JSON-RPC notifications में बदलने वाली translation layer की तरह काम करते हैं
- client और App Server के बीच का JSON-RPC protocol पूरी तरह bidirectional है
- जब agent को approval जैसे input की ज़रूरत हो, तब server खुद request शुरू कर सकता है और client के जवाब तक turn को pause कर सकता है
Conversation primitives
- agent loop के लिए API डिज़ाइन का मूल बिंदु यह है कि user और agent के बीच interaction सिर्फ़ एक साधारण request/response नहीं, बल्कि structured sequence of actions के रूप में आगे बढ़ती है
- तीन मुख्य primitives हैं:
-
Item
- Codex में input/output की बुनियादी इकाई
- इसका type निर्धारित होता है: user message, agent message, tool execution, approval request, diff आदि
- इसका स्पष्ट lifecycle है:
item/started → वैकल्पिक item/*/delta (streaming) → item/completed (final payload)
- client
started पर तुरंत rendering शुरू कर सकता है, delta पर क्रमिक updates stream कर सकता है, और completed पर item को final रूप देता है
-
Turn
- user input से शुरू होने वाली agent work की एक इकाई
- उदाहरण: client अगर "run tests and summarize failures" submit करे, तो turn शुरू होता है; agent output बनाना पूरा कर दे, तो turn समाप्त होता है
- एक turn में intermediate steps और result को दर्शाने वाले कई items शामिल होते हैं
-
Thread
- user और agent के बीच चल रहे Codex session का persistent container
- इसमें कई turns हो सकते हैं, और इसे create, resume, fork, archive किया जा सकता है
- thread history लगातार बनी रहती है ताकि client दोबारा connect होकर consistent timeline render कर सके
Client-server conversation flow
- conversation शुरू करते समय client और server को
initialize handshake स्थापित करना होता है
- client को किसी भी दूसरी method से पहले एक single
initialize request भेजनी होती है, और server response में उसे confirm करता है
- दोनों पक्ष protocol versioning, feature flags और defaults पर सहमति बनाते हैं
- नई request आने पर server thread बनाता है, फिर turn बनाता है, और
thread/started तथा turn/started notifications भेजता है
- tool calls भी items के रूप में client तक भेजी जाती हैं, और server execution approval मांग सकता है
- approval request होने पर turn तब तक pause रहता है जब तक client "allow" या "deny" में जवाब न दे
- server agent message भेजता है और
turn/completed के साथ turn समाप्त करता है
- agent message के delta events message के हिस्से stream करते हैं, और अंत में
item/completed के साथ final रूप पूरा होता है
- पूरे turn का JSON देखने के लिए
codex debug app-server send-message-v2 "run tests and summarize failures" कमांड चलाई जा सकती है
Clients के साथ integration patterns
-
Local apps और IDE
- transport के रूप में stdio पर JSON-RPC (JSONL) इस्तेमाल होता है
- local clients platform-specific App Server binary को bundle या fetch करके long-running subprocess के रूप में चलाते हैं
- VS Code extension और desktop app में deployment artifact के साथ platform-specific Codex binary शामिल की जाती है और tested version पर pin किया जाता है
- Go, Python, TypeScript, Swift, Kotlin जैसी भाषाओं में App Server clients पहले से implement किए जा चुके हैं
- TypeScript:
codex app-server generate-ts कमांड से definitions सीधे generate की जा सकती हैं
- अन्य भाषाएँ:
codex app-server generate-json-schema कमांड से JSON schema bundle बनाकर code generator में input दिया जा सकता है
- Xcode जैसे partners, client को stable रखते हुए सबसे नए App Server binary की ओर point करके release cycles को अलग रख सकते हैं
- इससे client release का इंतज़ार किए बिना server-side improvements (बेहतर auto-compaction, नई config keys आदि) और bug fixes deploy किए जा सकते हैं
- JSON-RPC surface backward compatible होने के कारण पुराने clients भी नए servers से सुरक्षित रूप से बात कर सकते हैं
-
Codex web runtime
- यह container environment में चलता है
- worker checked-out workspace के साथ container provision करता है, उसके भीतर App Server binary चलाता है, और stdio channel के ज़रिए JSON-RPC बनाए रखता है
- web app (user browser) HTTP और SSE के माध्यम से Codex backend से बात करती है और work events stream करती है
- इससे browser-side UI हल्का रहता है और desktop तथा web दोनों में consistent runtime मिलता है
- web sessions अक्सर अल्पकालिक होते हैं (tab बंद होना, network कटना), इसलिए state और progress server पर बनाए रखी जाती है
- tab बंद होने पर भी काम जारी रह सकता है, और नई session आसानी से reconnect होकर वहीं से resume कर सकती है जहाँ काम रुका था
-
TUI refactoring plan
- मौजूदा TUI एक "native" client है जो agent loop के साथ उसी process में चलता है, और App Server protocol की जगह Rust core types से सीधे बात करता है
- योजना है कि TUI को App Server का उपयोग करने के लिए refactor किया जाए ताकि वह दूसरे clients की तरह काम करे
- remote machine पर चल रहे Codex server से connect कर सके
- agent computing infrastructure से नज़दीकी रूप से जुड़ा रह सके और laptop sleep mode या connection drop होने पर भी काम जारी रखे
- local स्तर पर live updates और control capabilities मिलती रहें
सही protocol चुनना
- App Server प्राथमिक integration तरीका है, लेकिन कम capabilities वाले कुछ alternatives भी हैं
-
MCP server
codex mcp-server चलाएँ और किसी भी ऐसे MCP client (जैसे OpenAI Agents SDK) से connect करें जो stdio server को support करता हो- यह तब उपयुक्त है जब आपके पास पहले से MCP-based workflow हो और आप Codex को callable tool की तरह इस्तेमाल करना चाहते हों
- कमी: आप MCP द्वारा दिए गए दायरे तक सीमित रहते हैं; diff updates जैसी Codex-specific interactions सहज रूप से map नहीं हो सकतीं
-
Portable interface
- यह तब उपयोगी है जब कई model providers और runtimes को target करने वाला एक single abstraction चाहिए
- कमी: यह अक्सर features के common subset तक सिमट जाता है, जिससे rich interactions व्यक्त करना मुश्किल हो सकता है
- यह क्षेत्र तेज़ी से विकसित हो रहा है, और आगे और common standards आने की संभावना है (जैसे agentskills.io)
-
App Server
- यह पूरे Codex harness को एक स्थिर और UI-friendly event stream के रूप में expose करता है
- पूरे agent loop की functionality के अलावा, "ChatGPT से login", model discovery और configuration management जैसी सहायक सुविधाएँ भी उपलब्ध कराता है
- मुख्य लागत: इस्तेमाल की जा रही भाषा में client-side JSON-RPC binding बनानी पड़ती है
- अगर JSON schema और documentation उपलब्ध हो, तो Codex कई जटिल काम संभाल सकता है और बहुत-सी teams तेज़ी से integration लागू कर सकती हैं
-
CLI mode
- one-off tasks और CI runs के लिए हल्का script-style mode
- यह एक single command को non-interactively चलाता है, structured output stream करता है, और स्पष्ट success/failure signal के साथ समाप्त होता है
- automation और pipelines के लिए उपयुक्त
-
TypeScript SDK
- यह एक TypeScript library है जिससे अपने application के भीतर local Codex agent को programmatically control किया जा सकता है
- यह तब उपयोगी है जब अलग JSON-RPC client बनाए बिना native library interface चाहिए
- यह App Server से पहले लॉन्च हुआ था, इसलिए supported languages कम हैं और scope भी सीमित है
- developer interest के आधार पर App Server protocol को wrap करने वाले अतिरिक्त SDKs भी दिए जा सकते हैं
आगे की योजना
- App Server, Codex core को expose करता है, clients को पूरा agent loop चलाने देता है, और TUI, local IDE integrations तथा web runtime सहित विस्तृत surface support प्रदान करता है
- सारा source code Codex CLI open source repo में उपलब्ध है
- feature requests और feedback का स्वागत है, और agents को और आसान बनाने के लिए लगातार सुधार जारी रहेंगे
अभी कोई टिप्पणी नहीं है.