This guide explains how to connect Codex CLI to the DeepSeek API seamlessly on Windows. The core approach combines hosts redirection, a Caddy HTTPS reverse proxy, and a LiteLLM OpenAI-compatible proxy. It solves the integration pain point caused by Codex targeting only OpenAI endpoints and enables model replacement with minimal configuration changes. Keywords: Codex, DeepSeek, LiteLLM.
This setup forwards Codex OpenAI requests to DeepSeek through a transparent proxy.
| Parameter | Description |
|---|---|
| Runtime environment | Windows 10/11 |
| Language/Tools | Python 3.10+, PowerShell |
| Protocol path | HTTPS → HTTP → OpenAI-Compatible API |
| Proxy components | Caddy, LiteLLM |
| Target models | deepseek-chat / deepseek-reasoner |
| Original article popularity | 67 views |
| Article tags | codex, deepseek, proxy, reverse proxy |
| Core dependencies | litellm[proxy], caddy.exe |
The key value of this architecture is that Codex configuration appears unchanged.
The original request flow can be summarized as follows: requests sent by Codex CLI to api.openai.com are redirected by the local hosts file to 127.0.0.1, then handled by Caddy for TLS termination, forwarded to LiteLLM, and finally sent by LiteLLM to the DeepSeek API.
Codex CLI → hosts resolves to 127.0.0.1 → Caddy :443 → LiteLLM :4446 → DeepSeek APIThis chain effectively disguises an OpenAI-style request as a local compatibility proxy call, which bypasses Codex’s explicit limitation on target vendors.
Environment preparation determines whether the full request chain works on the first attempt.
Before you begin, prepare Windows 10/11, Python 3.10+, pip, a DeepSeek API key, and an installed Codex CLI. If any of these is missing, the proxy chain will fail.
Install the LiteLLM proxy layer.
pip install "litellm[proxy]"This step installs the OpenAI-compatible proxy service. All subsequent model mapping is handled by LiteLLM.
Install Caddy to handle the HTTPS entry point.
After downloading the Windows version of Caddy, rename it to caddy.exe and move it into a system path so you can call it globally.
move C:\Users\你的用户名\Downloads\caddy.exe C:\Windows\System32\caddy.exe
caddy version # Confirm that Caddy is correctly available in the system PATHThese commands install Caddy and verify that the executable is available.
Hosts redirection is the key step that makes Codex think it is still talking to OpenAI.
Edit C:\Windows\System32\drivers\etc\hosts as an administrator, and add the following line at the end to point api.openai.com to the local loopback address.
127.0.0.1 api.openai.comAfter saving the file, use the following command to verify name resolution.
ping api.openai.com # If the result returns 127.0.0.1, the domain is now controlled by the local machineThis step ensures that requests sent by Codex never leave the machine and instead enter the local proxy chain.
Caddy provides HTTPS support and reverse proxies traffic to LiteLLM.
Create a Caddyfile on your desktop without a .txt extension. The configuration is minimal, but critical: it listens on api.openai.com:443 and forwards traffic to local port 4446.
api.openai.com:443 {
tls internal
reverse_proxy 127.0.0.1:4446
}This configuration allows HTTPS requests from Codex to be terminated by a local certificate and then passed to LiteLLM, which serves only HTTP.
Codex only needs what looks like a normal OpenAI-style configuration.
Edit C:\Users\你的用户名\.codex\config.toml. The key detail is to preserve OpenAI-style model naming and not write a DeepSeek model name directly.
model = "gpt-4.1"
model_provider = "local-relay"
[model_providers.local-relay]
name = "Local Relay"
api_base_url = "http://127.0.0.1:4446/v1"
env_key = "OPENAI_API_KEY"
[projects.'C:\Users\你的用户名\Desktop']
trust_level = "trusted"
[windows]
sandbox = "unelevated" # Avoid Windows sandbox permission issues that can block executionThe core purpose of this configuration is to keep Codex operating in an OpenAI-oriented mode while routing the actual requests into the local relay layer.
The full setup works reliably only when you start services in the correct order.
Start LiteLLM first as the model egress.
$env:DEEPSEEK_API_KEY="你的DeepSeek API Key"
litellm --model deepseek/deepseek-chat --port 4446 --host 0.0.0.0 # Map DeepSeek Chat to an OpenAI-compatible interfaceThis command exposes an OpenAI-compatible API service locally on port 4446.
Start Caddy next to take over the 443 entry point.
cd C:\Users\你的用户名\Desktop
caddy run # Read the Caddyfile in the current directory and handle local HTTPS requests for api.openai.comYou must run this step as an administrator. Otherwise, port 443 binding or certificate-related operations may fail.
Start Codex last and validate the full request chain.
codex # After startup, send any prompt to verify that replies are returned normallyIf Codex returns responses successfully, the transparent proxy chain is working.
In daily use, you only need to remember that all three processes are required.
Before each use, start LiteLLM, Caddy, and Codex in that order. These three components handle model forwarding, HTTPS termination, and the local client entry point respectively. If any one of them exits, the chain breaks.
You can switch models quickly without changing Codex configuration.
As long as you stop LiteLLM and restart it with different parameters, you can switch the actual target model from deepseek-chat to deepseek-reasoner, or even to other OpenAI-compatible models.
litellm --model deepseek/deepseek-chat --port 4446 --host 0.0.0.0
litellm --model deepseek/deepseek-reasoner --port 4446 --host 0.0.0.0 # Switch to the R1 reasoning modelThis shows that model selection is effectively controlled at the LiteLLM layer, not the Codex layer.
Troubleshooting is easiest when you check protocol behavior and port usage first.
If you see Invalid HTTP request received, Caddy is usually not running, which means Codex is trying to access LiteLLM directly over HTTPS even though LiteLLM supports only HTTP. If ping api.openai.com does not return 127.0.0.1, the hosts redirection is not working. If Caddy reports a permissions error, it is usually because it was not started as an administrator.
Also, if the response style does not look like DeepSeek, inspect the LiteLLM logs and DeepSeek usage dashboard directly to confirm that requests are actually reaching the intended model.
Uninstalling and rolling back is straightforward.
Remove 127.0.0.1 api.openai.com from your hosts file, stop LiteLLM and Caddy, then uninstall LiteLLM or delete caddy.exe to restore the original state.
pip uninstall litellm # Remove the local proxy layer and restore the Python environmentBecause this solution is fundamentally based on local network redirection, rollback cost is very low. It is well suited for experimental integrations and rapid validation.
The structured FAQ summarizes the three questions developers care about most.
FAQ 1: Why does Codex use gpt-4.1, but actually call DeepSeek?
Because Codex uses an OpenAI-style model name only at the request layer. The real target model is determined by the LiteLLM parameter --model deepseek/deepseek-chat. In other words, the model name is the compatibility surface, while the routing rule defines actual execution.
FAQ 2: Why is Caddy required? Can LiteLLM be used directly with Codex?
Usually not. Codex sends requests to the HTTPS endpoint for api.openai.com, while LiteLLM exposes an HTTP service by default. Caddy terminates TLS and reverse proxies the HTTPS traffic to LiteLLM.
FAQ 3: What are the most common failure points in this setup?
The three most common issues are: an incorrect hosts entry, Caddy not running as administrator, and the wrong model parameter when starting LiteLLM. During troubleshooting, check DNS resolution, whether port 443 is listening, and the LiteLLM console logs first.
Core summary
This guide reconstructs the full Codex-to-DeepSeek integration path: by combining hosts redirection, a Caddy HTTPS reverse proxy, and a LiteLLM OpenAI-compatible proxy, Codex can continue using OpenAI model names while actually calling DeepSeek. This makes the setup practical for fast deployment on Windows.