Codex

Aurora is a good fit for Codex because Codex already targets the OpenAI Responses API.

Flow: Codex -> Aurora -> upstream model provider

Before you start

• Install Codex on your machine.
• Choose an Aurora master key, for example sk-aurora-....
• Make sure Aurora has the upstream provider key for the models you want to use.

1. Run Aurora

Start Aurora with a master key and an OpenAI provider key:

docker run --rm -p 8080:8080 \
-e AURORA_MASTER_KEY="sk-aurora-..." \
-e OPENAI_API_KEY="$OPENAI_API_KEY" \
aurorahq/aurora
 

2. Confirm the Responses API with curl

Before testing Codex itself, you can optionally verify that Aurora answers a normal Responses API request:

This step is optional. If you are sure you have configured a valid OPENAI_API_KEY in Aurora, you can skip it and go straight to step 3.

curl -s http://your-aurora-host/v1/responses \
-H "Authorization: Bearer sk-aurora-..." \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-4.1-mini",
"input": "Reply with exactly ok",
"max_output_tokens": 16
}'
 

If the gateway is wired correctly, the response will contain ok.

3. Configure Codex to use Aurora

Use a Responses-based provider in your Codex config file:

model_provider = "aurora" model = "gpt-4.1-mini"
[model_providers.aurora] name = "Aurora" base_url = "http://your-aurora-host/v1" env_key = "OPENAI_API_KEY" wire_api = "responses"
 

Then export the Aurora master key for that provider:

export OPENAI_API_KEY=sk-aurora-...
 

4. Run a Codex test prompt

codex exec -m gpt-4.1-mini 'Reply with exactly ok and no punctuation.'
 

The validated result was:

ok
 

DeepSeek V4

Codex sends POST /v1/responses. DeepSeek exposes chat completions instead of a native Responses API, so configure the first-class DeepSeek provider and let Aurora translate the request.

providers:
deepseek:
type: deepseek
base_url: "https://api.deepseek.com"
api_key: "${DEEPSEEK_API_KEY}"
 

If you previously configured DeepSeek as type: openai, change it to type: deepseek for Codex. The generic OpenAI provider forwards /responses upstream, while the DeepSeek provider translates /responses to /chat/completions.

See the DeepSeek guide for the full reasoning effort mapping table (DeepSeek V4 only accepts high and max, so Aurora maps low and medium up to high).

Then use the DeepSeek model name in Codex:

model_provider = "aurora" model = "deepseek-v4-pro"
[model_providers.aurora] name = "Aurora" base_url = "http://your-aurora-host/v1" env_key = "OPENAI_API_KEY" wire_api = "responses"
 

5. Check the traffic in Aurora

Open the Aurora dashboard audit logs:

http://your-aurora-host/admin/dashboard/audit

This lets you confirm that Codex is reaching Aurora and inspect the full request and response trail. From the same dashboard, you can keep following your Aurora traffic and usage.

Current status

• the recommended integration path is Codex custom provider -> standard http://your-aurora-host/v1
• Codex custom provider mode sends POST /v1/responses
• Codex 0.122.0 sends an uncompressed JSON request body in this path, so the old --disable enable_request_compression workaround is no longer required
• ChatGPT subscription sign-in can coexist with the custom provider, but the custom provider still requires the configured env_key

References

• OpenAI Codex discussion: Deprecating chat/completions support in Codex
• OpenAI Codex repository: openai/codex

Validated on April 21, 2026

This guide was validated against:

• a local Aurora instance on http://your-aurora-host
• Codex CLI 0.122.0 Local validation confirmed:
• POST /v1/responses returned 200 OK with curl
• codex exec returned ok through Codex -> Aurora -> OpenAI-compatible upstream
• Codex sent plain JSON to POST /v1/responses; no Content-Encoding: zstd header was present
• a ChatGPT-signed-in Codex session worked with the custom aurora provider when OPENAI_API_KEY was set to the Aurora master key
• the same custom provider failed without OPENAI_API_KEY, because the provider

env_key is still required