# How to Use Codex CLI with Ace Data Cloud in Your Terminal

If you like the idea of an AI coding agent but do not want to leave the terminal, this guide walks through a practical Codex CLI setup using Ace Data Cloud as the OpenAI Responses-compatible provider.

![Codex CLI through Ace Data Cloud](https://platform2.cdn.acedata.cloud/gpt-image/eb7a87c9-1c40-47f5-9c8e-679cece6c4af_0.png)

## Why this setup is useful

Codex CLI is useful because it stays close to the place where many builders already work: the project directory, the shell, and the files that need to change. Instead of copying errors into a chat window, you can ask Codex to inspect a repository, explain structure, modify files, run commands, and help with everyday development tasks from the terminal.

The small but important configuration detail is that Codex CLI supports custom model providers. In this setup, Codex keeps its native terminal workflow, while requests go to Ace Data Cloud through an OpenAI Responses-compatible endpoint.

The documented `base_url` is `https://api.acedata.cloud/v1`. Codex then uses the Responses protocol, so requests are sent to `base_url + /responses`, which resolves to `https://api.acedata.cloud/v1/responses`.

That means there is no local proxy to run and no extra plugin layer to maintain. You are mainly changing provider configuration and where Codex reads the API token.

## Install Codex CLI

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

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

On macOS, Homebrew is also supported:

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

After installing, reopen your terminal and verify that the command is available:

```bash
codex --version
```

If you see `command not found`, do not debug the provider configuration yet. First make sure the install location is on your shell `PATH`, then open a fresh terminal and try the version command again.

## Add your API token to the shell

Codex needs a token, but it should not be hard-coded directly into the config file. The documented setup uses an environment variable named `ACEDATACLOUD_API_KEY`.

Add this to your shell profile, such as `~/.zshrc`, `~/.bashrc`, or `~/.bash_profile`:

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

Replace `{token}` with the API token from your Ace Data Cloud application. Then reload your shell profile:

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

Use the file that matches your shell. For example, if you added the variable to `~/.bashrc`, source that file instead.

## Configure Codex to use Ace Data Cloud

Codex reads its global settings from:

```text
~/.codex/config.toml
```

Create the file if it does not exist:

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

Then add the provider 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"
```

The important fields are straightforward:

- `model_provider` selects the provider block Codex should use by default.
- `model` sets the default model ID, here `gpt-5`.
- `model_reasoning_effort` can use common values such as `low`, `medium`, or `high`.
- `base_url` points Codex at Ace Data Cloud's OpenAI-compatible API base.
- `env_key` tells Codex which environment variable contains the token.
- `wire_api = "responses"` tells Codex to use the Responses API protocol.

This is the part I like about the setup: the change is explicit and reversible. Your project does not need a wrapper script, and your token stays in your shell environment instead of being copied into every repository.

## Clear old login state if needed

If you previously logged into Codex CLI with an official OpenAI account, your machine may have cached that login under `~/.codex/auth.json`. Before switching providers, clear it:

```bash
codex logout
```

If that command is unavailable, the documented fallback is:

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

If you have never logged into Codex before, you can skip this step.

## Start a terminal session

Move into a project and start Codex:

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

A simple first prompt is often better than a huge instruction. For example:

```text
Explain the directory structure of this project
```

Once the session starts, check the active model and provider:

```text
/model
```

A working setup should show something like:

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

If the provider is not `acedatacloud`, recheck two things first: whether `~/.codex/config.toml` was saved correctly, and whether `ACEDATACLOUD_API_KEY` is visible in the same terminal session where you run `codex`.

## Use trust levels intentionally

Codex can read files, execute commands, and make edits, so trust settings matter. For a repository you know well, you can mark a path as trusted:

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

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

I would keep unfamiliar repositories untrusted until you understand what commands the agent may run and what files it may touch. This is less exciting than model selection, but it is the kind of detail that prevents a helpful tool from becoming a risky one.

## A practical way to think about the workflow

The request path is simple: Codex reads `~/.codex/config.toml`, loads the `acedatacloud` provider, reads `ACEDATACLOUD_API_KEY`, and sends traffic through the Responses API. Ace Data Cloud verifies the token, routes the model request, and records usage.

For me, the value of this setup is not that it changes how Codex feels. It is that it does not. You still type `codex`, stay inside your terminal, and keep the same builder workflow while making the provider layer explicit.

If you want the original reference while setting it up, keep the Ace Data Cloud Codex CLI terminal guide open: https://platform.acedata.cloud/documents/codex-terminal-integration