৪ ফেব্রুয়ারি, ২০২৬

Codex হারনেস উন্মোচন: আমরা কিভাবে App Server তৈরি করেছি

Celia Chen কর্তৃক, টেকনিক্যাল স্টাফের সদস্য

লোডিং…

OpenAI-এর কোডিং এজেন্ট Codex বিভিন্ন প্ল্যাটফর্মে উপলব্ধ: ওয়েব অ্যাপ⁠(একটি নতুন উইন্ডোতে খোলে), CLI⁠(একটি নতুন উইন্ডোতে খোলে), IDE এক্সটেনশন⁠(একটি নতুন উইন্ডোতে খোলে) এবং নতুন Codex macOS অ্যাপ. অভ্যন্তরীণভাবে, এগুলো সবই একই Codex হারনেস দ্বারা পরিচালিত—অর্থাৎ সেই এজেন্ট লুপ এবং লজিক, যা সকল Codex অভিজ্ঞতার মূল ভিত্তি হিসেবে কাজ করে. তাদের মধ্যে গুরুত্বপূর্ণ সংযোগ কী? Codex App Server⁠(একটি নতুন উইন্ডোতে খোলে), একটি ব্যবহারকারী-বান্ধব, দ্বিমুখী JSON-RPC¹ API.

এই পোস্টে আমরা Codex App Server-এর সাথে আপনাদের পরিচয় করিয়ে দেব; আমরা আপনার প্রোডাক্টে Codex-এর সক্ষমতাগুলো যুক্ত করার সেরা উপায়গুলো সম্পর্কে আমাদের এ পর্যন্ত প্রাপ্ত শিক্ষাগুলো শেয়ার করব, যা আপনার ইউজারদের কাজের গতি বহুগুণ বাড়িয়ে দিতে সাহায্য করবে. আমরা App Server-এর আর্কিটেকচার ও প্রোটোকল এবং এটি কিভাবে বিভিন্ন Codex সারফেসের সাথে একীভূত হয়, সেই বিষয়ে আলোচনা করব. সেইসাথে Codex-কে কাজে লাগানোর বিভিন্ন টিপস শেয়ার করব—তা আপনি একে কোড রিভিউয়ার, SRE এজেন্ট, কিংবা কোডিং অ্যাসিস্ট্যান্ট হিসেবে ব্যবহার করতে চান না কেন.

App Server-এর উৎপত্তি

স্থাপত্যে প্রবেশ করার আগে, App Server-এর পেছনের গল্প জানা সহায়ক. প্রথমে, App Server ছিল বিভিন্ন পণ্যের মধ্যে Codex হারনেস পুনঃব্যবহারের একটি কার্যকর উপায়, যা ধীরে ধীরে আমাদের স্ট্যান্ডার্ড প্রোটোকলে পরিণত হয়েছে.

Codex CLI শুরুতে একটি TUI (terminal user interface) হিসেবে শুরু হয়েছিল, অর্থাৎ Codex টার্মিনালের মাধ্যমে অ্যাক্সেস করা হয়. যখন আমরা VS Code এক্সটেনশন (Codex এজেন্টদের সাথে ইন্টারঅ্যাক্ট করার জন্য আরও বেশি IDE-বান্ধব উপায়) তৈরি করি, তখন আমাদের একই হারনেস ব্যবহার করার একটি পদ্ধতির প্রয়োজন ছিল যাতে এটি পুনরায় ইমপ্লিমেন্ট না করেই একটি IDE UI থেকে একই এজেন্ট লুপ পরিচালনা করা যায়. এর অর্থ ছিল রিকোয়েস্ট/রেসপন্স-এর বাইরেও আরও সমৃদ্ধ ইন্টারঅ্যাকশন প্যাটার্ন সমর্থন করা; যেমন—ওয়ার্কস্পেস এক্সপ্লোর করা বা খুঁজে দেখা, এজেন্ট যখন যুক্তি বিশ্লেষণ করে তখন তার অগ্রগতির স্ট্রিমিং দেখানো এবং ডিফস নির্গত করা. আমরা প্রথমে Codex-কে MCP সার্ভার হিসেবে উন্মোচিত⁠(একটি নতুন উইন্ডোতে খোলে) করার চেষ্টা করেছিলাম, কিন্তু VS Code-এর জন্য অর্থপূর্ণভাবে MCP সেম্যান্টিক্স বজায় রাখা কঠিন ছিল. এর পরিবর্তে, আমরা একটি JSON-RPC প্রোটোকল প্রবর্তন করি যা TUI লুপের প্রতিচ্ছবি ছিল এবং এটি App Server-এর অনানুষ্ঠানিক প্রথম সংস্করণ⁠(একটি নতুন উইন্ডোতে খোলে) হয়ে ওঠে. তখন আমরা আশা করিনি যে অন্য ক্লায়েন্টরা 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 স্যান্ডবক্সে shell/file টুলগুলো চালায় এবং MCP সার্ভার ও স্কিলের মতো ইন্টিগ্রেশনগুলোকে সংযুক্ত করে, যাতে তারা একটি সঙ্গতিপূর্ণ নীতিমালা মডেলের অধীনে এজেন্ট লুপে অংশ নিতে পারে.

