Primary navigation

Codex App Server

Embed Codex into your product with the app-server protocol

Codex app-server is the interface Codex uses to power rich clients (for example, the Codex VS Code extension). Use it when you want a deep integration inside your own product: authentication, conversation history, approvals, and streamed agent events. The app-server implementation is open source in the Codex GitHub repository (openai/codex/codex-rs/app-server). See the Open Source page for the full list of open-source Codex components.

If you are automating jobs or running Codex in CI, use the Codex SDK instead.

Protocol

Like MCP, codex app-server supports bidirectional communication and streams JSONL over stdio. The protocol is JSON-RPC 2.0, but it omits the "jsonrpc":"2.0" header.

Message schema

Requests include method, params, and id:

{ "method": "thread/start", "id": 10, "params": { "model": "gpt-5.1-codex" } }

Responses echo the id with either result or error:

{ "id": 10, "result": { "thread": { "id": "thr_123" } } }
{ "id": 10, "error": { "code": 123, "message": "Something went wrong" } }

Notifications omit id and use only method and params:

{ "method": "turn/started", "params": { "turn": { "id": "turn_456" } } }

You can generate a TypeScript schema or a JSON Schema bundle from the CLI. Each output is specific to the Codex version you ran, so the generated artifacts match that version exactly:

codex app-server generate-ts --out ./schemas
codex app-server generate-json-schema --out ./schemas

Getting started

  1. Start the server with codex app-server. It waits for JSONL over standard input and prints only protocol messages.
  2. Connect a client over stdio, then send initialize followed by the initialized notification.
  3. Start a thread and a turn, then keep reading notifications from stdout.

Example (Node.js / TypeScript):

import { spawn } from "node:child_process";
import readline from "node:readline";

const proc = spawn("codex", ["app-server"], {
  stdio: ["pipe", "pipe", "inherit"],
});
const rl = readline.createInterface({ input: proc.stdout });

const send = (message: unknown) => {
  proc.stdin.write(`${JSON.stringify(message)}\n`);
};

let threadId: string | null = null;

rl.on("line", (line) => {
  const msg = JSON.parse(line) as any;
  console.log("server:", msg);

  if (msg.id === 1 && msg.result?.thread?.id && !threadId) {
    threadId = msg.result.thread.id;
    send({
      method: "turn/start",
      id: 2,
      params: {
        threadId,
        input: [{ type: "text", text: "Summarize this repo." }],
      },
    });
  }
});

send({
  method: "initialize",
  id: 0,
  params: {
    clientInfo: {
      name: "my_product",
      title: "My Product",
      version: "0.1.0",
    },
  },
});
send({ method: "initialized", params: {} });
send({ method: "thread/start", id: 1, params: { model: "gpt-5.1-codex" } });

Core primitives

  • Thread: A conversation between a user and the Codex agent. Threads contain turns.
  • Turn: A single user request and the agent work that follows. Turns contain items and stream incremental updates.
  • Item: A unit of input or output (user message, agent message, command runs, file change, tool call, and more).

Use the thread APIs to create, list, or archive conversations. Drive a conversation with turn APIs and stream progress via turn notifications.

Lifecycle overview

  • Initialize once: Immediately after launching codex app-server, send an initialize request with your client metadata, then emit initialized. The server rejects any request before this handshake.
  • Start (or resume) a thread: Call thread/start for a new conversation, thread/resume to continue an existing one, or thread/fork to branch history into a new thread id.
  • Begin a turn: Call turn/start with the target threadId and user input. Optional fields override model, personality, cwd, sandbox policy, and more.
  • Stream events: After turn/start, keep reading notifications on stdout: item/started, item/completed, item/agentMessage/delta, tool progress, and other updates.
  • Finish the turn: The server emits turn/completed with final status when the model finishes or after a turn/interrupt cancellation.

Initialization

Clients must send a single initialize request before invoking any other method, then acknowledge with an initialized notification. Requests sent before initialization receive a Not initialized error, and repeated initialize calls return Already initialized.

