Troubleshoot Alibaba Cloud API keys in local Codex

Do not regenerate a key or rewrite the entire config for every failure. Authentication errors point first to the credential and host; model errors point to the exact model ID and workspace permission; protocol errors point to `wire_api` and Codex version; a Cloud-versus-local mismatch points to the product surface.

First confirm that the configured `env_key` name exactly matches the exported variable. Check only whether the variable exists; do not echo its value. Then compare the configured `base_url` with the API Host shown for the key in Model Studio. A Beijing key sent to a Singapore host is not a valid pairing.

If the host matches, inspect the key's current status, model permissions, and IP restrictions in the console. Resetting or deleting a key invalidates the old value. A key prefix cannot prove that the key is active or entitled to a particular model.

Copy the exact API model ID rather than using a console display name. Then verify that the model exists in the key's region and is allowed in the same workspace. Changing only the model string will not fix a workspace or regional mismatch.

Keep the host and model change in one controlled test. Start with the model and region combination shown in Alibaba's current Codex guide, verify one minimal prompt, and only then test another permitted model.

Current Codex uses the Responses API for custom providers. If the error says `wire_api = "chat" is no longer supported`, the configuration or selected model belongs to an older Chat Completions path. Update Codex, select a Responses-capable Alibaba model, and set `wire_api = "responses"`.

If Codex reports an unknown configuration field, compare the file with the current OpenAI advanced configuration reference and the current Alibaba integration page. Confirm that the provider block is in `~/.codex/config.toml`, the table name matches `model_provider`, and you are actually running the Codex binary you just updated.

A shell export belongs to that shell process and its children. If Codex CLI works in one terminal but the desktop app or IDE extension fails, the app probably did not receive `DASHSCOPE_API_KEY`. Fully quit and restart the client after configuring the approved environment source, or launch it from a shell that already has the variable.

Also check that all clients read the intended Codex home and `config.toml`. Multiple installations or a stale app process can make a correct file appear ineffective. Verify one client at a time before assuming the Alibaba endpoint is down.

Alibaba documents that some third-party switching tools can report HTTP 400 during a health check even when the actual Codex request works. Test by starting Codex from a fresh process and sending one small prompt through the configured provider.

The opposite also matters: a tool reporting that a key was saved does not prove model access. A valid result must come from the actual workspace host, permitted model, Responses route, and current Codex client.

If the Alibaba provider works locally and disappears when you open Codex Cloud, nothing has been lost from the local config. Codex Cloud is a separate ChatGPT-authenticated hosted workflow and does not import the local `model_provider` setting.

Keep the task local when Alibaba must be the model provider. Use Codex Cloud only when its own hosted model path is acceptable. An environment variable in Cloud can support application code, but it does not switch the agent model.