Hello everyone, I'm Cang He.
After CodexGuide went online the day before yesterday, the backend exploded.

The most frequently asked question is: How to use Codex in China? Can I use it without a Plus subscription?
To be honest, I understand this pain.
Subscribing to Plus has its own barriers, and you have to figure out payment methods; it's exhausting.
So I spent two days testing every solution I could find online, hit many pitfalls, and finally summarized the three most reliable access methods.
I'm sharing them all with you today—just follow the steps.
The tutorial is also live on CodexGuide for reference at any time.

Considering how hard I worked on this, give it a star, hahaha.

First, a prerequisite: the most stable way to use Codex is still logging in with an official GPT account.
Connecting to a third-party API is an advanced operation; you need to know what config.toml, API Key, and Base URL are.
If you don't know, it's okay—just follow the steps below.
How to Choose Between the Three Schemes
Here is a table for you to find your fit:
Scheme | Suitable for | Advantages | Note |
|---|---|---|---|
Manual Configuration | Those who want to understand the underlying principles | Transparent, controllable, easy to troubleshoot | Must maintain |
Codex++ | Desktop App users who want GUI management | Has a management interface, one-click configuration | Third-party tool, may need updates after Codex updates |
CCX + CC Switch | Those with multiple providers needing protocol conversion | Gateway routing + one-click provider switching | Many components, requires understanding ports and proxy chains |
Honestly, if you are a beginner, just look at Scheme 2; it's the most worry-free.
If you are just starting to learn Codex, I suggest looking at my previous Codex beginner tutorial before messing with third-party APIs.
Scheme 1: Manual Configuration
This method has a disadvantage: you cannot use the plugin function of the Codex APP.
If you want to use plugins, skip directly to Scheme 2.

The core of manual configuration is modifying one file:
Before modifying, back it up—develop good habits:

Two Login Approaches
Approach | How to understand it | Suitable scenario |
|---|---|---|
GPT Login | Keep official login status, only change request forwarding address | Want to keep official account capabilities while using a relay |
API Key Login | Use the Key in environment variables, request third-party directly | Use OpenAI API Key or self-built compatible service |
A suggestion: don't change too many things at once. Add only one provider first, and once it works, then mess with multiple configurations.

GPT Login Status Example
This means your Codex must first be logged into a GPT account.
Step 1: Modify the configuration file:
Open ~/.codex/config.toml and add the following configuration.
Note: fill in the fields and values according to your actual service:
A few common pitfalls:
model_providermust be exactly the same asxxxin[model_providers.xxx]; not even one letter off.base_urlshould only go up to/v1; do not include the entire/v1/responsessegment.wire_api = "responses"means requesting in the Responses API format; do not change it.requires_openai_auth = falsemeans not using the official login status.

Step 2: Set environment variables
Open the terminal and enter:

Step 3: Start Codex APP from the terminal
There's a catch here: Mac users must start from the terminal; clicking the icon directly might not read the model.
Completely close the Codex APP before starting, then enter in the terminal:
Step 4: Verify the effect
Open the Codex APP, and you will see that the model has been successfully switched:

Good heavens, it's taking off.
API Key Login Example
If you are using the API Key method, remember one principle: put the secret key in environment variables, don't hardcode it in the configuration file.
Corresponding config.toml configuration:
One thing to note: if your upstream only supports Chat Completions and not Responses API, just changing the configuration won't work; you need to use a gateway like CCX for protocol conversion, which will be discussed in Scheme 3.
Modify the authentication file
Open ~/.codex/auth.json and change OPENAI_API_KEY to your model provider's Key:

How to Verify Configuration Success
Don't rush after configuring; verify first:
- Completely exit Codex and reopen it.
- Have it perform a read-only task, such as summarizing the current directory structure.
- If it errors, first check the
model_providername,base_url, and environment variables. - If an authentication error occurs, switch back to the backup configuration first; don't panic.
Scheme 2: Codex++
If you find manual configuration too troublesome, check out Codex++.
It is a graphical management tool that helps you handle relay configurations with one click, without having to write toml files manually.
Moreover, it supports plugin functions, which Scheme 1 cannot do.

