# 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
## 6. Transport Mechanisms
### Overview
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.
### 6.1 HTTP (SSE - Server-Sent Events)
### Key Type Definitions
**Location**: `codex-rs/core/src/client.rs:1132`
#### Codex Internal Types (`ResponseInputItem` and `ResponseItem`)
1. POST to `/v1/responses`
2. Response: `Content-Type: text/event-stream`
3.**Events**:
-`response.created`
-`response.output_item.added`
-`response.output_item.done`
-`response.completed`
-`response.failed`
Codex uses two main types for messages:
### 6.2 WebSocket
1. **`ResponseInputItem`** - Messages sent TO the API
**Location**: `codex-rs/core/src/client.rs:1229`
2. **`ResponseItem`** - Messages received FROM the API
For WebSocket transport, messages use a different structure:
```rust
## Summary
// From codex-rs/codex-api/src/websocket.rs
// Request (WebSocket)
This documentation provides a complete reference for implementing a standalone client that mimics Codex's request behavior to ChatGPT's backend API. Key takeaways:
{
"type": "response.create",
"response": {
"model": "gpt-4",
"instructions": "...",
"input": [...],
"client_metadata": {
"x-codex-window-id": "...",
"x-openai-subagent": "..."
}
}
}
// Incremental request (subsequent requests in same turn)
1.**Authentication**: Uses OAuth2 device code flow with token refresh
{
2.**Headers**: Requires `Authorization`, `ChatGPT-Account-ID`, and various Codex-specific headers
"type": "response.create",
3.**Format**: Uses custom `ResponseItem` format instead of OpenAI's `messages` array
"previous_response_id": "resp_123",
4.**Transport**: Supports both HTTP/SSE and WebSocket with automatic fallback
"input": [...], // Only new items, not full history
5.**Session Management**: Uses conversation IDs, window generations, and turn state for routing
"response": { ... }
6.**Instructions**: Separate `instructions` field instead of system messages
-`additionalProperties: false` is typically included
- Tool definition is flatter
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.
### 12.4 Built-in Tool Types
### Lifecycle of a Session
Codex supports special built-in tool types not in standard OpenAI: