4 ਫ਼ਰਵਰੀ 2026

Unlocking the Codex harness: how we built the App Server

By Celia Chen, Member of the Technical Staff

ਲੋਡ ਹੋ ਰਿਹਾ ਹੈ…

OpenAI’s coding agent Codex exists across many different surfaces: the web app⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ), the CLI⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ), the IDE extension⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ), and the new Codex macOS app. Under the hood, they’re all powered by the same Codex harness—the agent loop and logic that underlies all Codex experiences. The critical link between them? The Codex App Server⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ), a client-friendly, bidirectional JSON-RPC¹ API.

In this post, we’ll introduce the Codex App Server; we’ll share our learnings so far on the best ways to bring Codex’s capabilities into your product to help your users supercharge their workflows. We’ll cover the App Server’s architecture and protocol and how it integrates with different Codex surfaces, as well as tips on leveraging Codex, whether you want to turn Codex into a code reviewer, an SRE agent, or a coding assistant.

Origin of the App Server

Before diving into architecture, it’s helpful to know the App Server’s backstory. Initially, the App Server was a practical way to reuse the Codex harness across products that gradually evolved into our standard protocol.

Codex CLI started as a TUI (terminal user interface), meaning Codex is accessed through the terminal. When we built the VS Code extension (a more IDE-friendly way to interact with Codex agents), we needed a way to use the same harness so as to drive the same agent loop from an IDE UI without re-implementing it. That meant supporting rich interaction patterns beyond request/response, such as exploring the workspace, streaming progress as the agent reasons, and emitting diffs. We first experimented with exposing Codex as an MCP server⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ), but maintaining MCP semantics in a way that made sense for VS Code proved difficult. Instead, we introduced a JSON-RPC protocol that mirrored the TUI loop, which became the unofficial first version⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) of the App Server. At the time, we didn’t expect other clients to depend on the App Server, so it wasn’t designed as a stable API.

As Codex adoption grew over the next few months, internal teams and external partners wanted the ability to embed the same harness in their own products in order to accelerate their users’ software development workflows. For example, JetBrains and Xcode wanted an IDE-grade agent experience, while the Codex desktop app needed to orchestrate many Codex agents in parallel. Those demands pushed us to design a platform surface that both our products and partner integrations could safely depend on over time. It needed to be easy to integrate and backward compatible, meaning we could evolve the protocol without breaking existing clients.

Next, we’ll walk through how we designed the architecture and protocol so different clients can use the same harness.

Inside the Codex harness

First, let’s zoom in on what’s inside the Codex harness and how the Codex App Server exposes it to clients. In our last Codex blog, we broke down the core agent loop that orchestrates the interaction between the user, the model, and the tools. This is the core logic of the Codex harness, but there’s more to the full agent experience:

1. Thread lifecycle and persistence. A thread is a Codex conversation between a user and an agent. Codex creates, resumes, forks, and archives threads, and persists the event history so clients can reconnect and render a consistent timeline.

2. Config and auth. Codex loads configuration, manages defaults, and runs authentication flows like “Sign in with ChatGPT,” including credential state.

3. Tool execution and extensions. Codex executes shell/file tools in a sandbox and wires up integrations like MCP servers and skills so they can participate in the agent loop under a consistent policy model.

All the agent logic we mentioned here, including the core agent loop, lives in a part of the Codex CLI codebase called “Codex core⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ).” Codex core is both a library where all the agent code lives and a runtime that can be spun up to run the agent loop and manage the persistence of one Codex thread (conversation).

To be useful, the Codex harness needs to be accessible to clients. That’s where the App Server comes in.

“App server process flow” ਸਿਰਲੇਖ ਵਾਲਾ ਡਾਇਗ੍ਰਾਮ। ਇੱਕ ਕਲਾਇੰਟ stdio reader ਨੂੰ JSON-RPC ਸੁਨੇਹੇ ਭੇਜਦਾ ਹੈ, ਜੋ ਬੇਨਤੀਆਂ ਨੂੰ Codex message processor ਵੱਲ ਭੇਜਦਾ ਹੈ। processor lookup threads, thread handles, submitted requests ਅਤੇ events/updates ਰਾਹੀਂ thread manager ਅਤੇ core thread ਨਾਲ ਇੰਟਰਐਕਟ ਕਰਦਾ ਹੈ, ਫਿਰ responses ਕਲਾਇੰਟ ਨੂੰ ਵਾਪਸ ਕਰਦਾ ਹੈ।

The App Server is both the JSON-RPC protocol between the client and the server and a long-lived process that hosts the Codex core threads. As we can see from the diagram above, an App Server process has four main components: the stdio reader, the Codex message processor, the thread manager, and core threads. The thread manager spins up one core session for each thread, and the Codex message processor then communicates with each core session directly to submit client requests and receive updates.

One client request can result in many event updates, and these detailed events are what allow us to build a rich UI on top of the App Server. Furthermore, the stdio reader and the Codex message processor serve as the translation layer between the client and Codex core threads. They translate client JSON-RPC requests into Codex core operations, listen to Codex core’s internal event stream, and then transform those low-level events into a small set of stable, UI-ready JSON-RPC notifications.

The JSON-RPC protocol between the client and the App Server is fully bidirectional. A typical thread has a client request and many server notifications. In addition, the server can initiate requests when the agent needs input, like an approval, and then pause the turn until the client responds.

The conversation primitives

Next, we’ll break down the conversation primitives, the building blocks of the App Server protocol. Designing an API for an agent loop is tricky because the user/agent interaction is not a simple request/response. One user request can unfold into a structured sequence of actions that the client needs to represent faithfully: the user’s input, the agent’s incremental progress, artifacts produced along the way (e.g., diffs). To make that interaction stream easy to integrate and resilient across UIs, we landed on three core primitives with clear boundaries and lifecycles:

