# Complete ChatGPT/OpenAI API Request Flow Documentation
This document provides a comprehensive analysis of how codex-cli communicates with ChatGPT API endpoints, including exact endpoints, headers, authentication, request schemas, and implementation details.
This document provides a comprehensive analysis of how Codex sends requests to the ChatGPT/OpenAI API, including authentication, headers, request format, session management, and endpoints.
-**Configurable**: via `chatgpt_base_url` in config
-**Purpose**: Uninstall a plugin
#### 8. MCP Apps
### Primary Endpoints
-**Path**: `/backend-api/wham/apps`
-**Method**: WebSocket connection
-**Purpose**: MCP (Model Context Protocol) server communication
**Important Note**: When using ChatGPT OAuth authentication, the base instructions field in the request is **required** and should reference "Codex" specifically. The example from the blog post shows:
#### 2.1 Responses API (Main chat endpoint)
```json
-**Path**: `/v1/responses`
{
-**Method**: `POST`
"instructions":"You are Codex, based on GPT-5. You are running as a coding agent ..."
-**Transport**: HTTP (SSE) or WebSocket
}
-**Purpose**: Streaming chat completions
```
This appears to be a requirement for the ChatGPT backend API to accept requests properly.
When using the ChatGPT OAuth API, requests often include a `developer` role message in the input array. This is distinct from the `instructions` field:
```http
x-codex-installation-id: {installation_id}
```
-**`instructions` field**: Base system instructions (e.g., "You are Codex, based on GPT-5...")
#### Window/Turn Tracking
-**`developer` role message**: Additional contextual instructions injected as a message in the conversation
## Message Conversion Between OpenAI and Codex Formats
## 7. System Prompt (Instructions)
### Overview
### 7.1 Base Instructions
Codex uses the OpenAI Responses API format which is more structured than the traditional Chat Completions API. Understanding how to convert between standard OpenAI message formats and Codex's internal format is essential for implementing compatible clients.
**Location**: `codex-rs/protocol/src/models.rs`
```rust
pubstructBaseInstructions{
pubtext:String,
pubpersonality:Option<Personality>,
}
```
### Key Type Definitions
### 7.2 Instruction Sources (Priority Order)
#### Codex Internal Types (`ResponseInputItem` and `ResponseItem`)
This documentation provides a complete reference for implementing a standalone client that mimics Codex's request behavior to ChatGPT's backend API. Key takeaways:
For WebSocket transport, messages use a different structure:
1.**Authentication**: Uses OAuth2 device code flow with token refresh
2.**Headers**: Requires `Authorization`, `ChatGPT-Account-ID`, and various Codex-specific headers
3.**Format**: Uses custom `ResponseItem` format instead of OpenAI's `messages` array
4.**Transport**: Supports both HTTP/SSE and WebSocket with automatic fallback
5.**Session Management**: Uses conversation IDs, window generations, and turn state for routing
6.**Instructions**: Separate `instructions` field instead of system messages
```rust
All code locations reference the Codex Rust codebase for verification and deeper exploration.
// From codex-rs/codex-api/src/websocket.rs
// Request (WebSocket)
---
## 11. Detailed Request Examples with Tool Usage
### 11.1 Simple Text Request (No Tools)
**Request:**
```json
{
{
"type": "response.create",
"response": {
"model":"gpt-4",
"model":"gpt-4",
"instructions": "...",
"instructions":"You are a helpful coding assistant.",
A session represents an entire conversation from start to finish. Understanding the flow of requests and how conversation state is maintained is essential for implementing a compatible client.