# How to Use Codex CLI with Ace Data Cloud (Practical Terminal Guide)

When I try a coding agent, the question is rarely "can it answer questions?" The useful question is whether it can sit inside my normal terminal, read the project, make careful edits, and use the model provider I already run through.

![Cover](https://platform2.cdn.acedata.cloud/gpt-image/baa76de0-6b3a-4a37-8519-43ab97bb37fd_0.png)

This guide walks through a practical setup for running Codex CLI with Ace Data Cloud as the custom model provider. The end state is simple: you still run the normal `codex` command, but requests go through the OpenAI Responses-compatible endpoint at `https://api.acedata.cloud/v1`.

## What you are setting up

Codex CLI is a local programming agent that runs in the terminal. It can inspect code, modify files, execute commands, explain errors, and help with day-to-day development tasks without forcing you into a separate web UI.

The important part for this setup is that Codex CLI supports custom model providers. Ace Data Cloud exposes an OpenAI Responses-compatible proxy, so the CLI can send requests to:

```text
https://api.acedata.cloud/v1/responses
```

You configure that by editing Codex's global config file and pointing it at a provider named `acedatacloud`. The CLI then reads your API token from an environment variable called `ACEDATACLOUD_API_KEY`.

## Install Codex CLI

Codex CLI supports macOS, Linux, Windows, and WSL. If you already have Node.js 18 or higher installed, the npm path is the most direct:

```bash
npm install -g @openai/codex
```

On macOS, Homebrew is also available:

```bash
brew install --cask codex
```

After installation, reopen your terminal and check that the command is on your path:

```bash
codex --version
```

If you see `command not found`, it is usually a PATH issue. Close and reopen the terminal first; if that does not help, check the install output from npm or Homebrew and update your shell profile accordingly.

## Add your API token to the shell

Codex needs a token it can read from the current terminal session. Put the Ace Data Cloud API token into your shell configuration file, such as `~/.zshrc`, `~/.bashrc`, or `~/.bash_profile`:

```bash
export ACEDATACLOUD_API_KEY="{token}"
```

Replace `{token}` with your actual API token. Then reload the shell configuration. For example, if you use zsh:

```bash
source ~/.zshrc
```

I prefer using an environment variable here instead of pasting tokens directly into config files. It keeps the Codex configuration reusable, and it makes rotating the token later less annoying.

## Configure Codex to use Ace Data Cloud

Codex CLI reads its global configuration from `~/.codex/config.toml`. If the file does not exist yet, create it:

```bash
mkdir -p ~/.codex
touch ~/.codex/config.toml
```

Then add this configuration:

```toml
model_provider = "acedatacloud"
model = "gpt-5"
model_reasoning_effort = "high"

[model_providers.acedatacloud]
name = "Ace Data Cloud"
base_url = "https://api.acedata.cloud/v1"
env_key = "ACEDATACLOUD_API_KEY"
wire_api = "responses"
```

Here is what each field is doing:

- `model_provider` selects the default provider and must match the provider block below.
- `model` sets the default model Codex will use, such as `gpt-5`.
- `model_reasoning_effort` controls reasoning intensity; common values are `low`, `medium`, and `high`.
- `base_url` points Codex at the Ace Data Cloud OpenAI-compatible endpoint.
- `env_key` tells Codex which environment variable contains the API token.
- `wire_api` must be `responses`, because this setup uses the OpenAI Responses API protocol.

If you previously logged into Codex CLI with an official OpenAI account, clear the cached login before switching providers:

```bash
codex logout
```

If that command is not available, you can remove the local auth cache directly:

```bash
rm -f ~/.codex/auth.json
```

## Start a project session and verify it

Move into a project and start Codex:

```bash
cd /path/to/your/project
codex
```

Inside the interactive interface, run:

```text
/model
```

You should see the model and provider reflected back, for example:

```text
Model: gpt-5
Provider: acedatacloud
```

If the provider is not `acedatacloud`, check two things first: whether `~/.codex/config.toml` was saved correctly, and whether the current shell can read `ACEDATACLOUD_API_KEY`.

The request flow is straightforward. Codex reads `model_provider`, loads `[model_providers.acedatacloud]`, gets the token from `ACEDATACLOUD_API_KEY`, and sends requests through `wire_api = "responses"` to `https://api.acedata.cloud/v1/responses`. Ace Data Cloud verifies the token, checks quota, forwards the request to the selected model channel, and records usage after completion.

## Switching models and setting project trust

The default model is controlled by the `model` field in `~/.codex/config.toml`. Common options in the document include `gpt-5`, `gpt-5-mini`, `gpt-5.6-sol`, `gpt-5.6-terra`, `gpt-5.6-luna`, `gpt-5.5`, `gpt-5.5-pro`, `gpt-4.1`, `o3`, and `o4-mini`.

For a temporary switch, pass the model when starting Codex:

```bash
codex --model gpt-5-mini
```

Codex also supports project-level trust settings:

```toml
[projects."/path/to/trusted/project"]
trust_level = "trusted"

[projects."/path/to/untrusted/project"]
trust_level = "untrusted"
```

Use `trusted` for projects where you are comfortable letting the agent execute commands and modify files. Use `untrusted` when opening unfamiliar repositories or code you have not reviewed yet.

For me, this is the part that makes the setup feel practical: the terminal workflow stays the same, while the provider layer becomes explicit and easy to change. If you want the source configuration details, the original guide is here: https://platform.acedata.cloud/documents/codex-terminal-integration