4 பிப்ரவரி, 2026

Codex ஹார்னஸை திறத்தல்: ஆப் சர்வரை எவ்வாறு உருவாக்கினோம்

Celia Chen, தொழில்நுட்ப பணியாளர் குழுவின் உறுப்பினர்

ஏற்றுகிறது…

OpenAI-யின் கோடிங் ஏஜென்ட் Codex பல்வேறு மேடைகளில் கிடைக்கிறது: வலை செயலி⁠(புதிய சாளரத்தில் திறக்கும்), CLI⁠(புதிய சாளரத்தில் திறக்கும்), IDE நீட்சிகள்⁠(புதிய சாளரத்தில் திறக்கும்), மற்றும் புதிய Codex macOS செயலி. உள்ளே பார்த்தால், அவை அனைத்தும் ஒரே Codex harness மூலம் இயக்கப்படுகின்றன—அனைத்து Codex அனுபவங்களுக்கும் அடிப்படையாக இருக்கும் ஏஜென்ட் லூப் மற்றும் தர்க்கம். அவற்றுக்கிடையேயான முக்கியமான தொடர்பு என்ன? Codex App Server⁠(புதிய சாளரத்தில் திறக்கும்), வாடிக்கையாளர் நட்பு, இருதிசை JSON-RPC¹ API.

இந்த பதிவில், Codex ஆப் சர்வரை அறிமுகப்படுத்துவோம்; உங்கள் பயனர்கள் தங்கள் பணிப்பாய்வுகளை மேலும் திறம்படச் செய்ய, Codex இன் திறன்களை உங்கள் தயாரிப்பில் கொண்டு வர சிறந்த வழிகள் குறித்து இதுவரை நாங்கள் கற்றுக்கொண்டவற்றைப் பகிர்வோம். நாங்கள் ஆப் சர்வரின் கட்டமைப்பு மற்றும் நெறிமுறையை மற்றும் அது வெவ்வேறு Codex பரப்புகளுடன் எவ்வாறு ஒருங்கிணைக்கிறது என்பதையும், Codex ஐப் பயன்படுத்துவதற்கான உதவிக்குறிப்புகளையும் உள்ளடக்குவோம், நீங்கள் Codex ஐ ஒரு குறியீடு மதிப்பாய்வாளராகவோ, SRE ஏஜென்ட்டாகவோ அல்லது குறியீட்டு உதவியாளராகவோ மாற்ற விரும்பினால்.

ஆப் சர்வர் (செயலி சேவையகம்) இன் தோற்றம்

கட்டிடக்கலையில் ஆழமாக இறங்குவதற்கு முன், ஆப் சர்வர் இன் பின்னணிக் கதையை அறிந்துகொள்வது பயனுள்ளதாக இருக்கும். ஆரம்பத்தில், ஆப் சர்வர் தயாரிப்புகள் முழுவதும் Codex harness ஐ மீண்டும் பயன்படுத்துவதற்கான ஒரு நடைமுறை வழியாக இருந்தது, அது படிப்படியாக எங்கள் நிலையான நெறிமுறையாக மாறியது.

Codex CLI ஒரு TUI (terminal user interface) ஆகத் தொடங்கியது, அதாவது Codex டெர்மினல் மூலம் அணுகப்படுகிறது. நாங்கள் VS Code நீட்டிப்பை (Codex ஏஜென்ட்களுடன் தொடர்பு கொள்ள அதிக IDE-நட்பு வழி) உருவாக்கியபோது, IDE UI-இல் அதே ஏஜென்ட் லூப்பை இயக்குவதற்காக அதே ஹார்னஸ்ஸை பயன்படுத்த ஒரு வழி தேவைப்பட்டது, அதை மீண்டும் செயல்படுத்தாமல். அதன் பொருள் request/response ஐத் தாண்டிய செறிவான தொடர்பு முறைகளை ஆதரிப்பதாகும்; உதாரணமாக, வர்க்ஸ்பேஸை ஆராய்வது, ஏஜென்ட் காரணம் கூறும் போது முன்னேற்றத்தை ஸ்ட்ரீம் செய்வது, மற்றும் வேறுபாடுகளை வெளியிடுவது. நாங்கள் முதலில் Codex-ஐ MCP சர்வராக வெளிப்படுத்துவதில்⁠(புதிய சாளரத்தில் திறக்கும்) பரிசோதனை செய்தோம், ஆனால் VS Code க்கு பொருத்தமான MCP அர்த்தவியலை பராமரிப்பது சிரமமாக இருந்தது. அதற்குப் பதிலாக, TUI loop ஐ பிரதிபலிக்கும் JSON-RPC நெறிமுறையை நாங்கள் அறிமுகப்படுத்தினோம், இது ஆப் சர்வர்-இன் அதிகாரப்பூர்வமற்ற முதல் பதிப்பு⁠(புதிய சாளரத்தில் திறக்கும்) ஆக மாறியது. அந்த நேரத்தில், பிற வாடிக்கையாளர்கள் App Server மீது சார்ந்திருப்பார்கள் என்று நாங்கள் எதிர்பார்க்கவில்லை, எனவே அது ஒரு நிலையான API ஆக வடிவமைக்கப்படவில்லை.