The server returns the user agent string it will present to upstream services. Set clientInfo to identify your integration.

Important: Use clientInfo.name to identify your client for the OpenAI Compliance Logs Platform. If you are developing a new Codex integration intended for enterprise use, please contact OpenAI to get it added to a known clients list. For more context, see the Codex logs reference.

Example (from the Codex VS Code extension):

{
  "method": "initialize",
  "id": 0,
  "params": {
    "clientInfo": {
      "name": "codex_vscode",
      "title": "Codex VS Code Extension",
      "version": "0.1.0"
    }
  }
}

API overview

  • thread/start - create a new thread; emits thread/started and automatically subscribes you to turn/item events for that thread.
  • thread/resume - reopen an existing thread by id so later turn/start calls append to it.
  • thread/fork - fork a thread into a new thread id by copying stored history; emits thread/started for the new thread.
  • thread/read - read a stored thread by id without resuming it; set includeTurns to return full turn history.
  • thread/list - page through stored thread logs; supports cursor-based pagination plus modelProviders, sourceKinds, and archived filters.
  • thread/loaded/list - list the thread ids currently loaded in memory.
  • thread/archive - move a thread’s log file into the archived directory; returns {} on success.
  • thread/unarchive - restore an archived thread rollout back into the active sessions directory; returns the restored thread.
  • thread/rollback - drop the last N turns from the in-memory context and persist a rollback marker; returns the updated thread.
  • turn/start - add user input to a thread and begin Codex generation; responds with the initial turn and streams events.
  • turn/interrupt - request cancellation of an in-flight turn; success is {} and the turn ends with status: "interrupted".
  • review/start - kick off the Codex reviewer for a thread; emits enteredReviewMode and exitedReviewMode items.
  • command/exec - run a single command under the server sandbox without starting a thread/turn.
  • model/list - list available models (with effort options).
  • collaborationMode/list - list collaboration mode presets (experimental, no pagination).
  • skills/list - list skills for one or more cwd values (optional forceReload).
  • app/list - list available apps (connectors) with pagination.
  • skills/config/write - enable or disable skills by path.
  • mcpServer/oauth/login - start an OAuth login for a configured MCP server; returns an authorization URL and emits mcpServer/oauthLogin/completed on completion.
  • tool/requestUserInput - prompt the user with 1-3 short questions for a tool call (experimental); questions can set isOther for a free-form option.
  • config/mcpServer/reload - reload MCP server configuration from disk and queue a refresh for loaded threads.
  • mcpServerStatus/list - list MCP servers, tools, resources, and auth status (cursor + limit pagination).
  • feedback/upload - submit a feedback report (classification + optional reason/logs + conversation id).
  • config/read - fetch the effective configuration on disk after resolving configuration layering.
  • config/value/write - write a single configuration key/value to the user’s config.toml on disk.
  • config/batchWrite - apply configuration edits atomically to the user’s config.toml on disk.
  • configRequirements/read - fetch requirements from requirements.toml and/or MDM, including allow-lists and residency requirements (or null if you haven’t set any up).

Models

List models (model/list)

Call model/list to discover available models and their capabilities before rendering model or personality selectors.

{ "method": "model/list", "id": 6, "params": { "limit": 20 } }
{ "id": 6, "result": {
  "data": [{
    "id": "gpt-5.2-codex",
    "model": "gpt-5.2-codex",
    "displayName": "GPT-5.2 Codex",
    "defaultReasoningEffort": "medium",
    "reasoningEffort": [{
      "effort": "low",
      "description": "Lower latency"
    }],
    "supportsPersonality": true,
    "isDefault": true
  }],
  "nextCursor": null
} }

Each model entry can include:

  • reasoningEffort - supported effort options for the model.
  • defaultReasoningEffort - suggested default effort for clients.
  • supportsPersonality - whether the model supports personality-specific instructions such as /personality.
  • isDefault - whether the model is the recommended default.

Threads

  • thread/read reads a stored thread without subscribing to it; set includeTurns to include turns.
  • thread/list supports cursor pagination plus modelProviders, sourceKinds, and archived filtering.
  • thread/loaded/list returns the thread IDs currently in memory.
  • thread/archive moves the thread’s persisted JSONL log into the archived directory.
  • thread/unarchive restores an archived thread rollout back into the active sessions directory.
  • thread/rollback drops the last N turns from the in-memory context and records a rollback marker in the thread’s persisted JSONL log.

Start or resume a thread

Start a fresh thread when you need a new Codex conversation.

{ "method": "thread/start", "id": 10, "params": {
  "model": "gpt-5.1-codex",
  "cwd": "/Users/me/project",
  "approvalPolicy": "never",
  "sandbox": "workspaceWrite",
  "personality": "friendly"
} }
{ "id": 10, "result": {
  "thread": {
    "id": "thr_123",
    "preview": "",
    "modelProvider": "openai",
    "createdAt": 1730910000
  }
} }
{ "method": "thread/started", "params": { "thread": { "id": "thr_123" } } }

To continue a stored session, call thread/resume with the thread.id you recorded earlier. The response shape matches thread/start. You can also pass the same configuration overrides supported by thread/start, such as personality:

{ "method": "thread/resume", "id": 11, "params": {
  "threadId": "thr_123",
  "personality": "friendly"
} }
{ "id": 11, "result": { "thread": { "id": "thr_123" } } }

Resuming a thread does not update thread.updatedAt (or the rollout file’s modified time) by itself. The timestamp updates when you start a turn.

Dynamic tools supplied on thread/start (dynamicTools) are persisted in the thread rollout metadata and restored on thread/resume when you do not supply new dynamic tools.

To branch from a stored session, call thread/fork with the thread.id. This creates a new thread id and emits a thread/started notification for it:

{ "method": "thread/fork", "id": 12, "params": { "threadId": "thr_123" } }
{ "id": 12, "result": { "thread": { "id": "thr_456" } } }
{ "method": "thread/started", "params": { "thread": { "id": "thr_456" } } }

Read a stored thread (without resuming)

Use thread/read when you want stored thread data but do not want to resume the thread or subscribe to its events.

  • includeTurns - when true, the response includes the thread’s turns; when false or omitted, you get the thread summary only.
{ "method": "thread/read", "id": 19, "params": { "threadId": "thr_123", "includeTurns": true } }
{ "id": 19, "result": { "thread": { "id": "thr_123", "turns": [] } } }

Unlike thread/resume, thread/read does not load the thread into memory or emit thread/started.

List threads (with pagination & filters)

thread/list lets you render a history UI. Results default to newest-first by createdAt. Filters apply before pagination. Pass any combination of:

  • cursor - opaque string from a prior response; omit for the first page.
  • limit - server defaults to a reasonable page size if unset.
  • sortKey - created_at (default) or updated_at.
  • modelProviders - restrict results to specific providers; unset, null, or an empty array includes all providers.
  • sourceKinds - restrict results to specific thread sources. When omitted or [], the server defaults to interactive sources only: cli and vscode.
  • archived - when true, list archived threads only. When false or omitted, list non-archived threads (default).

sourceKinds accepts the following values:

  • cli
  • vscode
  • exec
  • appServer
  • subAgent
  • subAgentReview
  • subAgentCompact
  • subAgentThreadSpawn
  • subAgentOther
  • unknown

Example:

{ "method": "thread/list", "id": 20, "params": {
  "cursor": null,
  "limit": 25,
  "sortKey": "created_at"
} }
{ "id": 20, "result": {
  "data": [
    { "id": "thr_a", "preview": "Create a TUI", "modelProvider": "openai", "createdAt": 1730831111, "updatedAt": 1730831111 },
    { "id": "thr_b", "preview": "Fix tests", "modelProvider": "openai", "createdAt": 1730750000, "updatedAt": 1730750000 }
  ],
  "nextCursor": "opaque-token-or-null"
} }

When nextCursor is null, you have reached the final page.

List loaded threads

thread/loaded/list returns thread IDs currently loaded in memory.

{ "method": "thread/loaded/list", "id": 21 }
{ "id": 21, "result": { "data": ["thr_123", "thr_456"] } }

Archive a thread

Use thread/archive to move the persisted thread log (stored as a JSONL file on disk) into the archived sessions directory.

{ "method": "thread/archive", "id": 22, "params": { "threadId": "thr_b" } }
{ "id": 22, "result": {} }

Archived threads won’t appear in future calls to thread/list unless you pass archived: true.

Unarchive a thread

Use thread/unarchive to move an archived thread rollout back into the active sessions directory.

{ "method": "thread/unarchive", "id": 24, "params": { "threadId": "thr_b" } }
{ "id": 24, "result": { "thread": { "id": "thr_b" } } }

Turns

The input field accepts a list of items:

  • { "type": "text", "text": "Explain this diff" }
  • { "type": "image", "url": "https://.../design.png" }
  • { "type": "localImage", "path": "/tmp/screenshot.png" }

You can override configuration settings per turn (model, effort, personality, cwd, sandbox policy, summary). When specified, these settings become the defaults for later turns on the same thread. outputSchema applies only to the current turn. For sandboxPolicy.type = "externalSandbox", set networkAccess to restricted or enabled; otherwise use a boolean.

Start a turn

{ "method": "turn/start", "id": 30, "params": {
  "threadId": "thr_123",
  "input": [ { "type": "text", "text": "Run tests" } ],
  "cwd": "/Users/me/project",
  "approvalPolicy": "unlessTrusted",
  "sandboxPolicy": {
    "type": "workspaceWrite",
    "writableRoots": ["/Users/me/project"],
    "networkAccess": true
  },
  "model": "gpt-5.1-codex",
  "effort": "medium",
  "summary": "concise",
  "personality": "friendly",
  "outputSchema": {
    "type": "object",
    "properties": { "answer": { "type": "string" } },
    "required": ["answer"],
    "additionalProperties": false
  }
} }
{ "id": 30, "result": { "turn": { "id": "turn_456", "status": "inProgress", "items": [], "error": null } } }

Start a turn (invoke a skill)

Invoke a skill explicitly by including $<skill-name> in the text input and adding a skill input item alongside it.

{ "method": "turn/start", "id": 33, "params": {
  "threadId": "thr_123",
  "input": [
    { "type": "text", "text": "$skill-creator Add a new skill for triaging flaky CI and include step-by-step usage." },
    { "type": "skill", "name": "skill-creator", "path": "/Users/me/.codex/skills/skill-creator/SKILL.md" }
  ]
} }
{ "id": 33, "result": { "turn": { "id": "turn_457", "status": "inProgress", "items": [], "error": null } } }

Interrupt a turn

{ "method": "turn/interrupt", "id": 31, "params": { "threadId": "thr_123", "turnId": "turn_456" } }
{ "id": 31, "result": {} }

On success, the turn finishes with status: "interrupted".

Review

review/start runs the Codex reviewer for a thread and streams review items. Targets include:

  • uncommittedChanges
  • baseBranch (diff against a branch)
  • commit (review a specific commit)
  • custom (free-form instructions)

Use delivery: "inline" (default) to run the review on the existing thread, or delivery: "detached" to fork a new review thread.

Example request/response:

{ "method": "review/start", "id": 40, "params": {
  "threadId": "thr_123",
  "delivery": "inline",
  "target": { "type": "commit", "sha": "1234567deadbeef", "title": "Polish tui colors" }
} }
{ "id": 40, "result": {
  "turn": {
    "id": "turn_900",
    "status": "inProgress",
    "items": [
      { "type": "userMessage", "id": "turn_900", "content": [ { "type": "text", "text": "Review commit 1234567: Polish tui colors" } ] }
    ],
    "error": null
  },
  "reviewThreadId": "thr_123"
} }

For a detached review, use "delivery": "detached". The response is the same shape, but reviewThreadId will be the id of the new review thread (different from the original threadId). The server also emits a thread/started notification for that new thread before streaming the review turn.

Codex streams the usual turn/started notification followed by an item/started with an enteredReviewMode item:

{
  "method": "item/started",
  "params": {
    "item": {
      "type": "enteredReviewMode",
      "id": "turn_900",
      "review": "current changes"
    }
  }
}

When the reviewer finishes, the server emits item/started and item/completed containing an exitedReviewMode item with the final review text:

{
  "method": "item/completed",
  "params": {
    "item": {
      "type": "exitedReviewMode",
      "id": "turn_900",
      "review": "Looks solid overall..."
    }
  }
}

Use this notification to render the reviewer output in your client.

Command execution

command/exec runs a single command (argv array) under the server sandbox without creating a thread.

{ "method": "command/exec", "id": 50, "params": {
  "command": ["ls", "-la"],
  "cwd": "/Users/me/project",
  "sandboxPolicy": { "type": "workspaceWrite" },
  "timeoutMs": 10000
} }
{ "id": 50, "result": { "exitCode": 0, "stdout": "...", "stderr": "" } }

Use sandboxPolicy.type = "externalSandbox" if you already sandbox the server process and want Codex to skip its own sandbox enforcement. For external sandbox mode, set networkAccess to restricted (default) or enabled. For other sandbox policies, networkAccess is a boolean.

Notes:

  • The server rejects empty command arrays.
  • sandboxPolicy accepts the same shape used by turn/start (for example, dangerFullAccess, readOnly, workspaceWrite, externalSandbox).
  • When omitted, timeoutMs falls back to the server default.

Events