এখানে আমরা যে এজেন্ট লজিকের কথা বলেছি, মূল এজেন্ট লুপসহ, সেগুলো Codex CLI কোডবেসের একটি অংশে থাকে, যার নাম “Codex core⁠(একটি নতুন উইন্ডোতে খোলে).” Codex core হলো একইসাথে একটি লাইব্রেরি যেখানে সমস্ত এজেন্ট কোড থাকে এবং একটি রানটাইম যা এজেন্ট লুপ চালানো এবং একটি Codex থ্রেড (কথোপকথন)-এর স্থায়িত্ব বা পারসিস্টেন্স পরিচালনা করার জন্য তাৎক্ষণিকভাবে চালু (spun up) করা যেতে পারে.

Codex হারনেস ক্লায়েন্টদের জন্য অ্যাক্সেসযোগ্য না হলে এটি উপযোগী হবে না. সেখানেই App Server ভূমিকা পালন করে.

“App server process flow” শিরোনামের ডায়াগ্রাম. একটি ক্লায়েন্ট JSON-RPC বার্তা stdio রিডারে পাঠায়, যা Codex বার্তা প্রসেসরে অনুরোধগুলি প্রেরণ করে. প্রসেসরটি লুকআপ থ্রেড, থ্রেড হ্যান্ডেল, জমা দেওয়া অনুরোধ এবং ইভেন্ট/আপডেটের মাধ্যমে থ্রেড ম্যানেজার এবং কোর থ্রেডের সাথে যোগাযোগ করে, তারপর ক্লায়েন্টের কাছে প্রতিক্রিয়া পাঠায়.

App Server ক্লায়েন্ট এবং সার্ভারের মধ্যে JSON-RPC প্রোটোকল এবং Codex কোর থ্রেডগুলিকে হোস্ট করে এমন একটি দীর্ঘস্থায়ী প্রক্রিয়া. উপরের ডায়াগ্রাম থেকে আমরা দেখতে পাচ্ছি, একটি App Server প্রক্রিয়ার চারটি প্রধান উপাদান রয়েছে: stdio reader, Codex মেসেজ প্রসেসর, থ্রেড ম্যানেজার এবং কোর থ্রেড. থ্রেড ম্যানেজার প্রতিটি থ্রেডের জন্য একটি করে কোর সেশন চালু করে, এরপর Codex মেসেজ প্রসেসর প্রতিটি কোর সেশনের সঙ্গে সরাসরি যোগাযোগ করে ক্লায়েন্টের অনুরোধ পাঠায় এবং আপডেট গ্রহণ করে.

একটি ক্লায়েন্টের অনুরোধের ফলে অনেক ইভেন্ট আপডেট হতে পারে এবং এই বিস্তারিত ইভেন্টগুলোই আমাদের App Server-এর উপর একটি সমৃদ্ধ UI তৈরি করতে সাহায্য করে. অতিরিক্তভাবে, stdio রিডার এবং Codex মেসেজ প্রসেসর ক্লায়েন্ট এবং Codex কোর থ্রেডগুলোর মধ্যে অনুবাদ স্তর হিসেবে কাজ করে. তারা ক্লায়েন্ট JSON-RPC অনুরোধগুলোকে Codex কোর অপারেশনে রূপান্তর করে, Codex কোর-এর অভ্যন্তরীণ ইভেন্ট স্ট্রিম শোনে এবং তারপর সেই নিম্ন-স্তরের ইভেন্টগুলোকে একটি ছোট সেটের স্থিতিশীল, UI-ready JSON-RPC নোটিফিকেশনে রূপান্তর করে.