Suitable for these people:
- Those who mainly use the Codex desktop App.
- Those who don't want to write configuration files manually.
- Those who want to switch back to official mode at any time.
Installation Steps
- Open Codex++ Releases and download the installation package.

You will see two installation packages: "Codex++ Management Tool" and "Codex++ app"; install both.

- Open the "Codex++ Management Tool" after installation.
If this error pops up the first time you open it, don't panic:

Go to "System Settings" - "Privacy & Security", and click "Open Anyway":

After opening, enter the management interface:

Install the Codex++ app in the same way; it's correct if the management tool detection is all green:

Confirm that the GPT login status is detected.
- Add relay configuration.
Select "Provider Configuration" - Add Provider, and fill in your Base URL and Key.
Note: select "Pure API" for the access method:

The model list can be automatically obtained from upstream; if you are configuring a relay station, there will be many models to choose from here:

Essentially, this tool helps you write configurations more conveniently, saving you from manual file editing:

Test the connectivity after saving; if there are no issues, use it directly:

- Start Codex from the Codex++ entry point.
Note: start from Codex++, not the original Codex:

After restarting, you will see that Codex is already using the custom model provider, and the number of optional models has suddenly increased:

Plugins can also be used directly; this is the complete experience:

You have to admit, this scheme is the smoothest I've used so far; highly recommended.
What if I want to roll back?
- Clear the API mode in the management tool and switch back to the official configuration.
- If Codex++ stops working after a Codex update, just wait for it to be adapted; it won't affect the use of the original version.
Scheme 3: CCX + CC Switch
This scheme is suitable for power users, separating the "gateway" and the "switching tool":
- CCX: API proxy gateway, responsible for protocol conversion and routing. Supports various entry points like Claude, OpenAI, Codex, Gemini, etc.
- CC Switch: Desktop management tool, one-click switching of different provider configurations.

When to use this scheme? When you have multiple domestic model APIs, multiple relay services, multiple Keys, or when the upstream only supports Chat Completions and needs conversion to Responses API.
Step 1: Deploy CCX
Use Docker with a single command:
After starting, you can see it by opening the browser.
Step 2: Add Upstream Channels
Add your channels in the CCX management interface:
- Select the upstream service type.
- Fill in the API Key and Base URL.
- Configure model mapping and routing rules.
- Use the built-in test function to confirm connectivity.
There is a key point here: Codex needs a Responses API entry point. If the upstream only has Chat Completions, CCX will help you perform protocol conversion, which is the core reason for using it.
Step 3: Install CC Switch
Command line installation:
Initialization:
During initialization, fill in the CCX address as the relay entry point.
Step 4: Switch Configuration and Start
One-line command to switch providers:
Then restart Codex for it to take effect.
After switching, it is recommended to open ~/.codex/config.toml to verify:
- Is
model_providerwhat you just selected? - Does
base_urlpoint to CCX? - Did you accidentally write the Key into a public repository (this is very important)?
Summary of Common Pitfalls
Finally, here is a troubleshooting table; check it first if you encounter problems:
Phenomenon | Check what first |
|---|---|
Not effective after switching | Whether Codex was completely restarted, whether |
Authentication error | Whether API Key is valid, whether environment variables are inherited by the current shell |
Interface path error | Whether |
Domestic model no response | Whether upstream supports Responses API; if not, you must use CCX for conversion |
Plugin configuration missing | Whether the switching tool overwrote the configuration; did you back up in advance? |
To be honest, I've successfully run all three schemes, but I use Scheme 2, Codex++, the most for daily use; it's worry-free.
If you are the kind of power user with several Keys and several providers, Scheme 3 is more suitable for you.
Alright, that's all for today's share.
If this tutorial helped you, give it a like to let me know, and I will continue to update more Codex practical gameplay in the future.
If you have questions, ask directly in the comments section; I will reply to all I see.