Event notifications are the server-initiated stream for thread lifecycles, turn lifecycles, and the items within them. After you start or resume a thread, keep reading stdout for thread/started, turn/*, and item/* notifications.

Turn events

  • turn/started - { turn } with the turn id, empty items, and status: "inProgress".
  • turn/completed - { turn } where turn.status is completed, interrupted, or failed; failures carry { error: { message, codexErrorInfo?, additionalDetails? } }.
  • turn/diff/updated - { threadId, turnId, diff } with the latest aggregated unified diff across every file change in the turn.
  • turn/plan/updated - { turnId, explanation?, plan } whenever the agent shares or changes its plan; each plan entry is { step, status } with status in pending, inProgress, or completed.
  • thread/tokenUsage/updated - usage updates for the active thread.

turn/diff/updated and turn/plan/updated currently include empty items arrays even when item events stream. Use item/* notifications as the source of truth for turn items.

Items

ThreadItem is the tagged union carried in turn responses and item/* notifications. Common item types include:

  • userMessage - {id, content} where content is a list of user inputs (text, image, or localImage).
  • agentMessage - {id, text} containing the accumulated agent reply.
  • plan - {id, text} containing proposed plan text in plan mode. Treat the final plan item from item/completed as authoritative.
  • reasoning - {id, summary, content} where summary holds streamed reasoning summaries and content holds raw reasoning blocks.
  • commandExecution - {id, command, cwd, status, commandActions, aggregatedOutput?, exitCode?, durationMs?}.
  • fileChange - {id, changes, status} describing proposed edits; changes list {path, kind, diff}.
  • mcpToolCall - {id, server, tool, status, arguments, result?, error?}.
  • collabToolCall - {id, tool, status, senderThreadId, receiverThreadId?, newThreadId?, prompt?, agentStatus?}.
  • webSearch - {id, query, action?} for web search requests issued by the agent.
  • imageView - {id, path} emitted when the agent invokes the image viewer tool.
  • enteredReviewMode - {id, review} sent when the reviewer starts.
  • exitedReviewMode - {id, review} emitted when the reviewer finishes.
  • contextCompaction - {id} emitted when Codex compacts the conversation history.

For webSearch.action, the action type can be search (query?, queries?), openPage (url?), or findInPage (url?, pattern?).

The legacy thread/compacted notification is deprecated; use the contextCompaction item instead.

All items emit two shared lifecycle events:

  • item/started - emits the full item when a new unit of work begins; the item.id matches the itemId used by deltas.
  • item/completed - sends the final item once work finishes; treat this as the authoritative state.

Item deltas

  • item/agentMessage/delta - appends streamed text for the agent message.
  • item/plan/delta - streams proposed plan text. The final plan item may not exactly equal the concatenated deltas.
  • item/reasoning/summaryTextDelta - streams readable reasoning summaries; summaryIndex increments when a new summary section opens.
  • item/reasoning/summaryPartAdded - marks a boundary between reasoning summary sections.
  • item/reasoning/textDelta - streams raw reasoning text (when supported by the model).
  • item/commandExecution/outputDelta - streams stdout/stderr for a command; append deltas in order.
  • item/fileChange/outputDelta - contains the tool call response of the underlying apply_patch tool call.

Errors

If a turn fails, the server emits an error event with { error: { message, codexErrorInfo?, additionalDetails? } } and then finishes the turn with status: "failed". When an upstream HTTP status is available, it appears in codexErrorInfo.httpStatusCode.

Common codexErrorInfo values include:

  • ContextWindowExceeded
  • UsageLimitExceeded
  • HttpConnectionFailed (4xx/5xx upstream errors)
  • ResponseStreamConnectionFailed
  • ResponseStreamDisconnected
  • ResponseTooManyFailedAttempts
  • BadRequest, Unauthorized, SandboxError, InternalServerError, Other

When an upstream HTTP status is available, the server forwards it in httpStatusCode on the relevant codexErrorInfo variant.

Approvals

Depending on a user’s Codex settings, command execution and file changes may require approval. The app-server sends a server-initiated JSON-RPC request to the client, and the client responds with { "decision": "accept" | "decline" } (plus optional acceptSettings for command approvals).

  • Requests include threadId and turnId - use them to scope UI state to the active conversation.
  • The server resumes or declines the work and ends the item with item/completed.

Command execution approvals

Order of messages:

  1. item/started shows the pending commandExecution item with command, cwd, and other fields.
  2. item/commandExecution/requestApproval includes itemId, threadId, turnId, optional reason or risk, plus parsedCmd for display.
  3. Client response accepts or declines (optionally setting acceptSettings).
  4. item/completed returns the final commandExecution item with status: completed | failed | declined.

File change approvals

Order of messages:

  1. item/started emits a fileChange item with proposed changes and status: "inProgress".
  2. item/fileChange/requestApproval includes itemId, threadId, turnId, and an optional reason.
  3. Client response accepts or declines.
  4. item/completed returns the final fileChange item with status: completed | failed | declined.

MCP tool-call approvals (apps)

App (connector) tool calls can also require approval. When an app tool call has side effects, the server may elicit approval with tool/requestUserInput and options such as Accept, Decline, and Cancel. If the user declines or cancels, the related mcpToolCall item completes with an error instead of running the tool.

Skills

Invoke a skill by including $<skill-name> in the user text input. Add a skill input item (recommended) so the server injects full skill instructions instead of relying on the model to resolve the name.

{
  "method": "turn/start",
  "id": 101,
  "params": {
    "threadId": "thread-1",
    "input": [
      {
        "type": "text",
        "text": "$skill-creator Add a new skill for triaging flaky CI."
      },
      {
        "type": "skill",
        "name": "skill-creator",
        "path": "/Users/me/.codex/skills/skill-creator/SKILL.md"
      }
    ]
  }
}

If you omit the skill item, the model will still parse the $<skill-name> marker and try to locate the skill, which can add latency.

Example:

$skill-creator Add a new skill for triaging flaky CI and include step-by-step usage.

Use skills/list to fetch the available skills (optionally scoped by cwds, with forceReload). When present, interface and dependencies are sourced from SKILL.json.

{ "method": "skills/list", "id": 25, "params": {
  "cwds": ["/Users/me/project"],
  "forceReload": false
} }
{ "id": 25, "result": {
  "data": [{
    "cwd": "/Users/me/project",
    "skills": [
      {
        "name": "skill-creator",
        "description": "Create or update a Codex skill",
        "enabled": true,
        "interface": {
          "displayName": "Skill Creator",
          "shortDescription": "Create or update a Codex skill"
        },
        "dependencies": {
          "tools": [
            {
              "type": "env_var",
              "value": "GITHUB_TOKEN",
              "description": "GitHub API token"
            },
            {
              "type": "mcp",
              "value": "github",
              "transport": "streamable_http",
              "url": "https://example.com/mcp"
            }
          ]
        }
      }
    ],
    "errors": []
  }]
} }

To enable or disable a skill by path:

{
  "method": "skills/config/write",
  "id": 26,
  "params": {
    "path": "/Users/me/.codex/skills/skill-creator/SKILL.md",
    "enabled": false
  }
}

Apps (connectors)

Use app/list to fetch available apps. In the CLI/TUI, /apps is the user-facing picker; in custom clients, call app/list directly.

{ "method": "app/list", "id": 50, "params": {
  "cursor": null,
  "limit": 50
} }
{ "id": 50, "result": {
  "data": [
    {
      "id": "demo-app",
      "name": "Demo App",
      "description": "Example connector for documentation.",
      "logoUrl": "https://example.com/demo-app.png",
      "installUrl": "https://chatgpt.com/apps/demo-app/demo-app",
      "isAccessible": true
    }
  ],
  "nextCursor": null
} }

Invoke an app by inserting $<app-slug> in the text input and adding a mention input item with the app://<id> path (recommended).

{
  "method": "turn/start",
  "id": 51,
  "params": {
    "threadId": "thread-1",
    "input": [
      {
        "type": "text",
        "text": "$demo-app Pull the latest updates from the team."
      },
      {
        "type": "mention",
        "name": "Demo App",
        "path": "app://demo-app"
      }
    ]
  }
}

Auth endpoints

The JSON-RPC auth/account surface exposes request/response methods plus server-initiated notifications (no id). Use these to determine auth state, start or cancel logins, logout, and inspect ChatGPT rate limits.

Authentication modes

Codex supports multiple authentication modes. The active mode is surfaced in account/updated.authMode and can be inferred from account/read.

  • API key (apikey) - the caller supplies an OpenAI API key and Codex stores it for API requests.
  • ChatGPT managed (chatgpt) - Codex owns the ChatGPT OAuth flow, persists tokens, and refreshes them automatically.
  • ChatGPT external tokens (chatgptAuthTokens) - a host app supplies idToken and accessToken directly. Tokens are stored in memory, and the host app must refresh them when asked.

API overview

  • account/read - fetch current account info; optionally refresh tokens.
  • account/login/start - begin login (apiKey, chatgpt, or chatgptAuthTokens).
  • account/login/completed (notify) - emitted when a login attempt finishes (success or error).
  • account/login/cancel - cancel a pending ChatGPT login by loginId.
  • account/logout - sign out; triggers account/updated.
  • account/updated (notify) - emitted whenever auth mode changes (authMode: apikey, chatgpt, chatgptAuthTokens, or null).
  • account/chatgptAuthTokens/refresh (server request) - request fresh externally managed ChatGPT tokens after an authorization failure.
  • account/rateLimits/read - fetch ChatGPT rate limits.
  • account/rateLimits/updated (notify) - emitted whenever a user’s ChatGPT rate limits change.
  • mcpServer/oauthLogin/completed (notify) - emitted after a mcpServer/oauth/login flow finishes; payload includes { name, success, error? }.

1) Check auth state

Request:

{ "method": "account/read", "id": 1, "params": { "refreshToken": false } }

Response examples:

{ "id": 1, "result": { "account": null, "requiresOpenaiAuth": false } }
{ "id": 1, "result": { "account": null, "requiresOpenaiAuth": true } }
{
  "id": 1,
  "result": { "account": { "type": "apiKey" }, "requiresOpenaiAuth": true }
}
{
  "id": 1,
  "result": {
    "account": {
      "type": "chatgpt",
      "email": "user@example.com",
      "planType": "pro"
    },
    "requiresOpenaiAuth": true
  }
}

Field notes:

  • refreshToken (boolean): set true to force a token refresh in managed ChatGPT mode. In external token mode (chatgptAuthTokens), this flag is ignored.
  • requiresOpenaiAuth reflects the active provider; when false, Codex can run without OpenAI credentials.

2) Log in with an API key

  1. Send:

    {
  "method": "account/login/start",
  "id": 2,
  "params": { "type": "apiKey", "apiKey": "sk-..." }
}

  2. Expect:

    { "id": 2, "result": { "type": "apiKey" } }

  3. Notifications:

    {
  "method": "account/login/completed",
  "params": { "loginId": null, "success": true, "error": null }
}
    { "method": "account/updated", "params": { "authMode": "apikey" } }

3) Log in with ChatGPT (browser flow)

  1. Start:

    { "method": "account/login/start", "id": 3, "params": { "type": "chatgpt" } }
    {
  "id": 3,
  "result": {
    "type": "chatgpt",
    "loginId": "<uuid>",
    "authUrl": "https://chatgpt.com/...&redirect_uri=http%3A%2F%2Flocalhost%3A<port>%2Fauth%2Fcallback"
  }
}

  2. Open authUrl in a browser; the app-server hosts the local callback.

  3. Wait for notifications:

    {
  "method": "account/login/completed",
  "params": { "loginId": "<uuid>", "success": true, "error": null }
}
    { "method": "account/updated", "params": { "authMode": "chatgpt" } }

3b) Log in with externally managed ChatGPT tokens (chatgptAuthTokens)

Use this mode when a host application owns the user’s ChatGPT auth lifecycle and supplies tokens directly.

  1. Send:

    {
  "method": "account/login/start",
  "id": 7,
  "params": {
    "type": "chatgptAuthTokens",
    "idToken": "<jwt>",
    "accessToken": "<jwt>"
  }
}

  2. Expect:

    { "id": 7, "result": { "type": "chatgptAuthTokens" } }

  3. Notifications:

    {
  "method": "account/login/completed",
  "params": { "loginId": null, "success": true, "error": null }
}
    {
  "method": "account/updated",
  "params": { "authMode": "chatgptAuthTokens" }
}

When the server receives a 401 Unauthorized, it may request refreshed tokens from the host app:

{
  "method": "account/chatgptAuthTokens/refresh",
  "id": 8,
  "params": { "reason": "unauthorized", "previousAccountId": "org-123" }
}
{ "id": 8, "result": { "idToken": "<jwt>", "accessToken": "<jwt>" } }

The server retries the original request after a successful refresh response. Respond promptly; requests time out after about 10 seconds.

4) Cancel a ChatGPT login

{ "method": "account/login/cancel", "id": 4, "params": { "loginId": "<uuid>" } }
{ "method": "account/login/completed", "params": { "loginId": "<uuid>", "success": false, "error": "..." } }

5) Logout

{ "method": "account/logout", "id": 5 }
{ "id": 5, "result": {} }
{ "method": "account/updated", "params": { "authMode": null } }

6) Rate limits (ChatGPT)

{ "method": "account/rateLimits/read", "id": 6 }
{ "id": 6, "result": { "rateLimits": { "primary": { "usedPercent": 25, "windowDurationMins": 15, "resetsAt": 1730947200 }, "secondary": null } } }
{ "method": "account/rateLimits/updated", "params": { "rateLimits": { } } }

Field notes:

  • usedPercent is current usage within the OpenAI quota window.
  • windowDurationMins is the quota window length.
  • resetsAt is a Unix timestamp (seconds) for the next reset.