ক্লায়েন্ট এবং App Server-এর মধ্যে JSON-RPC প্রোটোকলটি সম্পূর্ণরূপে দ্বিমুখী. একটি সাধারণ থ্রেডে একটি ক্লায়েন্টের অনুরোধ এবং অনেক সার্ভারের নোটিফিকেশন থাকে. এছাড়াও, যখন এজেন্টের ইনপুটের প্রয়োজন হয়, যেমন অনুমোদন, তখন সার্ভার অনুরোধ শুরু করতে পারে এবং ক্লায়েন্ট প্রতিক্রিয়া না দেওয়া পর্যন্ত টার্নটি বিরতি দিতে পারে.

কথোপকথনের মৌলিক উপাদানসমূহ

এরপর, আমরা কথোপকথনের প্রাথমিক উপাদানগুলো বিশ্লেষণ করব, যা App Server প্রোটোকলের ভিত্তি. এজেন্ট লুপের জন্য একটি API ডিজাইন করা কঠিন, কারণ ব্যবহারকারী/এজেন্টের ইন্টারঅ্যাকশনটি একটি সাধারণ অনুরোধ/প্রতিক্রিয়া নয়. একটি ব্যবহারকারীর অনুরোধ একটি গঠিত ক্রমধারায় উন্মোচিত হতে পারে, যা ক্লায়েন্টকে বিশ্বস্তভাবে উপস্থাপন করতে হয়: ব্যবহারকারীর ইনপুট, এজেন্টের ধাপে ধাপে অগ্রগতি এবং পথে তৈরি হওয়া আর্টিফ্যাক্ট (যেমন, ডিফস). ইন্টারঅ্যাকশন স্ট্রিমকে UI জুড়ে সহজে সংযুক্ত এবং স্থিতিশীল করতে, আমরা স্পষ্ট সীমানা ও জীবনচক্র সহ তিনটি মূল প্রিমিটিভ নির্ধারণ করেছি:

1. আইটেম: Codex-এ একটি আইটেম ইনপুট/আউটপুটের মৌলিক একক. আইটেমগুলো টাইপভিত্তিক (যেমন, ইউজার মেসেজ, এজেন্ট মেসেজ, টুল এক্সিকিউশন, অনুমোদন অনুরোধ, ডিফ) এবং প্রতিটির একটি স্পষ্ট জীবনচক্র রয়েছে:

