Codex App Server

Embed Codex into a host product using the same protocol used by OpenAI's rich Codex clients. This skill is adaptable across Electron, Swift, Next.js, and other hosts by choosing the right transport and bridge pattern for each environment.

Start Here

1. Decide whether the request needs App Server or the Codex SDK.
2. Re-check the official docs if the request depends on the latest auth or protocol behavior.
3. Pick the closest bundled starter from assets/ for the target host.
4. Generate version-matched schemas with scripts/generate-schemas.sh before building a typed client.

Choose the Right Surface

• Use App Server when the host product needs embedded authentication, conversation history, approvals, streamed agent events, review mode, rate limits, or a custom UI around threads and turns.
• Use the Codex SDK for automation, CI, server-side jobs, or non-interactive workflows.
• Prefer stdio first for local desktop hosts that can spawn codex app-server. Use WebSocket when the host cannot manage a child process, when the UI is browser-based, or when a separate sidecar/service boundary is the cleaner architecture.
• Treat WebSocket and experimentalApi features as opt-in. They are useful, but they are not the safest production default.
• Desktop hosts like Electron and macOS Swift apps can usually use managed ChatGPT login comfortably because the browser flow returns to a localhost callback owned by app-server.
• Browser-first web apps usually need a server-side bridge or host-managed tokens. The documented managed ChatGPT flow returns an authUrl with a localhost callback, which is a poor default fit for a pure browser deployment.