அடுத்த சில மாதங்களில் Codex ஏற்றுக்கொள்ளல் அதிகரிக்கும்போது, உள்நாட்டு குழுக்களும் வெளிப்புற கூட்டாளர்களும் தங்கள் பயனர்களின் மென்பொருள் மேம்பாட்டு பணிப்பாய்வுகளை விரைவுபடுத்துவதற்காக அதே ஹார்னஸை தங்கள் சொந்த தயாரிப்புகளில் உட்பொதிக்க விரும்பினர். உதாரணமாக, JetBrains மற்றும் Xcode IDE தரத்திலான ஏஜென்ட் அனுபவத்தை விரும்பின, அதே நேரத்தில் Codex டெஸ்க்டாப் பயன்பாடு பல Codex ஏஜென்ட்களை ஒரே நேரத்தில் ஒருங்கிணைக்க வேண்டியது. அந்த தேவைகள் எங்கள் தயாரிப்புகளும் கூட்டாளர் ஒருங்கிணைப்புகளும் காலப்போக்கில் பாதுகாப்பாக நம்பியிருக்கக்கூடிய ஒரு தள பரப்பை வடிவமைக்க எங்களைத் தூண்டின. இது ஒருங்கிணைக்க எளிதாகவும் பின்னோக்கி இணக்கத்தன்மை கொண்டதாகவும் இருக்க வேண்டும், அதாவது ஏற்கனவே உள்ள கிளையண்ட்களை பாதிக்காமல் நாங்கள் நெறிமுறையை மேம்படுத்த முடியும்.

அடுத்து, வெவ்வேறு கிளையண்டுகள் ஒரே ஹார்னஸ்ஸைப் பயன்படுத்த முடியும் வகையில், கட்டமைப்பு மற்றும் நெறிமுறையை எவ்வாறு வடிவமைத்தோம் என்பதைப் பற்றிப் பார்ப்போம்.

Codex ஹார்னஸின் உள்ளே

முதலில், Codex harness இன் உள்ளே என்ன இருக்கிறது மற்றும் Codex ஆப் சர்வர் அதை வாடிக்கையாளர்களுக்கு எவ்வாறு வெளிப்படுத்துகிறது என்பதை நெருக்கமாகப் பார்ப்போம். எங்கள் கடந்த Codex வலைப்பதிவில், பயனர், மாடல் மற்றும் கருவிகளுக்கிடையிலான தொடர்பை ஒருங்கிணைக்கும் மைய ஏஜென்ட் லூப்பை நாங்கள் பகுத்து விளக்கியோம். இது Codex harness இன் மைய தர்க்கம், ஆனால் முழு ஏஜென்ட் அனுபவத்தில் இன்னும் பல உள்ளது:

1. த்ரெட் வாழ்க்கைச் சுழற்சி மற்றும் நிலைத்தன்மை. ஒரு thread என்பது ஒரு பயனர் மற்றும் ஒரு Codex ஏஜென்ட் இடையிலான உரையாடல். Codex த்ரெட்களை உருவாக்குதல், மீண்டும் தொடர்தல், பிரித்தல் (fork), மற்றும் காப்பகப்படுத்தல் ஆகியவற்றை ஆதரிக்கிறது; இதன் மூலம் கிளையண்ட்கள் மீண்டும் இணைந்து ஒரே மாதிரியான காலவரிசையை துல்லியமாகக் காண முடியும்.

2. கட்டமைப்பு மற்றும் அங்கீகாரம். Codex உள்ளமைவை ஏற்றுகிறது, இயல்புநிலைகளை நிர்வகிக்கிறது, மேலும் சான்றளிப்பு நிலையை உள்ளடக்கிய “Sign in with ChatGPT” போன்ற அங்கீகார ஓட்டங்களை இயக்குகிறது.

3. கருவி செயலாக்கம் மற்றும் நீட்டிப்புகள். Codex ஒரு சாண்ட்பாக்ஸில் shell/file கருவிகளை இயக்குகிறது மற்றும் MCP servers மற்றும் skills போன்ற ஒருங்கிணைப்புகளை இணைக்கிறது, இதனால் அவை ஒரே மாதிரியான கொள்கை மாடலின் கீழ் ஏஜென்ட் லூப்பில் பங்கேற்க முடியும்.

இங்கே நாம் குறிப்பிட்ட அனைத்து ஏஜென்ட் தர்க்கம், மைய ஏஜென்ட் லூப்பை உட்பட, Codex CLI கோட்பேஸின் “Codex core⁠(புதிய சாளரத்தில் திறக்கும்)” எனப்படும் பகுதியில் உள்ளது. Codex கோர் என்பது அனைத்து முகவர் குறியீடும் வாழும் ஒரு நூலகம் மற்றும் ஏஜென்ட் சுழற்சியை இயக்கவும் ஒரு Codex தொடரிழையின் (உரையாடலின்) நிலைத்தன்மையை நிர்வகிக்கவும் சுழற்றக்கூடிய இயக்க நேரம் ஆகும்.

பயனுள்ளதாக இருக்க, Codex harness வாடிக்கையாளர்களால் அணுகக்கூடியதாக இருக்க வேண்டும். அதற்காகத்தான் ஆப் சர்வர் வருகிறது.

“App server process flow” என்ற தலைப்பில் வரைபடம். ஒரு கிளையன்ட் JSON-RPC செய்திகளை ஒரு stdio ரீடருக்கு அனுப்புகிறது, இது Codex செய்தி செயலிக்கு கோரிக்கைகளை அனுப்புகிறது. ப்ராசஸர், லுக்கப் திரெட்கள், திரெட் ஹேண்டில்கள், சமர்ப்பிக்கப்பட்ட கோரிக்கைகள், மற்றும் நிகழ்வுகள்/புதுப்பிப்புகள் மூலம் ஒரு திரெட் மேலாளர் மற்றும் மைய திரெடுடன் தொடர்பு கொண்டு, பின்னர் பதில்களை வாடிக்கையாளருக்கு திருப்பி அனுப்புகிறது.