item/started যখন আইটেমটি শুরু হয় তখন
(স্ট্রিমিং আইটেম প্রকারের জন্য) কনটেন্ট স্ট্রিম হিসেবে ঐচ্ছিক item/*/delta ইভেন্টগুলি
item/completed যখন আইটেমটি তার চূড়ান্ত পে-লোড সহ সম্পন্ন হয়

এই লাইফসাইকেলটি ক্লায়েন্টদের started-এ সঙ্গে সঙ্গে রেন্ডারিং শুরু করতে দেয়, delta-এ ক্রমবর্ধমান আপডেট স্ট্রিম করতে দেয় এবং completed-এ চূড়ান্ত করতে দেয়.

2. টার্ন: টার্ন হলো ব্যবহারকারীর ইনপুট দ্বারা শুরু হওয়া এজেন্টের কাজের একটি একক. এটি শুরু হয় যখন ক্লায়েন্ট একটি ইনপুট জমা দেয় (যেমন, “টেস্ট চালান এবং ব্যর্থতাগুলি সারসংক্ষেপ করুন”) এবং শেষ হয় যখন এজেন্ট সেই ইনপুটের জন্য আউটপুট তৈরি করা শেষ করে. একটি টার্নে আইটেমগুলোর একটি ক্রম থাকে, যা পথের মধ্যবর্তী ধাপ এবং আউটপুটগুলোকে উপস্থাপন করে.

3. থ্রেড: থ্রেড হলো একজন ব্যবহারকারী এবং একটি এজেন্টের মধ্যে চলমান Codex সেশনের জন্য একটি টেকসই ধারক. এতে একাধিক বাঁক রয়েছে. থ্রেড তৈরি করা যায়, পুনরায় শুরু করা যায়, ফর্ক করা যায় এবং আর্কাইভ করা যায়. থ্রেডের ইতিহাস সংরক্ষিত থাকে যাতে ক্লায়েন্টরা পুনরায় সংযোগ করে একটি সঙ্গতিপূর্ণ টাইমলাইন প্রদর্শন করতে পারে.

এখন, আমরা একজন ক্লায়েন্ট এবং একজন এজেন্টের মধ্যে একটি সরলীকৃত কথোপকথন দেখব, যেখানে কথোপকথনটি প্রাথমিক উপাদান দ্বারা উপস্থাপিত হয়:

“Client-server protocol message flow: Initialization handshake.” লেবেলযুক্ত ডায়াগ্রাম. একজন ক্লায়েন্ট clientInfo সহ একটি ইনিশিয়ালাইজ অনুরোধ সার্ভারে পাঠায়. সার্ভারটি userAgent স্ট্রিং “my_client/1.0.” সম্বলিত একটি result ইভেন্টের মাধ্যমে প্রতিক্রিয়া জানায়.

কথোপকথনের শুরুতে ক্লায়েন্ট এবং সার্ভারকে ইনিশিয়ালাইজ হ্যান্ডশেক স্থাপন করতে হয়. ক্লায়েন্টকে অন্য কোনো পদ্ধতির আগে একটি একক ইনিশিয়ালাইজ অনুরোধ পাঠাতে হবে, এবং সার্ভার একটি প্রতিক্রিয়া দিয়ে তা স্বীকার করে. এটি সার্ভারকে সক্ষমতাগুলি বিজ্ঞাপিত করার সুযোগ দেয় এবং আসল কাজ শুরু হওয়ার আগে উভয় পক্ষকে প্রোটোকল ভার্সনিং, ফিচার ফ্ল্যাগ এবং ডিফল্টগুলির বিষয়ে একমত হতে দেয়. 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/started, turn/started, item/started এবং item/completed) নির্গত করে—যা এমন একটি 'টার্ন' বা পর্যায় প্রদর্শন করে যেখানে ব্যবহারকারীর বার্তাটি হলো “run tests and summarize failures” (টেস্টগুলো রান করুন এবং ব্যর্থতাগুলোর সারসংক্ষেপ তৈরি করুন).

যখন কোনো ক্লায়েন্ট একটি নতুন অনুরোধ করে, তখন এটি প্রথমে একটি থ্রেড এবং তারপর একটি টার্ন তৈরি করবে. সার্ভার অগ্রগতির জন্য বিভিন্ন নোটিফিকেশন বা বিজ্ঞপ্তি (thread/started এবং turn/started) ফেরত পাঠাবে. এটি যে ইনপুটগুলোকে আইটেম হিসেবে রেজিস্টার করে, সেগুলোও ফেরত পাঠাবে, যেমন এখানে ব্যবহারকারীর বার্তাটি.

‘ক্লায়েন্ট-সার্ভার প্রোটোকল মেসেজ ফ্লো: ঐচ্ছিক অনুমোদনসহ টুল এক্সিকিউশন’ শিরোনামের ডায়াগ্রাম. একটি টুল কলের সময়, সার্ভার item/started এমিট করে, তারপর item/commandExecution/requestApproval একটি কারণ (“run tests”) সহ পাঠায়. ক্লায়েন্ট একটি অনুমোদন ইভেন্ট (অনুমোদন/প্রত্যাখ্যান) ফেরত দেয়. এরপর সার্ভার কমান্ড এক্সিকিউশন দেখিয়ে item/completed এমিট করে ("pnpm test").

টুল কলগুলো আইটেম হিসেবে ক্লায়েন্টের কাছে ফেরত পাঠানো হয়. অতিরিক্তভাবে, সার্ভার রিকোয়েস্ট পাঠিয়ে কোনো অ্যাকশন চালানোর আগে সার্ভারটি ক্লায়েন্টের অনুমোদন চাইতে পারে. অনুমোদন বা অ্যাপ্রুভাল পাওয়ার আগ পর্যন্ত এই পর্যায় বা এই 'টার্ন' স্থগিত থাকবে, যতক্ষণ না ক্লায়েন্ট "allow" (অনুমতি) অথবা "deny" (প্রত্যাখ্যান) লিখে উত্তর দেয়. VS Code এক্সটেনশনে অনুমোদন প্রবাহটি এভাবে দেখায়:

ডার্ক-থিমযুক্ত ইন্টারফেসে একটি অনুমতি প্রম্পট জিজ্ঞেস করছে, “আপনি কি আমাকে এই ওয়ার্কস্পেসের জন্য pnpm টেস্ট চালাতে অনুমতি দিতে চান?” এটি বিকল্পগুলি তালিকাভুক্ত করে: 1) হ্যাঁ, 2) pnpm test দিয়ে শুরু হওয়া কমান্ডগুলোর জন্য হ্যাঁ এবং আর জিজ্ঞাসা করবেন না, এবং 3) না, নিচে একটি সাবমিট বোতামসহ.

“ক্লায়েন্ট-সার্ভার প্রোটোকল মেসেজ ফ্লো: স্ট্রিমিং এজেন্ট মেসেজ ফ্লো” শিরোনামের ডায়াগ্রাম. সার্ভারটি অ্যাসিস্ট্যান্ট মেসেজকে অংশে স্ট্রিম করে: item/started, দুটি agentMessage/delta ইভেন্ট (“3-টি পরীক্ষা চালানো হয়েছে.”, “সব পাস করেছে”), তারপর আইটেম/সম্পন্ন হয়েছে. টার্নটি turn/completed দিয়ে শেষ হয়.

অবশেষে, সার্ভার একটি এজেন্ট বার্তা পাঠায় এবং তারপর turn/completed দিয়ে পালা শেষ করে. এজেন্ট মেসেজ ডেল্টা ইভেন্টস স্ট্রিম মেসেজটি চূড়ান্তভাবে item/completed দিয়ে সম্পন্ন না হওয়া পর্যন্ত মেসেজের অংশগুলো ফিরিয়ে পাঠায়.

ডায়াগ্রামের বার্তাগুলি সহজে পড়ার জন্য সরলীকৃত করা হয়েছে. আপনি যদি একটি সম্পূর্ণ টার্নের JSON দেখতে চান, তাহলে Codex CLI রিপো থেকে টেস্ট ক্লায়েন্ট চালাতে পারেন:

Bash

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

ক্লায়েন্টদের সাথে ইন্টিগ্রেশন করা

এখন, চলুন দেখি বিভিন্ন ক্লায়েন্ট সারফেস কিভাবে App Server-এর মাধ্যমে Codex এম্বেড করে. আমরা তিনটি প্যাটার্ন আলোচনা করবো: লোকাল অ্যাপ এবং IDE, Codex ওয়েব রানটাইম এবং TUI.

“App Server-এর মাধ্যমে Codex হারনেস-এর সাথে ইন্টিগ্রেট করা Codex ক্লায়েন্ট” শিরোনামের ডায়াগ্রাম. প্রথম-পক্ষের ক্লায়েন্ট (Codex Desktop App, TUI/CLI, Web Runtime) এবং তৃতীয়-পক্ষের ইন্টিগ্রেশন (JetBrains IDEs, VS Code, Xcode) JSON-RPC কলের মাধ্যমে Codex হারনেস-এর সাথে যোগাযোগ করে.

তিনটির মধ্যেই, ট্রান্সপোর্ট হলো stdio (JSONL) এর মাধ্যমে JSON-RPC. JSON-RPC আপনার পছন্দের ভাষায় ক্লায়েন্ট বাইন্ডিং তৈরি করা সহজ করে দেয়. Codex সারফেস এবং পার্টনার ইন্টিগ্রেশনগুলি Go, Python, TypeScript, Swift এবং Kotlin সহ বিভিন্ন ভাষায় App Server ক্লায়েন্ট বাস্তবায়ন করেছে. TypeScript-এর জন্য, আপনি নিচের কমান্ডটি চালিয়ে সরাসরি Rust প্রোটোকল থেকে ডেফিনিশনগুলো জেনারেট করতে পারেন:

Bash

1codex app-server generate-ts

অন্যান্য ভাষার জন্য, আপনি নিচের কমান্ডটি চালিয়ে একটি JSON Schema বান্ডল তৈরি করতে পারেন এবং সেটি আপনার পছন্দের code generator-এ ইনপুট হিসেবে ব্যবহার করতে পারেন:

Bash

1codex app-server generate-json-schema

লোকাল অ্যাপস এবং IDEs

Codex এক্সটেনশন চালু থাকা অবস্থায় VS Code-এর স্ক্রিনশট. একটি Rust টেস্ট ফাইল খোলা আছে এবং এর নিচে Codex প্যানেলটি শুধুমাত্র fmt এবং cargo test -p codex-app-server চালানোর কথা বলছে, যেখানে ফরম্যাটিং এবং টেস্ট চলছে বলে জানাচ্ছে এবং চূড়ান্ত পাস/ফেল ফলাফলের জন্য অপেক্ষা করছে.

স্থানীয় ক্লায়েন্টরা সাধারণত প্ল্যাটফর্ম-নির্দিষ্ট App Server বাইনারি বান্ডল করে বা ফেচ করে, এটিকে একটি দীর্ঘমেয়াদি চাইল্ড প্রসেস হিসেবে চালু করে, এবং JSON-RPC-এর জন্য একটি দ্বিমুখী স্ট্যান্ডার্ড ইনপুট/আউটপুট চ্যানেল খোলা রাখে. আমাদের VS Code এক্সটেনশন এবং ডেস্কটপ অ্যাপে, উদাহরণস্বরূপ, শিপ করা আর্টিফ্যাক্টে প্ল্যাটফর্ম-নির্দিষ্ট Codex বাইনারি অন্তর্ভুক্ত থাকে এবং এটি একটি পরীক্ষিত ভার্সনে পিন করা থাকে, যাতে ক্লায়েন্ট সবসময় আমরা যে নির্দিষ্ট বিটস যাচাই করেছি সেটাই চালায়.

প্রতিটি ইন্টিগ্রেশন ঘন ঘন ক্লায়েন্ট আপডেট পাঠাতে পারে না. Xcode-এর মতো কিছু পার্টনার ক্লায়েন্টকে স্থিতিশীল রেখে এবং প্রয়োজন অনুযায়ী নতুন App Server বাইনারি ব্যবহারের সুযোগ দিয়ে রিলিজ সাইকেলগুলোকে ডিকাপল বা আলাদা করে রাখে. এভাবে তারা সার্ভার-সাইড উন্নতি (যেমন, Codex কোরে উন্নত অটো-কম্প্যাকশন বা নতুন সমর্থিত কনফিগারেশন কী) গ্রহণ করতে পারে এবং ক্লায়েন্ট রিলিজের জন্য অপেক্ষা না করেই বাগ ফিক্স রোল আউট করতে পারে. App Server-এর JSON-RPC সারফেসটি ব্যাকওয়ার্ড কম্প্যাটিবল হওয়ার জন্য ডিজাইন করা হয়েছে, যাতে পুরোনো ক্লায়েন্টরা নতুন সার্ভারের সাথে নিরাপদে কথা বলতে পারে.

Codex ওয়েব

Codex ওয়েব Codex হারনেস ব্যবহার করে, তবে এটি একটি কন্টেইনার পরিবেশে চালায়. একজন কর্মী চেক-আউট করা ওয়ার্কস্পেসসহ একটি কন্টেইনার প্রস্তুত করেন, এর ভেতরে App Server বাইনারিটি চালু করেন এবং stdio-এর মাধ্যমে একটি দীর্ঘস্থায়ী JSON-RPC চ্যানেল বজায় রাখেন ওয়েব অ্যাপটি (যা ব্যবহারকারীর ব্রাউজার ট্যাবে চলছে) HTTP এবং SSE-এর মাধ্যমে Codex ব্যাকএন্ডের সাথে যোগাযোগ করে, যা কর্মীর তৈরি করা টাস্ক ইভেন্টগুলোকে স্ট্রিম করে পাঠায়. এটি ব্রাউজার-সাইড UI-কে হালকা রাখে, একই সঙ্গে ডেস্কটপ এবং ওয়েব জুড়ে আমাদের একটি সঙ্গতিপূর্ণ রানটাইম প্রদান করে.

ওয়েব সেশনগুলো ক্ষণস্থায়ী হওয়ায় (ট্যাব বন্ধ হয়ে যায়, নেটওয়ার্ক বিচ্ছিন্ন হয়), দীর্ঘমেয়াদী কাজের জন্য ওয়েব অ্যাপটি সত্যের উৎস হতে পারে না. সার্ভারে অবস্থা এবং অগ্রগতি সংরক্ষণ করা মানে ট্যাবটি অদৃশ্য হয়ে গেলেও কাজ অব্যাহত থাকে. স্ট্রিমিং প্রোটোকল এবং সংরক্ষিত থ্রেড সেশনগুলো নতুন সেশনের জন্য পুনরায় সংযোগ স্থাপন করা, যেখানে থেমে গিয়েছিল সেখান থেকে শুরু করা এবং ক্লায়েন্টে স্টেট পুনর্নির্মাণ না করেই দ্রুত সমন্বয় করা সহজ করে তোলে.

TUI/Codex CLI

Codex CLI চালু থাকা একটি টার্মিনালের স্ক্রিনশট. এটি gpt-5.2-codex medium মডেলসহ OpenAI Codex ব্যানার, ব্যবহারকারীর কমান্ড “explain app server to me” এবং একটি “Working” স্ট্যাটাস বা অবস্থা প্রদর্শন করছে. নীচে একটি পরামর্শ প্রদর্শিত হয়: “@filename-এর জন্য টেস্ট লিখুন,” শর্টকাটের বিকল্প সহ.

ঐতিহাসিকভাবে, TUI ছিল একটি “নেটিভ” ক্লায়েন্ট যা এজেন্ট লুপের সাথে একই প্রক্রিয়ায় চলত এবং অ্যাপ-সার্ভার প্রোটোকলের পরিবর্তে সরাসরি Rust কোর টাইপগুলোর সাথে যোগাযোগ করত. এটি প্রাথমিক ইটারেশনকে দ্রুত করেছিল, তবে এটি 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 যা প্রকাশ করে সেটাই পাবে, তাই Codex-নির্দিষ্ট ইন্টারঅ্যাকশনগুলো, যেগুলো আরও সমৃদ্ধ সেশন সেম্যান্টিক্সের উপর নির্ভর করে (যেমন, ডিফ আপডেটস), সেগুলো MCP এন্ডপয়েন্টগুলোর মাধ্যমে স্পষ্টভাবে ম্যাপ নাও হতে পারে.

ক্রস-প্রোভাইডার এজেন্ট হারনেস প্রোটোকলসমূহ

কিছু ইকোসিস্টেম একটি পোর্টেবল ইন্টারফেস প্রদান করে যা একাধিক মডেল প্রদানকারী এবং রানটাইমকে লক্ষ্য করতে পারে. আপনি যদি একাধিক এজেন্ট সমন্বয় করে এমন একটি অ্যাবস্ট্র্যাকশন চান, তাহলে এটি ভালোভাবে মানিয়ে যেতে পারে. বিনিময় হলো যে এই প্রোটোকলগুলো প্রায়ই সাধারণ সক্ষমতার সাবসেটের দিকে কনভার্জ করে, যা আরও সমৃদ্ধ ইন্টারঅ্যাকশন উপস্থাপন করা কঠিন করে তুলতে পারে, বিশেষত যখন প্রোভাইডার-নির্দিষ্ট টুল এবং সেশন সেম্যান্টিক্স গুরুত্বপূর্ণ. এই ক্ষেত্রটি দ্রুত বিকশিত হচ্ছে এবং আমরা আশা করি যে বাস্তব বিশ্বের এজেন্ট ওয়ার্কফ্লো উপস্থাপন করার জন্য সেরা প্রিমিটিভ নির্ধারণ করার সাথে সাথে আরও সাধারণ মানদণ্ড উদ্ভূত হবে (দক্ষতা⁠(একটি নতুন উইন্ডোতে খোলে) এর একটি ভালো উদাহরণ).

Codex App Server

আপনি যখন সম্পূর্ণ Codex হারনেস-কে একটি স্থিতিশীল, UI-বান্ধব ইভেন্ট স্ট্রিম হিসেবে প্রকাশ করতে চান, তখন App Server বেছে নিন. আপনি এজেন্ট লুপের সম্পূর্ণ কার্যকারিতা এবং Sign in with ChatGPT, মডেল ডিসকভারি এবং কনফিগারেশন ম্যানেজমেন্টের মতো অন্যান্য সহায়ক বৈশিষ্ট্যও পাবে. মূল খরচ হলো ইন্টিগ্রেশন কাজ, কারণ আপনাকে আপনার ভাষায় ক্লায়েন্ট-সাইড JSON-RPC বাইন্ডিং তৈরি করতে হবে. তবে বাস্তবে, আপনি যদি Codex-কে JSON স্কিমা এবং ডকুমেন্টেশন দেন, এটি অনেক কঠিন কাজ সহজে করতে পারে. আমরা যেসব দলের সঙ্গে কাজ করেছি, তাদের অনেকেই Codex ব্যবহার করে দ্রুত একটি কার্যকর ইন্টিগ্রেশন তৈরি করতে পেরেছে.

Codex এমবেড করার আরও উপায়

Codex Exec⁠(একটি নতুন উইন্ডোতে খোলে)

এককালীন কাজ এবং CI রান-এর জন্য একটি হালকা, স্ক্রিপ্টযোগ্য CLI মোড. এটি অটোমেশন এবং পাইপলাইনগুলোর জন্য অত্যন্ত উপযোগী, যেখানে আপনি চান একটি একক কমান্ড ইন্টারঅ্যাকশন ছাড়াই সম্পূর্ণ হওয়া পর্যন্ত চলুক, লগের জন্য স্ট্রিমড স্ট্রাকচার্ড আউটপুট প্রদান করুক এবং একটি স্পষ্ট সফল বা ব্যর্থতার সংকেত দিয়ে শেষ হোক.

Codex SDK⁠(একটি নতুন উইন্ডোতে খোলে)

আপনার নিজস্ব অ্যাপ্লিকেশন থেকে প্রোগ্রাম্যাটিকভাবে লোকাল Codex এজেন্ট নিয়ন্ত্রণের জন্য একটি TypeScript লাইব্রেরি. সার্ভার-সাইড টুলস এবং ওয়ার্কফ্লোর জন্য আলাদা JSON-RPC ক্লায়েন্ট তৈরি না করেই যখন আপনি একটি নেটিভ লাইব্রেরি ইন্টারফেস চান, তখন এটি সবচেয়ে ভালো. App Server-এর আগে শিপ হওয়ায়, এটি বর্তমানে কম ভাষা এবং ছোট সারফেস এরিয়া সমর্থন করে. যদি ডেভেলপারদের আগ্রহ থাকে, তাহলে আমরা App Server প্রোটোকলকে র‍্যাপ করে এমন অতিরিক্ত SDKs যোগ করতে পারি, যাতে টিমগুলো JSON-RPC bindings না লিখেই হারনেস surface-এর আরও বেশি অংশ কভার করতে পারে.

এটি সামনে এগিয়ে নিয়ে যাওয়া

এই পোস্টে, আমরা আলোচনা করেছি কিভাবে আমরা এজেন্টদের সাথে ইন্টারঅ্যাক্ট করার জন্য একটি নতুন মান তৈরি করি এবং Codex হারনেস-কে কিভাবে একটি স্থিতিশীল, ক্লায়েন্ট-বান্ধব প্রোটোকলে রূপান্তর করা যায়. আমরা আলোচনা করেছি কিভাবে App Server Codex core উন্মুক্ত করে, ক্লায়েন্টদের সম্পূর্ণ এজেন্ট লুপ পরিচালনা করতে দেয় এবং TUI, স্থানীয় IDE ইন্টিগ্রেশন এবং ওয়েব রানটাইম সহ বিভিন্ন ধরনের পৃষ্ঠতলকে শক্তি জোগায়.

যদি এটি আপনার নিজস্ব ওয়ার্কফ্লোতে Codex একীভূত করার জন্য কিছু ধারণা উদ্রেক করে, তাহলে App Server একবার চেষ্টা করে দেখা উচিত. সমস্ত সোর্স কোড Codex CLI ওপেন-সোর্স রিপো⁠(একটি নতুন উইন্ডোতে খোলে)-তে রয়েছে. আপনার ফিডব্যাক এবং ফিচার রিকোয়েস্ট শেয়ার করতে দ্বিধা করবেন না. আমরা আপনার কাছ থেকে শুনতে পেয়ে উচ্ছ্বসিত এবং এজেন্টগুলোকে সবার জন্য আরও সহজলভ্য করতে থাকব.

লেখক

Celia Chen

কৃতজ্ঞতা প্রকাশ

মাইকেল বলিন, ওয়েন লিন, এরিক ট্রাউট এবং রাসমুস রাইগার্ডকে বিশেষ ধন্যবাদ, যারা এই পোস্টে অবদান রেখেছেন এবং App Server-এ কাজ করা পুরো Codex দলের প্রতি কৃতজ্ঞতা.

ফুটনোটস

1
আমরা একটি “JSON‑RPC lite” ভ্যারিয়েন্ট ব্যবহার করি: এটি অনুরোধ/প্রতিক্রিয়া/বিজ্ঞপ্তি আকার বজায় রাখে, কিন্তু "jsonrpc": "2.0" বাদ দেয় হেডার এবং এটি strict JSON‑RPC 2.0-এর পরিবর্তে stdio-এর উপর JSONL আকারে ফ্রেম করা হয়েছে.
2
“stdio” বলতে কন্টেইনারের মধ্যে অ্যাপ-সার্ভারের stdin/stdout বোঝানো হয়. হোস্টেড সেটআপগুলোর ক্ষেত্রে, এই স্ট্রিমগুলো প্রায়শই একটি দীর্ঘস্থায়ী নেটওয়ার্ক সংযোগের (যেমন: WebSocket-এর মতো) মাধ্যমে কন্টেইনার রানটাইমে টানেল করা হয়—যাতে এটি সরাসরি লোকাল পাইপ না হওয়া সত্ত্বেও stdio-এর মতো কাজ করে.

পড়া চালিয়ে যান

সব দেখুন

Codex দিয়ে স্ব-উন্নয়নশীল ট্যাক্স এজেন্ট তৈরি

ইঞ্জিনিয়ারিং২৭ মে, ২০২৬

Windows-এ Codex চালু করতে একটি নিরাপদ, কার্যকর sandbox তৈরি করা

ইঞ্জিনিয়ারিং১৩ মে, ২০২৬

গবলিনগুলো কোথা থেকে এলো

ইঞ্জিনিয়ারিং৫ মে, ২০২৬