Connect Codex CLI

Add a custom Responses provider and a separate configuration profile to Codex CLI.

AELDER · SERVICE BASE URL

https://aelder.dev/v1

LOCAL CONFIGURATION

Let my agent set this up

Copy this task to an agent already running on your computer. Enter your API key locally when asked.

Help me connect Codex CLI to AELDER using this guide: https://aelder.dev/docs/codex/
Service Base URL: https://aelder.dev/v1
First inspect my installed version, active profile and configuration. Explain any mismatch with the guide before changing anything.
Use the documented local configuration or CLI method. Do not automate the GUI, install software or change permissions without asking.
Preserve existing accounts, providers, models, defaults, permissions and unrelated settings. Propose the smallest change, show a redacted diff, and back up any files before editing.
Have me enter my API key locally using the tool's secret storage or an environment variable. Never ask me to paste a key into chat, print it, or include it in a command, diff, log or commit.
Use the exact model ID I choose from my account's model list. Do not invent model IDs or assume every model supports every API format or tool feature.
Validate syntax and configuration loading before making any generation request. If there is no dry-run, say so.
Explain any proposed paid test, the model and what it sends, and ask for approval before running it. Do not send project files or private conversation history as a test.
Finish with the settings changed, checks performed and steps to restore the backup.

Codex CLI supports a custom model provider in config.toml. Current Codex uses the Responses API for this route: /v1/responses. A Chat Completions endpoint alone is insufficient.

Use this guide for an existing Codex CLI installation. Check that your installed release accepts the provider capability fields shown below; the example follows the current configuration schema. Availability in the CLI does not establish the same behavior in a hosted or managed Codex environment.

1. Prepare the key and model

Copy the Base URL above, including /v1. Choose an exact ID from the authenticated models endpoint. That model must support the Responses request format, streaming and tools required by Codex; appearing in the catalog proves availability to your key, not those capabilities.

Set SERVICE_API_KEY through your local secrets tooling, or read it in Bash or Zsh:

printf 'Service API key: '
IFS= read -r -s SERVICE_API_KEY
printf '\n'
export SERVICE_API_KEY

The hidden prompt keeps the literal key out of shell history. Do not supply the key in a chat or a codex -c argument.

2. Add a provider and profile

Open the config.toml in your effective CODEX_HOME, which normally defaults to ~/.codex/config.toml. Preserve the existing file and add these tables, choosing a different provider/profile name if my_api already exists:

[model_providers.my_api]
name = "My API"
base_url = "https://aelder.dev/v1"
env_key = "SERVICE_API_KEY"
wire_api = "responses"
requires_openai_auth = false
supports_websockets = false

[model_providers.my_api.capabilities]
remote_compaction = "unsupported"

[profiles.my_api]
model_provider = "my_api"
model = "YOUR_MODEL_ID"
web_search = "disabled"

Replace YOUR_MODEL_ID with the exact service ID. Keep the AELDER Base URL including /v1. env_key names an environment variable; do not replace it with the secret.

The provider appends /responses to its base URL. Do not add /responses or /chat/completions yourself. Keep wire_api = "responses"; current Codex does not offer a chat value.

This profile uses HTTP and local compaction. Hosted web search, Responses WebSockets and remote compaction require additional endpoint behavior that this connection guide does not establish. Leave them disabled until separately verified. Do not guess model context limits, reasoning settings or a Codex model catalog.

3. Start a fresh CLI session

From the terminal with the exported key, launch:

codex --profile my_api

Confirm the selected model in Codex’s session information. In an interactive session, /status shows the current configuration. A profile keeps this setup selectable without replacing your normal provider. Start a fresh session after changing the profile or key.

To change models, set another exact, compatible ID in the profile, or use the CLI’s --model option when launching that profile. /v1/models is an OpenAI-compatible availability list, not a Codex-native catalog: do not set model_catalog_url to it.

4. Verify generation

Reading the profile or opening /status is a local configuration check. Send “Reply with OK” when ready for a billable request and confirm the model and request in your service dashboard. Then try a small tool task in a disposable project before relying on a long coding run.

For 401 errors, check that the key is present in the process running Codex. For 404 errors, check /v1 and Responses support. For rejected tool, reasoning, compaction or streaming fields, check the selected model’s protocol capabilities. A successful short reply does not verify every Codex feature.

Sources: official OpenAI documentation for the configuration reference and Codex CLI. The documented native provider settings were reviewed; this service has not been tested end to end with Codex.

Need the key? Open your AELDER dashboard. For direct API calls, see the API reference.