ஆப் சர்வர் என்பது கிளையண்ட் மற்றும் சர்வர் இடையிலான JSON-RPC நெறிமுறையும் Codex கோர் த்ரெட்களை ஹோஸ்ட் செய்யும் நீண்டகால செயல்முறையும் ஆகும். மேலே உள்ள வரைபடத்திலிருந்து நாம் காணக்கூடியது போல, ஒரு ஆப் சர்வர் செயல்முறையில் நான்கு முக்கிய கூறுகள் உள்ளன: stdio reader, Codex message processor, thread manager, மற்றும் core threads. த்ரெட் மேலாளர் ஒவ்வொரு த்ரெட்டிற்கும் ஒரு கோர் செஷனை தொடங்குகிறது, பின்னர் Codex செய்தி செயலி ஒவ்வொரு கோர் செஷனுடனும் நேரடியாக தொடர்பு கொண்டு வாடிக்கையாளர் கோரிக்கைகளை சமர்ப்பித்து புதுப்பிப்புகளைப் பெறுகிறது.

ஒரு கிளையன்ட் கோரிக்கை பல நிகழ்வு புதுப்பிப்புகளை உருவாக்க முடியும், மேலும் இந்த விரிவான நிகழ்வுகள் ஆப் சர்வர் இன் மேல் ஒரு வளமான UI-ஐ உருவாக்க எங்களுக்கு அனுமதிக்கின்றன. மேலும், stdio reader மற்றும் Codex message processor ஆகியவை கிளையண்ட் மற்றும் Codex core threads இடையிலான மொழிபெயர்ப்பு அடுக்காக செயல்படுகின்றன. அவை வாடிக்கையாளர் JSON-RPC கோரிக்கைகளை Codex core செயல்பாடுகளாக மொழிபெயர்க்கின்றன, Codex core இன் உள்நாட்டு நிகழ்வு ஸ்ட்ரீமைக் கேட்டு, பின்னர் அந்த குறைந்த-நிலை நிகழ்வுகளை சிறிய தொகுதி நிலையான, UI-க்கு தயாரான JSON-RPC அறிவிப்புகளாக மாற்றுகின்றன.

கிளையண்ட் மற்றும் ஆப் சர்வர் இடையிலான JSON-RPC நெறிமுறை முழுமையாக இருதிசை தொடர்புடையது. ஒரு சாதாரண திரெடில் ஒரு கிளையண்ட் கோரிக்கையும் பல சர்வர் அறிவிப்புகளும் உள்ளன. மேலும், ஏஜென்டுக்கு ஒப்புதல் போன்ற உள்ளீடு தேவைப்படும் போது, சர்வர் கோரிக்கைகளைத் தொடங்க முடியும், பின்னர் கிளையண்ட் பதிலளிக்கும் வரை அந்த செயல்முறையை நிறுத்த முடியும்.

உரையாடல் அடிப்படை கூறுகள்

அடுத்து, ஆப் சர்வர் நெறிமுறையின் கட்டுமானத் தொகுதிகளான உரையாடல் ஆதிமூலங்களைப் பிரிப்போம். ஏஜென்ட் லூப்பிற்கான API-ஐ வடிவமைப்பது சிக்கலானது, ஏனெனில் பயனர்/ஏஜென்ட் தொடர்பு ஒரு எளிய கோரிக்கை/பதில் அல்ல. ஒரு பயனர் கோரிக்கை, கிளையன்ட் நம்பகமாக பிரதிநிதித்துவப்படுத்த வேண்டிய கட்டமைக்கப்பட்ட செயல்களின் தொடராக விரியலாம்: பயனரின் உள்ளீடு, ஏஜென்டின் படிப்படியான முன்னேற்றம், வழியிலேயே உருவாக்கப்படும் கலைப்பொருட்கள் (எ.கா., வேறுபாடுகள்). அந்த தொடர்பு ஸ்ட்ரீமை UI களில் எளிதாக ஒருங்கிணைக்கவும், பல்வேறு UI களிலும் உறுதியாக செயல்படவும், தெளிவான எல்லைகள் மற்றும் வாழ்க்கைச் சுழற்சிகளுடன் மூன்று முக்கிய அடிப்படை கூறுகளை நாங்கள் தேர்ந்தெடுத்துள்ளோம்:

1. உருப்படி: Codex இல் ஒரு உருப்படி என்பது உள்ளீடு/வெளியீட்டின் அணு அலகாகும். உருப்படிகள் வகைப்படுத்தப்பட்டுள்ளன (எ.கா., பயனர் செய்தி, ஏஜென்ட் செய்தி, கருவி செயல்படுத்தல், ஒப்புதல் கோரிக்கை, வேறுபாடு) மற்றும் ஒவ்வொன்றுக்கும் வெளிப்படையான வாழ்க்கைச் சுழற்சி உள்ளது.