1. Item: An item is the atomic unit of input/output in Codex. Items are typed (e.g., user message, agent message, tool execution, approval request, diff) and each has an explicit lifecycle:

item/started when the item begins
optional item/*/delta events as content streams in (for streaming item types)
item/completed when the item finalizes with its terminal payload

This lifecycle lets clients start rendering immediately on started, stream incremental updates on delta, and finalize on completed.

2. Turn: A turn is one unit of agent work initiated by user input. It begins when the client submits an input (for example, “run tests and summarize failures”) and ends when the agent finishes producing outputs for that input. A turn contains a sequence of items that represent the intermediate steps and outputs produced along the way.

3. Thread: A thread is the durable container for an ongoing Codex session between a user and an agent. It contains multiple turns. Threads can be created, resumed, forked, and archived. Thread history is persisted so clients can reconnect and render a consistent timeline.

Now, we’ll look at a simplified conversation between a client and an agent, where the conversation is represented by primitives:

“ਕਲਾਇੰਟ-ਸਰਵਰ ਪ੍ਰੋਟੋਕੋਲ ਸੁਨੇਹਾ ਪ੍ਰਵਾਹ: ਸ਼ੁਰੂਆਤੀ ਹੈਂਡਸ਼ੇਕ” ਲੇਬਲ ਵਾਲਾ ਡਾਇਗ੍ਰਾਮ। ਇੱਕ ਕਲਾਇੰਟ clientInfo ਨਾਲ initialize ਬੇਨਤੀ ਸਰਵਰ ਨੂੰ ਭੇਜਦਾ ਹੈ। ਸਰਵਰ result ਇਵੈਂਟ ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ userAgent ਸਤਰ “my_client/1.0” ਹੈ।

At the beginning of the conversation, the client and the server need to establish the initialize handshake. The client must send a single initialize request before any other method, and the server acknowledges with a response. This gives the server a chance to advertise capabilities and lets both sides agree on protocol versioning, feature flags, and defaults before the real work begins. Here’s an example payload from OpenAI’s VS Code extension:

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}

This is what the server returns:

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 ਇਵੈਂਟ ਜਾਰੀ ਕਰਦਾ ਹੈ, ਜੋ ਇੱਕ ਟਰਨ ਦਿਖਾਉਂਦੇ ਹਨ ਜਿਸ ਵਿੱਚ ਯੂਜ਼ਰ ਸੁਨੇਹਾ “ਟੈਸਟ ਚਲਾਓ ਅਤੇ ਨਾਕਾਮੀਆਂ ਦਾ ਸਾਰ ਦਿਓ।” ਹੈ।

When a client makes a new request, it will first create a thread and then a turn. The server will send back notifications for progress (thread/started and turn/started). It will also send back inputs it registers as items, like the user message here.

“ਕਲਾਇੰਟ-ਸਰਵਰ ਪ੍ਰੋਟੋਕੋਲ ਸੁਨੇਹਾ ਪ੍ਰਵਾਹ: ਵਿਕਲਪਕ ਮਨਜ਼ੂਰੀ ਨਾਲ tool execution” ਸਿਰਲੇਖ ਵਾਲਾ ਡਾਇਗ੍ਰਾਮ। tool call ਦੌਰਾਨ ਸਰਵਰ ਪਹਿਲਾਂ item/started ਜਾਰੀ ਕਰਦਾ ਹੈ, ਫਿਰ item/commandExecution/requestApproval ਕਾਰਨ (“ਟੈਸਟ ਚਲਾਓ”) ਨਾਲ। ਕਲਾਇੰਟ ਇੱਕ approval ਇਵੈਂਟ (allow/deny) ਵਾਪਸ ਕਰਦਾ ਹੈ। ਫਿਰ ਸਰਵਰ item/completed ਜਾਰੀ ਕਰਦਾ ਹੈ ਜੋ command execution (“pnpm test”) ਦਿਖਾਉਂਦਾ ਹੈ।

Tool calls are also sent back to the client as items. Additionally, the server may ask for client approval before it can run an action by sending a server request. The approval will pause the turn until the client replies with either “allow” or “deny.” This is what the approval flow looks like in the VS Code extension:

ਗੂੜ੍ਹੇ ਥੀਮ ਵਾਲੇ ਇੰਟਰਫੇਸ ਵਿੱਚ ਇਜਾਜ਼ਤ ਪ੍ਰੌੰਪਟ, ਜੋ ਪੁੱਛਦਾ ਹੈ, “ਕੀ ਤੁਸੀਂ ਮੈਨੂੰ ਇਸ ਵਰਕਸਪੇਸ ਲਈ pnpm test ਚਲਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣਾ ਚਾਹੁੰਦੇ ਹੋ?” ਇਸ ਵਿੱਚ ਵਿਕਲਪ ਦਿੱਤੇ ਹਨ: 1) ਹਾਂ, 2) ਹਾਂ ਅਤੇ pnpm test ਨਾਲ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੇ ਕਮਾਂਡਾਂ ਲਈ ਮੁੜ ਨਾ ਪੁੱਛੋ, ਅਤੇ 3) ਨਹੀਂ। ਹੇਠਾਂ Submit ਬਟਨ ਹੈ।

“ਕਲਾਇੰਟ-ਸਰਵਰ ਪ੍ਰੋਟੋਕੋਲ ਸੁਨੇਹਾ ਪ੍ਰਵਾਹ: streaming agent message flow” ਸਿਰਲੇਖ ਵਾਲਾ ਡਾਇਗ੍ਰਾਮ। ਸਰਵਰ assistant message ਨੂੰ ਹਿੱਸਿਆਂ ਵਿੱਚ stream ਕਰਦਾ ਹੈ: item/started, ਦੋ agentMessage/delta ਇਵੈਂਟ (“3 ਟੈਸਟ ਚਲਾਏ.”, “ਸਾਰੇ ਪਾਸ ਹੋਏ”), ਫਿਰ item/completed। turn ਦਾ ਅੰਤ turn/completed ਨਾਲ ਹੁੰਦਾ ਹੈ।

In the end, the server sends an agent message and then ends the turn with turn/completed. The agent message delta events stream pieces of the message back until the message is finalized with item/completed.

ਡਾਇਗ੍ਰਾਮ ਵਿੱਚ ਸੁਨੇਹਿਆਂ ਨੂੰ ਪੜ੍ਹਨ ਦੀ ਸੁਵਿਧਾ ਲਈ ਸਰਲ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਜੇ ਤੁਸੀਂ ਪੂਰੇ turn ਦਾ JSON ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ Codex CLI ਰਿਪੋ ਤੋਂ ਟੈਸਟ ਕਲਾਇੰਟ ਚਲਾ ਸਕਦੇ ਹੋ:

Bash

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

ਕਲਾਇੰਟਾਂ ਨਾਲ ਇੰਟੀਗ੍ਰੇਸ਼ਨ

ਹੁਣ, ਆਓ ਵੇਖੀਏ ਕਿ ਵੱਖ-ਵੱਖ ਕਲਾਇੰਟ ਸਰਫੇਸ App Server ਰਾਹੀਂ Codex ਨੂੰ ਕਿਵੇਂ ਐਮਬੈਡ ਕਰਦੀਆਂ ਹਨ। ਅਸੀਂ ਤਿੰਨ ਪੈਟਰਨ ਕਵਰ ਕਰਾਂਗੇ: ਲੋਕਲ ਐਪਸ ਅਤੇ IDEs, Codex ਵੈੱਬ ਰਨਟਾਈਮ, ਅਤੇ TUI.

“app server ਰਾਹੀਂ Codex harness ਨਾਲ ਇੰਟੀਗ੍ਰੇਟ ਕੀਤੇ Codex ਕਲਾਇੰਟ” ਸਿਰਲੇਖ ਵਾਲਾ ਡਾਇਗ੍ਰਾਮ। ਪਹਿਲੇ-ਪੱਖ ਕਲਾਇੰਟ, ਜਿਵੇਂ Codex Desktop App, TUI/CLI ਅਤੇ Web Runtime, ਅਤੇ ਤੀਜੇ-ਪੱਖ ਇੰਟੀਗ੍ਰੇਸ਼ਨ, ਜਿਵੇਂ JetBrains IDEs, VS Code ਅਤੇ Xcode, JSON-RPC calls ਰਾਹੀਂ Codex harness ਨਾਲ ਸੰਚਾਰ ਕਰਦੇ ਹਨ।

ਇਨ੍ਹਾਂ ਤਿੰਨਾਂ ਵਿੱਚ ਟ੍ਰਾਂਸਪੋਰਟ stdio (JSONL) ਉੱਤੇ JSON-RPC ਹੈ। JSON-RPC ਤੁਹਾਡੀ ਪਸੰਦ ਦੀ ਭਾਸ਼ਾ ਵਿੱਚ ਕਲਾਇੰਟ ਬਾਈਂਡਿੰਗ ਬਣਾਉਣਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ। Codex ਸਰਫੇਸਾਂ ਅਤੇ ਭਾਗੀਦਾਰ ਇੰਟੀਗ੍ਰੇਸ਼ਨਾਂ ਨੇ Go, Python, TypeScript, Swift ਅਤੇ Kotlin ਸਮੇਤ ਕਈ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ App Server ਕਲਾਇੰਟ ਲਾਗੂ ਕੀਤੇ ਹਨ। TypeScript ਲਈ, ਤੁਸੀਂ ਇਹ ਚਲਾ ਕੇ Rust ਪ੍ਰੋਟੋਕੋਲ ਤੋਂ ਸਿੱਧੇ ਡਿਫਿਨੀਸ਼ਨ ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹੋ:

Bash

1codex app-server generate-ts

ਹੋਰ ਭਾਸ਼ਾਵਾਂ ਲਈ, ਤੁਸੀਂ ਇੱਕ JSON ਸਕੀਮਾ bundle ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਇਸਨੂੰ ਆਪਣੇ ਮਨਪਸੰਦ ਕੋਡ ਜਨਰੇਟਰ ਵਿੱਚ ਇਹ ਚਲਾ ਕੇ ਦੇ ਸਕਦੇ ਹੋ:

Bash

1codex app-server generate-json-schema

ਲੋਕਲ ਐਪਸ ਅਤੇ IDEs

Codex ਐਕਸਟੈਂਸ਼ਨ ਚੱਲ ਰਹੀ VS Code ਦੀ ਸਕ੍ਰੀਨਸ਼ਾਟ। ਇੱਕ Rust ਟੈਸਟ ਫ਼ਾਇਲ ਖੁੱਲ੍ਹੀ ਹੈ ਅਤੇ ਹੇਠਾਂ Codex ਪੈਨਲ ਸਿਰਫ਼ fmt ਅਤੇ cargo test -p codex-app-server ਚਲਾਉਣ ਬਾਰੇ ਦੱਸਦਾ ਹੈ, ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਫਾਰਮੈਟਿੰਗ ਅਤੇ ਟੈਸਟ ਜਾਰੀ ਹਨ ਅਤੇ ਅੰਤਿਮ ਪਾਸ/ਫੇਲ ਨਤੀਜੇ ਦੀ ਉਡੀਕ ਹੋ ਰਹੀ ਹੈ।

ਲੋਕਲ ਕਲਾਇੰਟ ਆਮ ਤੌਰ 'ਤੇ ਪਲੇਟਫਾਰਮ-ਖਾਸ App Server ਬਾਈਨਰੀ ਨੂੰ bundle ਕਰਦੇ ਜਾਂ ਫੈਚ ਕਰਦੇ ਹਨ, ਇਸਨੂੰ ਲੰਮੇ ਸਮੇਂ ਚੱਲਣ ਵਾਲੀ child process ਵਜੋਂ ਲਾਂਚ ਕਰਦੇ ਹਨ, ਅਤੇ JSON-RPC ਲਈ ਦੋ-ਦਿਸ਼ੀ stdio ਚੈਨਲ ਖੁੱਲ੍ਹਾ ਰੱਖਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਸਾਡੇ VS Code ਐਕਸਟੈਂਸ਼ਨ ਅਤੇ Desktop App ਵਿੱਚ ਭੇਜੇ ਗਏ artifact ਵਿੱਚ ਪਲੇਟਫਾਰਮ-ਖਾਸ Codex ਬਾਈਨਰੀ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ ਅਤੇ ਇਸਨੂੰ ਟੈਸਟ ਕੀਤੇ ਵਰਜਨ ਨਾਲ pin ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਜੋ ਕਲਾਇੰਟ ਹਮੇਸ਼ਾਂ ਓਹੀ bits ਚਲਾਏ ਜੋ ਅਸੀਂ ਵੈਲਿਡੇਟ ਕੀਤੇ ਹਨ।

ਹਰ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਕਲਾਇੰਟ ਅਪਡੇਟ ਵਾਰ-ਵਾਰ ਨਹੀਂ ਭੇਜ ਸਕਦੀ। Xcode ਵਰਗੇ ਕੁਝ ਭਾਗੀਦਾਰ ਰਿਲੀਜ਼ ਚੱਕਰਾਂ ਨੂੰ ਵੱਖ ਰੱਖਦੇ ਹਨ: ਕਲਾਇੰਟ ਨੂੰ ਸਥਿਰ ਰੱਖ ਕੇ, ਲੋੜ ਪੈਣ 'ਤੇ ਇਸਨੂੰ ਨਵੀਂ App Server ਬਾਈਨਰੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ। ਇਸ ਨਾਲ ਉਹ ਸਰਵਰ-ਸਾਈਡ ਸੁਧਾਰਾਂ ਨੂੰ ਅਪਣਾਉਂਦੇ ਹਨ, ਜਿਵੇਂ Codex core ਵਿੱਚ ਵਧੀਆ auto-compaction ਜਾਂ ਨਵੀਆਂ ਸਮਰਥਿਤ config keys, ਅਤੇ ਕਲਾਇੰਟ ਰਿਲੀਜ਼ ਦੀ ਉਡੀਕ ਬਿਨਾਂ bug fixes ਜਾਰੀ ਕਰ ਸਕਦੇ ਹਨ। App Server ਦੀ JSON-RPC ਸਰਫੇਸ ਨੂੰ backward compatible ਬਣਾਇਆ ਗਿਆ ਹੈ, ਇਸ ਲਈ ਪੁਰਾਣੇ ਕਲਾਇੰਟ ਨਵੇਂ ਸਰਵਰਾਂ ਨਾਲ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਗੱਲ ਕਰ ਸਕਦੇ ਹਨ।

Codex Web

Codex ਵੈੱਬ ਇੰਟਰਫੇਸ ਦੀ ਸਕ੍ਰੀਨਸ਼ਾਟ ਜਿਸ ਵਿੱਚ “Update login success message” ਸਿਰਲੇਖ ਵਾਲਾ ਅਪਡੇਟ ਦਿਖਾਇਆ ਗਿਆ ਹੈ। ਖੱਬੇ ਪੈਨਲ ਵਿੱਚ ਬਦਲਾਵਾਂ, ਟੈਸਟਾਂ ਅਤੇ ਸੋਧੀਆਂ ਫ਼ਾਈਲਾਂ ਦਾ ਸਾਰ ਹੈ, ਜਦਕਿ ਸੱਜੇ ਪੈਨਲ ਵਿੱਚ login.rs ਲਈ code diff ਹੈ ਜਿਸ ਵਿੱਚ login success message ਦੀ ਭਾਸ਼ਾ ਅਪਡੇਟ ਕੀਤੀ ਗਈ ਹੈ।

Codex Web Codex harness ਵਰਤਦਾ ਹੈ, ਪਰ ਇਸਨੂੰ ਇੱਕ container ਮਾਹੌਲ ਵਿੱਚ ਚਲਾਉਂਦਾ ਹੈ। ਇੱਕ worker checked-out ਵਰਕਸਪੇਸ ਨਾਲ container ਤਿਆਰ ਕਰਦਾ ਹੈ, ਉਸ ਦੇ ਅੰਦਰ App Server ਬਾਈਨਰੀ ਲਾਂਚ ਕਰਦਾ ਹੈ, ਅਤੇ stdio² ਉੱਤੇ ਲੰਮੇ ਸਮੇਂ ਵਾਲਾ JSON-RPC ਚੈਨਲ ਬਣਾਈ ਰੱਖਦਾ ਹੈ। ਵੈੱਬ ਐਪ, ਜੋ ਯੂਜ਼ਰ ਦੇ ਬ੍ਰਾਊਜ਼ਰ ਟੈਬ ਵਿੱਚ ਚੱਲਦੀ ਹੈ, HTTP ਅਤੇ SSE ਰਾਹੀਂ Codex backend ਨਾਲ ਗੱਲ ਕਰਦੀ ਹੈ, ਜੋ worker ਦੁਆਰਾ ਬਣੇ task events ਨੂੰ stream ਕਰਦਾ ਹੈ। ਇਸ ਨਾਲ browser-side UI ਹਲਕਾ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਸਾਨੂੰ desktop ਤੇ web ਦੋਵਾਂ 'ਤੇ ਇਕਸਾਰ runtime ਮਿਲਦਾ ਹੈ।

ਕਿਉਂਕਿ ਵੈੱਬ ਸੈਸ਼ਨ ਅਸਥਾਈ ਹੁੰਦੇ ਹਨ, ਜਿਵੇਂ ਟੈਬ ਬੰਦ ਹੋ ਜਾਣਾ ਜਾਂ ਨੈੱਟਵਰਕ ਟੁੱਟ ਜਾਣਾ, ਇਸ ਲਈ ਵੈੱਬ ਐਪ ਲੰਮੇ ਸਮੇਂ ਚੱਲਣ ਵਾਲੇ ਕੰਮਾਂ ਲਈ source of truth ਨਹੀਂ ਹੋ ਸਕਦੀ। ਸਟੇਟ ਅਤੇ ਪ੍ਰਗਤੀ ਨੂੰ ਸਰਵਰ 'ਤੇ ਰੱਖਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਟੈਬ ਗਾਇਬ ਹੋ ਜਾਣ 'ਤੇ ਵੀ ਕੰਮ ਜਾਰੀ ਰਹਿੰਦਾ ਹੈ। ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰੋਟੋਕੋਲ ਅਤੇ ਸੇਵ ਕੀਤੇ thread sessions ਨਾਲ ਨਵਾਂ ਸੈਸ਼ਨ ਮੁੜ ਜੁੜ ਸਕਦਾ ਹੈ, ਜਿੱਥੇ ਕੰਮ ਛੱਡਿਆ ਸੀ ਉੱਥੋਂ ਅੱਗੇ ਵਧ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਵਿੱਚ ਸਟੇਟ ਮੁੜ ਬਣਾਏ ਬਿਨਾਂ ਕੈਚ ਅੱਪ ਕਰ ਸਕਦਾ ਹੈ।

TUI/Codex CLI

Codex CLI ਚਲਾਉਂਦੇ terminal ਦੀ ਸਕ੍ਰੀਨਸ਼ਾਟ। ਇਸ ਵਿੱਚ OpenAI Codex ਬੈਨਰ, model gpt-5.2-codex medium, ਯੂਜ਼ਰ ਕਮਾਂਡ “ਮੈਨੂੰ app server ਸਮਝਾਓ,” ਅਤੇ “Working” ਸਥਿਤੀ ਦਿਖਾਈ ਗਈ ਹੈ। ਹੇਠਾਂ ਇੱਕ ਸੁਝਾਅ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ: “@filename ਲਈ ਟੈਸਟ ਲਿਖੋ,” ਨਾਲ shortcut ਵਿਕਲਪ ਹਨ।

ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ, TUI ਇੱਕ “native” ਕਲਾਇੰਟ ਸੀ ਜੋ ਏਜੰਟ ਲੂਪ ਦੇ ਨਾਲ ਉਸੇ ਪ੍ਰੋਸੈਸ ਵਿੱਚ ਚੱਲਦਾ ਸੀ ਅਤੇ app-server ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਥਾਂ ਸਿੱਧਾ Rust core types ਨਾਲ ਗੱਲ ਕਰਦਾ ਸੀ। ਇਸ ਨਾਲ ਸ਼ੁਰੂਆਤੀ iteration ਤੇਜ਼ ਸੀ, ਪਰ ਇਸ ਨੇ TUI ਨੂੰ ਇੱਕ special-case ਸਰਫੇਸ ਵੀ ਬਣਾ ਦਿੱਤਾ।

ਹੁਣ ਜਦੋਂ App Server ਮੌਜੂਦ ਹੈ, ਅਸੀਂ TUI ਨੂੰ refactor ਕਰਨ⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹਾਂ ਤਾਂ ਜੋ ਇਹ ਵੀ ਕਿਸੇ ਹੋਰ ਕਲਾਇੰਟ ਵਾਂਗ ਵਰਤਾਅ ਕਰੇ: ਇੱਕ App Server child process ਲਾਂਚ ਕਰੇ, stdio ਉੱਤੇ JSON-RPC ਬੋਲੇ, ਅਤੇ ਓਹੀ streaming events ਅਤੇ approvals render ਕਰੇ। ਇਸ ਨਾਲ ਅਜਿਹੇ workflows ਖੁਲ੍ਹਦੇ ਹਨ ਜਿੱਥੇ TUI ਕਿਸੇ remote machine 'ਤੇ ਚੱਲ ਰਹੇ Codex ਸਰਵਰ ਨਾਲ ਜੁੜ ਸਕਦੀ ਹੈ, ਏਜੰਟ ਨੂੰ compute ਦੇ ਨੇੜੇ ਰੱਖ ਸਕਦੀ ਹੈ, ਅਤੇ ਲੈਪਟਾਪ ਦੇ sleep ਜਾਂ disconnect ਹੋਣ 'ਤੇ ਵੀ ਕੰਮ ਜਾਰੀ ਰੱਖ ਸਕਦੀ ਹੈ, ਜਦਕਿ ਲਾਈਵ ਅਪਡੇਟ ਅਤੇ ਕੰਟਰੋਲ ਲੋਕਲ ਹੀ ਮਿਲਦੇ ਰਹਿੰਦੇ ਹਨ।

ਸਹੀ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਚੋਣ

Codex App Server ਉਹ first-class ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਵਿਧੀ ਹੋਵੇਗੀ ਜਿਸਨੂੰ ਅਸੀਂ ਅੱਗੇ ਵੀ ਬਣਾਈ ਰੱਖਾਂਗੇ, ਪਰ ਹੋਰ ਕੁਝ ਵਿਧੀਆਂ ਵੀ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਸੀਮਿਤ ਹੈ। ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਅਸੀਂ ਸਿਫਾਰਸ਼ ਕਰਾਂਗੇ ਕਿ ਕਲਾਇੰਟ Codex ਨਾਲ ਇੰਟੀਗ੍ਰੇਟ ਕਰਨ ਲਈ Codex App Server ਵਰਤਣ, ਪਰ ਵੱਖ-ਵੱਖ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਵਿਧੀਆਂ ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਫਾਇਦੇ-ਨੁਕਸਾਨਾਂ ਨੂੰ ਵੇਖਣਾ ਲਾਭਦਾਇਕ ਹੈ। ਹੇਠਾਂ Codex ਚਲਾਉਣ ਦੇ ਸਭ ਤੋਂ ਆਮ ਤਰੀਕੇ ਅਤੇ ਕਦੋਂ ਕਿਹੜਾ ਤਰੀਕਾ ਚੰਗਾ ਫਿੱਟ ਹੋ ਸਕਦਾ ਹੈ, ਦਿੱਤੇ ਹਨ।

JSON-RPC ਪ੍ਰੋਟੋਕੋਲ

MCP ਸਰਵਰ ਵਜੋਂ Codex

codex mcp-server⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਚਲਾਓ ਅਤੇ ਕਿਸੇ ਵੀ ਅਜੇਹੇ MCP ਕਲਾਇੰਟ ਤੋਂ ਜੁੜੋ ਜੋ stdio servers ਨੂੰ ਸਮਰਥਨ ਦਿੰਦਾ ਹੋਵੇ, ਜਿਵੇਂ OpenAI Agents SDK⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ)। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ MCP-ਅਧਾਰਿਤ workflow ਹੈ ਅਤੇ ਤੁਸੀਂ Codex ਨੂੰ callable tool ਵਜੋਂ ਵਰਤਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਹ ਵਧੀਆ ਚੋਣ ਹੈ। ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਓਹੀ ਮਿਲਦਾ ਹੈ ਜੋ MCP expose ਕਰਦਾ ਹੈ, ਇਸ ਲਈ Codex-ਖਾਸ interactions ਜੋ ਵੱਧ ਸਮ੍ਰਿੱਧ session semantics 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ, ਜਿਵੇਂ diff updates, MCP ਐਂਡਪੌਇੰਟਸ ਰਾਹੀਂ ਸਾਫ਼ ਤੌਰ 'ਤੇ ਮੈਪ ਨਾ ਹੋ ਸਕਣ।

ਕਰਾਸ-ਪ੍ਰੋਵਾਈਡਰ ਏਜੰਟ harness ਪ੍ਰੋਟੋਕੋਲ

ਕੁਝ ecosystem ਐਸਾ portable interface ਦਿੰਦੇ ਹਨ ਜੋ ਕਈ model providers ਅਤੇ runtimes ਨੂੰ ਟਾਰਗੇਟ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਇੱਕ abstraction ਚਾਹੁੰਦੇ ਹੋ ਜੋ ਕਈ ਏਜੰਟਾਂ ਦਾ ਸਮਨਵਯ ਕਰੇ, ਤਾਂ ਇਹ ਚੰਗੀ ਚੋਣ ਹੋ ਸਕਦੀ ਹੈ। ਪਰ ਸਮਝੌਤਾ ਇਹ ਹੈ ਕਿ ਇਹ ਪ੍ਰੋਟੋਕੋਲ ਅਕਸਰ ਸਮਰਥਾਵਾਂ ਦੇ ਸਾਂਝੇ subset 'ਤੇ ਆ ਟਿਕਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਹੋਰ ਸਮ੍ਰਿੱਧ interactions ਨੂੰ ਦਰਸਾਉਣਾ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ provider-ਖਾਸ tools ਅਤੇ session semantics ਮਹੱਤਵਪੂਰਣ ਹੋਣ। ਇਹ ਖੇਤਰ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲ ਰਿਹਾ ਹੈ, ਅਤੇ ਜਿਵੇਂ-ਜਿਵੇਂ ਅਸੀਂ ਅਸਲ ਦੁਨੀਆ ਦੇ ਏਜੰਟ workflows ਨੂੰ ਦਰਸਾਉਣ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ primitives ਸਮਝਦੇ ਹਾਂ, ਸਾਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਹੋਰ ਸਾਂਝੇ standards ਉਭਰਨਗੇ। skills⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਇਸ ਦੀ ਇੱਕ ਚੰਗੀ ਉਦਾਹਰਨ ਹੈ।

Codex App Server

ਜੇ ਤੁਸੀਂ ਪੂਰੇ Codex harness ਨੂੰ ਇੱਕ ਸਥਿਰ, UI-ਅਨੁਕੂਲ event stream ਵਜੋਂ expose ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ App Server ਚੁਣੋ। ਤੁਹਾਨੂੰ ਏਜੰਟ ਲੂਪ ਦੀ ਪੂਰੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦੇ ਨਾਲ Sign in with ChatGPT, model discovery ਅਤੇ configuration management ਵਰਗੀਆਂ ਹੋਰ ਸਹਾਇਕ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵੀ ਮਿਲਦੀਆਂ ਹਨ। ਮੁੱਖ ਲਾਗਤ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਦਾ ਕੰਮ ਹੈ, ਕਿਉਂਕਿ ਤੁਹਾਨੂੰ ਆਪਣੀ ਭਾਸ਼ਾ ਵਿੱਚ client-side JSON-RPC binding ਬਣਾਉਣੀ ਪੈਂਦੀ ਹੈ। ਪਰ ਅਮਲ ਵਿੱਚ, ਜੇ ਤੁਸੀਂ Codex ਨੂੰ JSON ਸਕੀਮਾ ਅਤੇ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਉਹ ਕਾਫ਼ੀ ਭਾਰੀ ਕੰਮ ਆਪਣੇ ਆਪ ਕਰ ਸਕਦਾ ਹੈ। ਜਿਨ੍ਹਾਂ ਕਈ ਟੀਮਾਂ ਨਾਲ ਅਸੀਂ ਕੰਮ ਕੀਤਾ, ਉਹ Codex ਦੀ ਮਦਦ ਨਾਲ ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ ਕਾਰਗਰ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਬਣਾਉਣ ਵਿੱਚ ਸਫਲ ਰਹੀਆਂ।

Codex ਐਮਬੈਡ ਕਰਨ ਦੇ ਹੋਰ ਤਰੀਕੇ

Codex Exec⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ)

ਇੱਕ ਹਲਕਾ, ਸਕ੍ਰਿਪਟ ਕਰਨ ਯੋਗ CLI ਮੋਡ, ਜੋ ਇਕ-ਵਾਰ ਵਾਲੇ ਕੰਮਾਂ ਅਤੇ CI ਰਨਾਂ ਲਈ ਹੈ। ਇਹ automation ਅਤੇ pipelines ਲਈ ਚੰਗਾ ਫਿੱਟ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਇੱਕੋ ਕਮਾਂਡ ਬਿਨਾਂ ਇੰਟਰਐਕਸ਼ਨ ਦੇ ਪੂਰੀ ਹੋ ਜਾਵੇ, ਲੌਗਾਂ ਲਈ structured output stream ਕਰੇ, ਅਤੇ ਸਫਲਤਾ ਜਾਂ ਅਸਫਲਤਾ ਦਾ ਸਪਸ਼ਟ ਸੰਕੇਤ ਦੇ ਕੇ ਬੰਦ ਹੋ ਜਾਵੇ।

Codex SDK⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ)

ਇੱਕ TypeScript ਲਾਇਬ੍ਰੇਰੀ ਜੋ ਤੁਹਾਡੀ ਆਪਣੀ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਅੰਦਰੋਂ ਲੋਕਲ Codex ਏਜੰਟਾਂ ਨੂੰ ਪ੍ਰੋਗਰਾਮਕ ਤਰੀਕੇ ਨਾਲ ਕੰਟਰੋਲ ਕਰਨ ਲਈ ਹੈ। ਇਹ ਉਸ ਵੇਲੇ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਵੱਖਰਾ JSON-RPC ਕਲਾਇੰਟ ਬਣਾਏ ਬਿਨਾਂ server-side tools ਅਤੇ workflows ਲਈ native library interface ਚਾਹੁੰਦੇ ਹੋ। ਕਿਉਂਕਿ ਇਹ App Server ਤੋਂ ਪਹਿਲਾਂ ਰਿਲੀਜ਼ ਹੋਇਆ ਸੀ, ਇਸ ਵੇਲੇ ਇਹ ਘੱਟ ਭਾਸ਼ਾਵਾਂ ਅਤੇ ਛੋਟੀ ਸਰਫੇਸ ਏਰੀਆ ਨੂੰ ਹੀ ਸਮਰਥਨ ਦਿੰਦਾ ਹੈ। ਜੇ ਡਿਵੈਲਪਰ ਰੁਚੀ ਹੋਈ, ਤਾਂ ਅਸੀਂ ਹੋਰ SDKs ਜੋ App Server ਪ੍ਰੋਟੋਕੋਲ ਨੂੰ wrap ਕਰਦੀਆਂ ਹੋਣ, ਸ਼ਾਮਲ ਕਰ ਸਕਦੇ ਹਾਂ ਤਾਂ ਜੋ ਟੀਮਾਂ JSON-RPC bindings ਲਿਖੇ ਬਿਨਾਂ harness ਦੀ ਹੋਰ ਵੱਡੀ ਸਰਫੇਸ ਕਵਰ ਕਰ ਸਕਣ।

ਇਸਨੂੰ ਅੱਗੇ ਵਧਾਉਣਾ

ਇਸ ਪੋਸਟ ਵਿੱਚ ਅਸੀਂ ਸਾਂਝਾ ਕੀਤਾ ਕਿ ਏਜੰਟਾਂ ਨਾਲ ਇੰਟਰਐਕਟ ਕਰਨ ਲਈ ਨਵਾਂ ਮਿਆਰ ਡਿਜ਼ਾਇਨ ਕਰਨ ਵੱਲ ਸਾਡਾ ਰੁਖ ਕੀ ਹੈ ਅਤੇ Codex harness ਨੂੰ ਇੱਕ ਸਥਿਰ, ਕਲਾਇੰਟ-ਅਨੁਕੂਲ ਪ੍ਰੋਟੋਕੋਲ ਵਿੱਚ ਕਿਵੇਂ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਅਸੀਂ ਕਵਰ ਕੀਤਾ ਕਿ App Server Codex core ਨੂੰ ਕਿਵੇਂ expose ਕਰਦਾ ਹੈ, ਕਲਾਇੰਟਾਂ ਨੂੰ ਪੂਰਾ ਏਜੰਟ ਲੂਪ ਕਿਵੇਂ ਚਲਾਉਣ ਦਿੰਦਾ ਹੈ, ਅਤੇ TUI, ਲੋਕਲ IDE ਇੰਟੀਗ੍ਰੇਸ਼ਨਾਂ ਅਤੇ ਵੈੱਬ runtime ਸਮੇਤ ਕਈ ਤਰ੍ਹਾਂ ਦੀਆਂ ਸਰਫੇਸਾਂ ਨੂੰ ਕਿਵੇਂ ਸ਼ਕਤੀ ਦਿੰਦਾ ਹੈ।

ਜੇ ਇਸ ਨਾਲ ਤੁਹਾਡੇ ਆਪਣੇ workflows ਵਿੱਚ Codex ਨੂੰ ਇੰਟੀਗ੍ਰੇਟ ਕਰਨ ਦੇ ਵਿਚਾਰ ਜਾਗੇ ਹਨ, ਤਾਂ App Server ਨੂੰ ਇੱਕ ਵਾਰੀ ਅਜ਼ਮਾਉਣਾ ਚੰਗਾ ਰਹੇਗਾ। ਸਾਰਾ source code Codex CLI ਦੀ open-source repo⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਵਿੱਚ ਉਪਲਬਧ ਹੈ। ਆਪਣੇ ਫੀਡਬੈਕ ਅਤੇ feature requests ਸਾਂਝੇ ਕਰਨ ਲਈ ਨਿਸ਼ਚਿੰਤ ਰਹੋ। ਅਸੀਂ ਤੁਹਾਡੇ ਤੋਂ ਸੁਣਨ ਲਈ ਉਤਸ਼ਾਹਿਤ ਹਾਂ ਅਤੇ ਏਜੰਟਾਂ ਨੂੰ ਹਰ ਕਿਸੇ ਲਈ ਹੋਰ ਪਹੁੰਚਯੋਗ ਬਣਾਉਂਦੇ ਰਹਿਣ ਲਈ ਬੱਧਪ੍ਰਤਿਬੱਧ ਹਾਂ।

ਲੇਖਕ

Celia Chen

ਆਭਾਰ

ਮਾਈਕਲ ਬੋਲਿਨ, ਓਵਨ ਲਿਨ, ਐਰਿਕ ਟਰਾਟ ਅਤੇ ਰਾਸਮਸ ਰਾਇਗਾਰਡ ਦਾ ਵਿਸ਼ੇਸ਼ ਧੰਨਵਾਦ, ਜਿਨ੍ਹਾਂ ਨੇ ਇਸ ਪੋਸਟ ਵਿੱਚ ਯੋਗਦਾਨ ਦਿੱਤਾ, ਅਤੇ ਪੂਰੀ Codex ਟੀਮ ਦਾ ਵੀ, ਜਿਸਨੇ App Server 'ਤੇ ਕੰਮ ਕੀਤਾ।

ਫੁੱਟਨੋਟਸ

1
ਅਸੀਂ “JSON‑RPC lite” ਰੂਪ ਵਰਤਦੇ ਹਾਂ: ਇਹ request/response/notification ਵਾਲਾ ਢਾਂਚਾ ਬਣਾਈ ਰੱਖਦਾ ਹੈ, ਪਰ "jsonrpc": "2.0" ਹੈਡਰ ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ ਅਤੇ strict JSON‑RPC 2.0 ਦੀ ਥਾਂ stdio ਉੱਤੇ JSONL ਵਜੋਂ ਫ੍ਰੇਮ ਕੀਤਾ ਜਾਂਦਾ ਹੈ.
2
“stdio” ਨਾਲ ਭਾਵ container ਦੇ ਅੰਦਰ app-server ਦਾ stdin/stdout ਹੈ। hosted setups ਵਿੱਚ, ਇਹ streams ਅਕਸਰ container runtime ਤੱਕ ਇੱਕ persistent network connection, ਜਿਵੇਂ WebSocket-like, ਰਾਹੀਂ tunneled ਹੁੰਦੀਆਂ ਹਨ—ਇਸ ਲਈ ਇਹ stdio ਵਾਂਗ ਵਰਤਾਅ ਕਰਦਾ ਹੈ, ਭਾਵੇਂ ਇਹ ਸ਼ਾਬਦਿਕ local pipe ਨਾ ਹੋਵੇ.

ਪੜ੍ਹਦੇ ਰਹੋ

ਸਭ ਵੇਖੋ

Codex ਦੇ ਨਾਲ ਖੁਦ ਵਿੱਚ ਸੁਧਾਰ ਕਰਨ ਵਾਲੇ ਟੈਕਸ ਏਜੰਟ ਤਿਆਰ ਕਰਨਾ

ਇੰਜੀਨੀਅਰਿੰਗ27 ਮਈ 2026

Windows 'ਤੇ Codex ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਣ ਲਈ ਇੱਕ ਸੁਰੱਖਿਅਤ ਅਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਸੈਂਡਬਾਕਸ ਬਣਾਉਣਾ

ਇੰਜੀਨੀਅਰਿੰਗ13 ਮਈ 2026

Supercomputer networking to accelerate large scale AI training

ਇੰਜੀਨੀਅਰਿੰਗ5 ਮਈ 2026