DurinDoor
Integrations

Codex

Configure Codex Responses requests with a DurinDoor provider, key, and model.

Codex CLI is an OpenAI Responses client. DurinDoor exposes POST /v1/responses and POST /v1/responses/compact. The dashboard writes a provider slot Codex already knows as 9router, with display name DurinDoor.

You need the gateway running, a DurinDoor API key, a coding model or combo, and the codex CLI (npm install -g @openai/codex).

Dashboard apply

  1. Open CLI Tools → OpenAI Codex CLI / App.
  2. Choose the endpoint, DurinDoor key, main model, and optional subagent model.
  3. Click Apply, then restart Codex.

Apply updates ~/.codex/config.toml and ~/.codex/auth.json on the gateway host. If Codex runs elsewhere, use Manual Config on that machine. Missing files are created. Invalid existing TOML or JSON causes refusing to overwrite it; repair or restore that file and retry. Other provider and MCP settings and existing ChatGPT tokens remain.

The selected provider slot is 9router with display name DurinDoor. The subagent model defaults to the main model. Choose a real key rather than the local placeholder when authentication is enforced.

Reset removes that provider slot, subagent settings, and API-key auth fields. It clears the root model fields only when the selected provider is still 9router.

Manual config

~/.codex/config.toml:

model = "provider/model-id"
model_provider = "9router"

[model_providers.9router]
name = "DurinDoor"
base_url = "http://localhost:20128/v1"
wire_api = "responses"

[agents.subagent]
model = "provider/model-id"

~/.codex/auth.json:

{
  "auth_mode": "apikey",
  "OPENAI_API_KEY": "YOUR_DURINDOOR_API_KEY"
}

Codex reads the key from auth.json, not from config.toml. Do not put api_key in the 9router table.

To run Codex after Apply:

codex --model provider/model-id "Explain the test strategy for this project."

Responses support

Codex uses /v1/responses and can call /v1/responses/compact. Streaming Responses requests receive an early SSE connection while the provider starts. Support for compaction, tools, and context still depends on the selected provider and model; test those operations before using a fallback combo for coding work.

Codex model discovery uses a Codex-specific list envelope. Use the exact IDs from the gateway, or a combo you created. The 9router provider slot in the example is intentional and remains supported.

Check it works

curl http://localhost:20128/v1/models \
  -H "Authorization: Bearer YOUR_DURINDOOR_API_KEY"

Then run codex --model provider/model-id "Reply with one short sentence." and confirm the request on Usage. Invalid API key almost always means an upstream OpenAI key in auth.json instead of the DurinDoor key. Apply failing with refusing to overwrite it means config.toml or auth.json is not a parseable object.

On this page

Edit on GitHub