item/started உருப்படி தொடங்கும் போது
விருப்பமான item/*/delta நிகழ்வுகள் உள்ளடக்க ஸ்ட்ரீம்களாக (ஸ்ட்ரீமிங் உருப்படி வகைகளுக்காக)
item/completed உருப்படி அதன் இறுதி payload உடன் முடிவடையும் போது

இந்த வாழ்க்கைச் சுழற்சி, வாடிக்கையாளர்களை started இல் உடனடியாக ரெண்டரிங் செய்ய தொடங்க அனுமதிக்கிறது, delta இல் படிப்படியான புதுப்பிப்புகளை ஸ்ட்ரீம் செய்யவும், completed இல் இறுதிப்படுத்தவும் முடிக்கிறது.

2. Turn: ஒரு திருப்பம் என்பது பயனர் உள்ளீட்டால் தொடங்கப்பட்ட ஏஜென்ட் வேலையின் ஒரு அலகு ஆகும். கிளையன்ட் ஒரு உள்ளீட்டைச் சமர்ப்பிக்கும் போது (உதாரணமாக, “சோதனைகளை இயக்கி தோல்விகளைச் சுருக்கமாகக் கூறவும்”) இது தொடங்கி, அந்த உள்ளீட்டிற்கான வெளியீடுகளை ஏஜென்ட் உருவாக்கி முடிக்கும் போது இது முடிகிறது. ஒரு திருப்பம் என்பது வழியில் உற்பத்தி செய்யப்படும் இடைநிலை படிகள் மற்றும் வெளியீடுகளைக் குறிக்கும் உருப்படிகளின் வரிசையைக் கொண்டுள்ளது.

3. Thread: ஒரு த்ரெட் என்பது பயனர் மற்றும் ஒரு ஏஜென்ட் இடையே நடைபெறும் தொடர்ச்சியான Codex அமர்வுக்கான நிலைத்த கொள்கலன் ஆகும். இதில் பல முறை திருப்பங்கள் உள்ளன. த்ரெட்களை உருவாக்கலாம், மீண்டும் தொடங்கலாம், பிரிக்கலாம், மற்றும் காப்பகப்படுத்தலாம். த்ரெட் வரலாறு நிலைத்துப் பாதுகாக்கப்படுகிறது, எனவே வாடிக்கையாளர்கள் மீண்டும் இணைந்து ஒரே மாதிரியான காலவரிசையை காட்சிப்படுத்த முடியும்.

இப்போது, primitives மூலம் உரையாடல் பிரதிநிதித்துவப்படுத்தப்படும் நிலையில், ஒரு கிளையன்ட் மற்றும் ஒரு ஏஜென்ட் இடையிலான எளிமைப்படுத்தப்பட்ட உரையாடலைப் பார்ப்போம்:

"Client-server protocol message flow: Initialization handshake (கிளையன்ட்-சர்வர் நெறிமுறை செய்தி ஓட்டம்: துவக்க கைகுலுக்கல்)" என்று பெயரிடப்பட்ட வரைபடம். ஒரு வாடிக்கையாளர் clientInfo உடன் ஒரு ஆரம்ப கோரிக்கையை சேவையகத்திற்கு அனுப்புகிறார். சர்வர் “my_client/1.0.” என்ற userAgent string ஐ கொண்ட முடிவு நிகழ்வுடன் பதிலளிக்கிறது.

உரையாடலின் தொடக்கத்தில், கிளையன்ட் மற்றும் சர்வர் 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}

“Client-server protocol message flow: Thread & turn lifecycle.” என்ற தலைப்புடைய வரைபடம். வாடிக்கையாளர் 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”). வாடிக்கையாளர் அங்கீகார நிகழ்வை (அனுமதி/மறுப்பு) திருப்பி அனுப்புகிறார். பின்னர் சேவையகம் item/completed ஐ வெளியிடுகிறது, இது கட்டளை செயல்படுத்தலைக் காட்டுகிறது ("pnpm test").

கருவி அழைப்புகளும் உருப்படிகளாக வாடிக்கையாளருக்கு மீண்டும் அனுப்பப்படுகின்றன. மேலும், சர்வர் கோரிக்கையை அனுப்பி ஒரு செயலை இயக்குவதற்கு முன், சர்வர் கிளையண்டின் அங்கீகாரத்தை கேட்கலாம். அனுமதி செயல்முறை, வாடிக்கையாளர் “allow” அல்லது “deny” என்று பதிலளிக்கும் வரை அந்த முறைநிலை நிறுத்தப்படும். VS Code நீட்டிப்பில் அங்கீகார ஓட்டம் பின்வருமாறு இருக்கும்:

டார்க் தீம் இடைமுகத்தில் அனுமதி ப்ராம்ப்ட், "இந்த வர்க்ஸ்பேஸில் pnpm டெஸ்ட் இயக்க என்னை அனுமதிக்க விரும்புகிறீர்களா?" என்று கேட்கிறது. இது விருப்பங்களை பட்டியலிடுகிறது: 1) ஆம், 2) pnpm test இல் தொடங்கும் கட்டளைகளுக்கு ஆம் மற்றும் மீண்டும் கேட்க வேண்டாம், 3) இல்லை, கீழே Submit பொத்தானுடன்.

“Client-server protocol message flow: Streaming agent message flow” என்ற தலைப்புடைய வரைபடம். சர்வர் உதவியாளர் செய்தியை பகுதிகளாக ஸ்ட்ரீம் செய்கிறது: item/started, இரண்டு agentMessage/delta நிகழ்வுகள் (“மூன்று சோதனைகளை இயக்கியது.”, “அனைத்தும் தேர்ச்சி பெற்றது”), பின்னர் உருப்படி/முடிந்தது. முறையை turn/completed உடன் முடிக்கவும்.

இறுதியில், சர்வர் ஒரு ஏஜென்ட் செய்தியை அனுப்பி, பின்னர் turn/completed உடன் சுற்றத்தை முடிக்கிறது. ஏஜென்ட் செய்தி டெல்டா நிகழ்வுகள் ஸ்ட்ரீம், செய்தி item/completed மூலம் இறுதிப்படுத்தப்படும் வரை, செய்தியின் பகுதிகளை மீண்டும் அனுப்பும்.

வாசிப்புத் திறனை மேம்படுத்துவதற்காக வரைபடத்தில் உள்ள செய்திகள் எளிமைப்படுத்தப்பட்டுள்ளன. நீங்கள் முழு திருப்பத்திற்கான JSON-ஐப் பார்க்க விரும்பினால், Codex CLI ரெபோவில் இருந்து டெஸ்ட் கிளையண்டை இயக்கவும்:

Bash

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

வாடிக்கையாளர்களுடன் ஒருங்கிணைப்பு

இப்போது, ஆப் சர்வர் வழியாக வெவ்வேறு கிளையன்ட் சர்ஃபேஸ்கள் Codex-ஐ எவ்வாறு உட்பொதிக்கின்றன என்பதை நாங்கள் பார்ப்போம். நாங்கள் மூன்று முறைகளைப் பற்றி பேசுவோம்: உள்ளூர் பயன்பாடுகள் மற்றும் IDE-கள், Codex வெப் ரன்டைம், மற்றும் TUI.

“Codex clients integrated with Codex harness via app server” என்ற தலைப்புடைய வரைபடம். முதல்-தரப்பு கிளையண்ட்கள் (Codex Desktop App, TUI/CLI, Web Runtime) மற்றும் மூன்றாம்-தரப்பு ஒருங்கிணைப்புகள் (JetBrains IDEs, VS Code, Xcode) JSON-RPC அழைப்புகள் மூலம் Codex harness உடன் தொடர்பு கொள்கின்றன.

மூன்றிலும், போக்குவரத்து JSON-RPC stdio (JSONL) வழியாக நடைபெறுகிறது. JSON-RPC உங்கள் விருப்பமான மொழியில் கிளையன்ட் பைண்டிங்ஸை உருவாக்க எளிதாக்குகிறது. Codex மேற்பரப்புகள் மற்றும் கூட்டாளர் ஒருங்கிணைப்புகள் Go, Python, TypeScript, Swift, மற்றும் Kotlin போன்ற மொழிகளில் ஆப் சர்வர் கிளையண்ட்களை செயல்படுத்தியுள்ளன. TypeScript க்கு, Rust நெறிமுறையிலிருந்து நேரடியாக வரையறைகளை உருவாக்க, இதை இயக்கவும்:

Bash

1codex app-server generate-ts

மற்ற மொழிகளுக்காக, நீங்கள் ஒரு JSON ஸ்கீமா பண்டிலை உருவாக்கி, அதை உங்கள் விருப்பமான கோடு ஜெனரேட்டருக்குள் வழங்க, இயக்கவும்:

Bash

1codex app-server generate-json-schema

உள்ளூர் செயலிகள் & IDEகள்

Codex நீட்டிப்பு இயங்கும் நிலையில் உள்ள VS Code இன் திரைபடம். ஒரு Rust டெஸ்ட் கோப்பு திறந்திருக்கிறது, அதன் கீழே Codex பேனல் fmt மற்றும் cargo test -p codex-app-server மட்டும் இயக்கப்படுவதை விவரிக்கிறது, ஃபார்மாட்டிங் மற்றும் டெஸ்ட்கள் நடைபெற்று கொண்டிருக்கின்றன என்று தெரிவிக்கிறது, இறுதி pass/fail முடிவுக்காக காத்திருக்கிறது.

உள்ளூர் கிளையண்ட்கள் பொதுவாக ஒரு பிளாட்ஃபார்ம் சிறப்பான ஆப் சர்வர் பைனரியை தொகுப்பதோ அல்லது பெறுவதோ செய்து, அதை நீண்ட நேரம் இயங்கும் குழந்தை செயல்முறையாக தொடங்கி, JSON-RPC க்காக இருதிசை stdio சேனலை திறந்தவாறே வைத்திருக்கும். எங்கள் VS Code நீட்டிப்பு மற்றும் டெஸ்க்டாப் ஆப்பில், உதாரணமாக, அனுப்பப்படும் ஆர்டிஃபாக்ட் பிளாட்ஃபார்ம்-சார்ந்த Codex பைனரியை உள்ளடக்குகிறது மற்றும் சோதிக்கப்பட்ட ஒரு பதிப்பில் பின் செய்யப்பட்டுள்ளது, எனவே கிளையண்ட் எப்போதும் நாங்கள் சரிபார்த்த துல்லியமான பிட்ஸ்களையே இயக்குகிறது.

ஒவ்வொரு ஒருங்கிணைப்பும் வாடிக்கையாளர் புதுப்பிப்புகளை அடிக்கடி அனுப்ப முடியாது. Xcode போன்ற சில கூட்டாளர்கள், கிளையண்டை நிலையாக வைத்துக்கொண்டு, தேவையான போது புதியஆப் சர்வர் பைனரியை சுட்டிக்காட்ட அனுமதிப்பதன் மூலம் வெளியீட்டு சுழற்சிகளை பிரித்துவைக்கின்றனர். அந்த வழியில் அவர்கள் சர்வர்-பக்க மேம்பாடுகளை (உதாரணமாக, Codex core இல் சிறந்த தானியங்கி-சுருக்கம் அல்லது புதிதாக ஆதரிக்கப்படும் config keys) ஏற்றுக்கொள்ளவும், கிளையண்ட் வெளியீட்டை காத்திருக்காமல் பிழை திருத்தங்களை வெளியிடவும் முடியும். ஆப் சர்வர் இன் JSON-RPC மேற்பரப்பு பின்நோக்கி இணக்கத்தன்மையுடன் வடிவமைக்கப்பட்டுள்ளது, எனவே பழைய கிளையண்ட்கள் புதிய சர்வர்களுடன் பாதுகாப்பாக தொடர்புகொள்ள முடியும்.

Codex வெப்

“Update login success message” என்ற தலைப்பிலான ஒரு புதுப்பிப்பைக் காட்டும் Codex வலை இடைமுகத்தின் ஸ்கிரீன்ஷாட். இடது பானல் மாற்றங்கள், சோதனைகள் மற்றும் மாற்றியமைக்கப்பட்ட கோப்புகளை சுருக்கமாகக் காட்டுகிறது, வலது பானல் login.rs க்கான குறியீட்டு வேறுபாட்டை, புதுப்பிக்கப்பட்ட உள்நுழைவு வெற்றிச் செய்தி சொற்றொடருடன், காட்டுகிறது.

Codex வலை Codex harness ஐ பயன்படுத்துகிறது, ஆனால் அதை ஒரு container சூழலில் இயக்குகிறது. ஒரு பணியாளர் செக்-அவுட் செய்யப்பட்ட வர்க்ஸ்பேஸுடன் ஒரு கன்டெய்னரை தயாரித்து, அதில் ஆப் சர்வர் பைனரி இயக்கி, stdio² வழியாக நீண்டகால JSON-RPC சேனலை பராமரிக்கிறார். வலை ஆப் (பயனரின் உலாவி டேபில் இயங்குவது) HTTP மற்றும் SSE வழியாக Codex பின்தளத்துடன் தொடர்பு கொள்கிறது, இது வொர்க்கர் உருவாக்கும் பணிச் செயல்களை ஸ்ட்ரீம் செய்கிறது. இது உலாவி-பக்க UI-ஐ இலகுவாக வைத்துக்கொண்டாலும், டெஸ்க்டாப் மற்றும் வலை தளங்களில் ஒரே மாதிரியான இயக்க நேரத்தை வழங்குகிறது.

வலை அமர்வுகள் தற்காலிகமானவை (தாவல்கள் மூடப்படும், நெட்வொர்க்கள் துண்டிக்கப்படும்) என்பதால், நீண்டகாலப் பணிகளுக்கான உண்மையான ஆதாரமாக வலை செயலி இருக்க முடியாது. சர்வரில் நிலையும் முன்னேற்றமும் வைத்திருப்பது, டேப் மறைந்தாலும் வேலை தொடர்ந்து நடைபெறும். ஸ்ட்ரீமிங் ப்ரொடோகால் மற்றும் சேமிக்கப்பட்ட த்ரெட் செஷன்கள், கிளையண்டில் நிலையை மீண்டும் உருவாக்காமல், ஒரு புதிய செஷன் மீண்டும் இணைந்து, முன்பு நிறுத்திய இடத்திலிருந்து தொடரவும், மற்றும் முன்னேற்றத்தை இழக்காமல் பிடித்துக்கொள்ளவும் எளிதாக்குகின்றன.

TUI/Codex CLI

Codex CLI இயங்கும் ஒரு டெர்மினலின் திரைபடம். இது OpenAI Codex பேனரை gpt-5.2-codex மாடலுடன் காட்டுகிறது நடுத்தரம், “explain app server to me, (எனக்கு app server ஐ விளக்கவும்)” என்ற பயனர் கட்டளை, மற்றும் “Working” நிலை. கீழே, “@filename க்கான சோதனைகளை எழுதுங்கள்” என்ற பரிந்துரை தோன்றும், குறுக்குவழிகளுக்கான விருப்பங்களுடன்.

வரலாற்று ரீதியாக, TUI என்பது ஏஜென்ட் லூப்புடன் அதே செயல்முறையில் இயங்கிய ஒரு “நேட்டிவ்” கிளையண்ட் ஆகும், இது ஆப் சர்வர் நெறிமுறைக்கு பதிலாக Rust கோர் வகைகளுடன் நேரடியாக தொடர்பு கொண்டது. அது ஆரம்பக்கட்ட மீளச்செயலாக்கத்தை வேகமாக்கியது, ஆனால் அது TUI ஐ ஒரு சிறப்பு நிலை மேற்பரப்பாகவும் மாற்றியது.

இப்போது ஆப் சர்வர் உள்ளது என்பதால், அதை எந்த மற்ற client போலவும் செயல்படச் செய்ய TUI-ஐ மறுசீரமைக்க⁠(புதிய சாளரத்தில் திறக்கும்) திட்டமிட்டுள்ளோம்: App Server child process ஐ தொடங்கவும், stdio வழியாக JSON-RPC-ஐ பேசவும், அதே ஸ்ட்ரீமிங் நிகழ்வுகள் மற்றும் அனுமதிகளை ரெண்டர் செய்யவும். இது TUI தொலைதூர கணினியில் இயங்கும் Codex சேவையகத்துடன் இணைக்கக்கூடிய பணிப்பாய்வுகளைத் திறக்கிறது, ஏஜென்ட்டை கணினிக்கு அருகில் வைத்திருக்கிறது மற்றும் மடிக்கணினி துண்டிக்கப்பட்டாலும் கூட வேலையைத் தொடர்கிறது, அதே நேரத்தில் நேரடி புதுப்பிப்புகள் மற்றும் கட்டுப்பாடுகளை உள்ளூரில் வழங்குகிறது.

சரியான நெறிமுறையைத் தேர்வு செய்வது

Codex ஆப் சர்வர் இனிமேல் நாம் பராமரிக்கும் முதன்மை ஒருங்கிணைப்பு முறையாக இருக்கும், ஆனால் குறைந்த செயல்பாடுகளுடன் பிற முறைகளும் உள்ளன. இயல்பாக, Codex உடன் ஒருங்கிணைக்க வாடிக்கையாளர்கள் Codex ஆப் சர்வர் ஐ பயன்படுத்துமாறு நாங்கள் பரிந்துரைக்கிறோம், ஆனால் வேறு ஒருங்கிணைப்பு முறைகளையும் ஆராய்ந்து, அவற்றின் நன்மை-தீமைகளைப் புரிந்துகொள்வது பயனுள்ளதாக இருக்கும். Codex ஐ இயக்குவதற்கான மிகவும் பொதுவான வழிகள் மற்றும் ஒவ்வொன்றும் எப்போது ஒரு நல்ல பொருத்தமாக இருக்கலாம் என்பவை கீழே உள்ளன.

JSON-RPC புரோடோக்கால்கள்

Codex MCP சேவையகமாக

codex mcp-server⁠(புதிய சாளரத்தில் திறக்கும்) ஐ இயக்கி, stdio சர்வர்களை ஆதரிக்கும் எந்த MCP கிளையண்டிலிருந்தும் (எ.கா., OpenAI Agents SDK⁠(புதிய சாளரத்தில் திறக்கும்)) இணைக்கவும். உங்களிடம் ஏற்கனவே MCP-அடிப்படையிலான பணிப்பாய்வு இருந்தால், Codex-ஐ அழைக்கக்கூடிய கருவியாக அழைக்க விரும்பினால், இது ஒரு நல்ல பொருத்தம். குறைபாடு என்னவென்றால், நீங்கள் MCP வெளிப்படுத்துவதையே பெறுகிறீர்கள், எனவே வளமான செஷன் அர்த்தவியலை (எ.கா., வேறுபாடு புதுப்பிப்புகள்) சார்ந்த Codex-சிறப்பான தொடர்புகள் MCP எண்ட்பாயிண்ட் வழியாக சுத்தமாக வரைபடமாக முடியாது.

குறுக்கு-வழங்குநர் ஏஜென்ட் ஹார்னஸ் புரோட்டோகால்கள்

சில எகோசிஸ்டம்கள் பல மாடல் வழங்குநர்கள் மற்றும் ரன்டைம்களை இலக்காகக் கொண்ட ஒரு இடைமுகத்தை வழங்குகின்றன. நீங்கள் பல ஏஜன்ட்களை ஒருங்கிணைக்கும் ஒரு அப்ஸ்ட்ராக்ஷனை விரும்பினால், இது ஒரு நல்ல பொருத்தமாக இருக்கலாம். இவற்றின் பரிமாற்றம் என்னவென்றால், இந்த நெறிமுறைகள் பெரும்பாலும் திறன்களின் பொதுவான துணைத் தொகுப்பில் ஒன்றிணைந்து விடுகின்றன, இதனால் வழங்குநர்-சார்ந்த கருவி மற்றும் அமர்வு அர்த்தவியல் முக்கியமானபோது, மேலும் வளமான தொடர்பாடல்களை பிரதிநிதித்துவப்படுத்துவது கடினமாகலாம். இந்த துறை வேகமாக மாறிக்கொண்டிருக்கிறது, மேலும் நாங்கள் நிஜ உலக ஏஜென்ட் பணிச்சூழல்களை பிரதிநிதித்துவப்படுத்த சிறந்த அடிப்படை கூறுகளை கண்டறியும் போது, மேலும் பொதுவான தரநிலைகள் உருவாகும் என்று எதிர்பார்க்கிறோம் (skills⁠(புதிய சாளரத்தில் திறக்கும்) இதற்கான ஒரு சிறந்த உதாரணம்).

Codex செயலி சேவையகம்

நீங்கள் முழு Codex ஹார்னஸை நிலையான, UI-க்கு ஏற்ற நிகழ்வு ஸ்ட்ரீமாக வெளிப்படுத்த விரும்பினால், ஆப் சர்வர்-ஐத் தேர்ந்தெடுக்கவும். நீங்கள் ஏஜென்ட் லூப்பின் முழு செயல்பாடுகளையும், ChatGPT மூலம் உள்நுழைவு, மாடல் கண்டறிதல், மற்றும் கட்டமைப்பு மேலாண்மை போன்ற பிற ஆதரவு அம்சங்களையும் பெறுவீர்கள். முக்கிய செலவு ஒருங்கிணைப்பு பணியே, ஏனெனில் உங்கள் மொழியில் கிளையன்ட்-பக்க JSON-RPC பைண்டிங்கை நீங்கள் உருவாக்க வேண்டும். நடைமுறையில், இருப்பினும், நீங்கள் JSON ஸ்கீமா மற்றும் ஆவணங்களை வழங்கினால், Codex பெரும்பாலான கடினமான பணிகளைச் செய்ய முடியும். நாங்கள் பணியாற்றிய பல குழுக்கள் Codex-ஐ பயன்படுத்தி விரைவாக செயல்படும் ஒருங்கிணைப்பை உருவாக்க முடிந்தன.

Codex ஐ உட்பொதிக்க மற்ற வழிகள்

Codex Exec⁠(புதிய சாளரத்தில் திறக்கும்)

ஒருமுறை செய்யும் பணிகளுக்கும் CI இயக்கங்களுக்கும் இலகுரக, ஸ்கிரிப்ட் செய்யக்கூடிய CLI முறை. ஆட்டோமேஷன் மற்றும் பைப்லைன்களுக்கு இது நல்ல பொருத்தம், இதில் நீங்கள் ஒரே கட்டளையை இடையீடின்றி முழுமையாக இயங்கச் செய்ய, லாக்களுக்காக ஸ்ட்ரக்ச்சர்டு அவுட்புட்ஸ் ஸ்ட்ரீம் செய்ய, மேலும் தெளிவான வெற்றி அல்லது தோல்வி சிக்னலுடன் வெளியேற விரும்புகிறீர்கள்.

Codex SDK⁠(புதிய சாளரத்தில் திறக்கும்)

உங்கள் சொந்த பயன்பாட்டிற்குள் இருந்து உள்ளூர் Codex ஏஜன்ட்களை நிரல்முறையாக கட்டுப்படுத்துவதற்கான ஒரு TypeScript நூலகம். சர்வர்-சைடு கருவிகள் மற்றும் பணிப்பாய்வுகளுக்காக, தனியாக ஒரு JSON-RPC கிளையண்ட் உருவாக்காமல், நேடிவ் நூலக இடைமுகம் தேவைப்பட்டால், இது சிறந்தது. இது ஆப் சர்வர்-ஐ விட முன்பே வெளியிடப்பட்டதால், இது தற்போது குறைவான மொழிகளையும் குறைந்த அளவிலான அம்சப் பரப்பளவையும் ஆதரிக்கிறது. டெவலப்பர் ஆர்வம் இருந்தால், JSON-RPC பிணைப்புகளை எழுதாமல் குழுக்கள் ஹார்னஸ் மேற்பரப்பை அதிகமாக உள்ளடக்கும் வகையில், ஆப் சர்வர் நெறிமுறையை உள்ளடக்கிய கூடுதல் SDKகளை நாங்கள் சேர்க்கலாம்.

இதை முன்னெடுத்து செல்கிறோம்

இந்த பதிவில், ஏஜென்ட்களுடன் தொடர்பு கொள்ள ஒரு புதிய தரநிலையை வடிவமைப்பதற்கான எங்கள் அணுகுமுறையையும், Codex harness ஐ நிலையான, வாடிக்கையாளர் நட்பு நெறிமுறையாக மாற்றுவதையும் எவ்வாறு செய்கிறோம் என்பதையும் நாங்கள் பகிர்ந்துள்ளோம். நாம் ஆப் சர்வர் எவ்வாறு Codex மையத்தை வெளிப்படுத்துகிறது, கிளையண்ட்கள் முழு ஏஜென்ட் லூப்பை இயக்க அனுமதிக்கிறது, மேலும் TUI, உள்ளூர் IDE ஒருங்கிணைப்புகள், மற்றும் வலை ரன்டைம் போன்ற பல்வேறு மேற்பரப்புகளை இயக்குகிறது என்பதைக் குறித்து கவர் செய்தோம்.

இது Codex-ஐ உங்கள் சொந்த பணிப்பாய்வுகளில் ஒருங்கிணைக்க யோசனைகளைத் தூண்டியிருந்தால், ஆப் சர்வர்-ஐ முயற்சி செய்வது மதிப்புள்ளது. அனைத்து மூலக் கோடும் 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 மற்றும் stdio மீது JSONL வடிவத்தில் அமைக்கப்பட்டுள்ளது; இது கடுமையான JSON‑RPC 2.0 ஆக இல்லை.
2
“stdio” என்பது கண்டெய்னருக்குள் உள்ள app-server இன் stdin/stdout ஐ குறிக்கிறது. ஹோஸ்டட் அமைப்புகளில், அந்த ஸ்ட்ரீம்கள் பெரும்பாலும் ஒரு நிலையான நெட்வொர்க் இணைப்பின் (எ.கா., WebSocket போன்ற) வழியாக கன்டெய்னர் ரன்டைமிற்கு டன்னல் செய்யப்படுகின்றன—அதனால் அது நேரடி உள்ளூர் பைப் அல்லாதிருந்தாலும் stdio போல செயல்படுகிறது.

தொடர்ந்து படிக்க

அனைத்தையும் பார்க்கவும்

Codex உடன் சுயமாக மேம்படும் வரி ஏஜென்ட்களை உருவாக்குதல்

என்ஜினியரிங்27 மே, 2026

Windows-இல் Codex-ஐ செயல்படுத்த பாதுகாப்பான, பயனுள்ள சாண்ட்பாக்ஸ் உருவாக்குதல்

என்ஜினியரிங்13 மே, 2026

Supercomputer networking to accelerate large scale AI training

என்ஜினியரிங்5 மே, 2026