Codex CLI 配置能直接搬到 Trae 和 VS Code 吗？我把配置项逐个拆开验证

我已经在 Codex CLI 里配置过模型服务，接下来想把同一套信息迁移到 Trae 和 VS Code。真正容易出错的地方，不是“复制几行配置”，而是没有分清请求地址、模型 ID、API 协议、Key 和客户端自己的设置。

这次我把配置拆成字段逐项验证：Trae CN 成功保存了自定义模型，并发送“你好”得到回复；VS Code 侧确认了扩展、CLI 入口和配置文件存在性，但远程配置脚本读取返回 Authentication failed，所以没有把 VS Code 模型对话写成成功结果。

先给结论：能复用什么，不能复用什么

可以迁移的是模型服务的连接信息：

• base_url：请求发往哪里；
• model：服务端识别的模型 ID；
• API 协议：例如 OpenAI Chat Completions 格式；
• API Key 对应的认证方式。

不能直接复制的是客户端专属设置：

• Codex CLI 的权限和沙箱选项；
• .codex 目录下的全部文件；
• Trae 或 VS Code 的展示名称、插件设置和上下文选项；
• 某个客户端自己的工具调用或快捷键配置。

所以迁移的正确方式是“读字段、填对应字段、做最小请求”，不是把整个配置目录搬过去。

一、先只读取 Codex CLI 需要的字段

本机实际使用 codex-cli 0.148.0。配置文件通常位于：

%USERPROFILE%\\.codex\\config.toml

我只查看 base_url 和 model，本次得到的示例值是：

model = "gpt-5.6-luna"

[model_providers.custom]
base_url = "https://llapi.org/v1"

图 1：只提取请求地址和模型 ID，不打印完整配置文件。

认证文件通常位于：

%USERPROFILE%\\.codex\\auth.json

我只确认 OPENAI_API_KEY 字段存在，实际 Key 使用占位符表示：

{
  "OPENAI_API_KEY": "<YOUR_LLAPI_API_KEY>"
}

不要把 auth.json 全文复制进文章、聊天记录或 Git。尤其不要为了确认 Key 是否正确，直接把它打印到终端。

二、先理解地址、模型 ID 和完整 URL

这三个概念经常被混在一起：

• https://llapi.org/v1 是请求地址；
• gpt-5.6-luna 是模型 ID；
• /chat/completions 是某种 API 格式下的请求路径。

如果客户端的“完整 URL”开关会自动追加 /chat/completions，自定义请求地址就填写到 /v1；如果客户端要求完整地址，则应按它的字段说明填写。不要看到 404 后盲目重复拼接 /v1 或 /chat/completions。

模型展示名称也不等于模型 ID。展示名称可以写成“我的模型”，但请求发给服务端的仍应是配置中真实存在的模型 ID。出现 model not found 时，先核对这个字段。

三、迁移到 Trae：这次验证成功

我在 Trae CN 的“设置 -> 模型 -> 模型管理 -> 添加模型”中选择自定义模型，逐项填写：

Codex CLI 字段	Trae 字段	本次填写
API 协议	API 格式	OpenAI Chat Completions 格式
base_url	自定义请求地址	https://llapi.org/v1
model	模型 ID	gpt-5.6-luna
OPENAI_API_KEY 的值	API 密钥	真实 Key，仅在本机输入

保存时 Trae 提示测试通过，模型出现在自定义模型列表中。随后我在编辑器中选择该模型，发送最小消息：

你好

实际返回：

你好，有什么需要我帮你处理？

图 2：Trae 保存模型并完成最小对话测试的真实结果整理。Key 只显示为隐藏字符。

这个结果只能证明本次地址、模型 ID、协议和 Key 组合完成了连通性验证，不代表所有模型、长文本或工具调用都一定可用。

四、迁移到 VS Code：先把链路拆开

VS Code 里的扩展、Codex CLI、本地配置和模型请求不是同一个环节。我先确认扩展商店中显示的是 OpenAI 发布的：

Codex – OpenAI's coding agent

本机检查结果：

VS Code 1.133.0
codex-cli 0.148.0
config.toml: exists
auth.json: exists

命令入口还需要单独确认：

Get-Command codex -ErrorAction SilentlyContinue
where.exe codex
codex --version

如果 PowerShell 能找到 Codex，而 VS Code 找不到，可能是 VS Code 启动时没有读取最新 PATH。完全退出后重新启动，比在扩展面板里反复点击更容易定位。

图 3：VS Code 扩展、Codex CLI 版本、命令入口和配置文件存在性检查。截图不显示认证内容。

五、远程配置脚本不能直接当成成功路径

之前常见的一键命令是：

irm https://llapi.org/api-public/setup.ps1 | iex

这里的 irm 会读取远程内容，iex 会立即执行。涉及下载、安装和写入配置时，我先保存脚本再查看：

$uri = 'https://llapi.org/api-public/setup.ps1'
$script = Invoke-RestMethod -Uri $uri
$script | Set-Content -LiteralPath '.\\setup-llapi.ps1' -Encoding UTF8
Get-Content -LiteralPath '.\\setup-llapi.ps1'

本轮实际读取远程脚本返回：

Authentication failed, see inner exception.

因此我没有执行 irm ... | iex，也没有在 VS Code 中输入真实 Key 或发送模型请求。这个结果只能说明当前读取链路失败，不能被解释为 VS Code 配置成功或服务不可用。

图 4：远程脚本读取的真实失败结果。未执行脚本，未把失败伪装成配置成功。

六、迁移失败时按错误类型排查

401 或 403

检查 Key 是否复制完整、是否过期，以及服务方是否允许当前模型。不要把错误响应中的 Authorization 头发到聊天群或文章里。

404

检查 Base URL 是否重复拼接 /v1，以及客户端是否自动追加 /chat/completions。地址和模型 ID 都要单独核对。

model not found

检查填写的是模型 ID，而不是客户端里自定义的展示名称。模型列表和官网当前支持范围也可能发生变化，应以当时页面为准。

能保存，但不能对话

保存成功通常只完成了一次连通性检查，不等于每种请求都成功。重新核对 API 格式、请求地址、模型 ID 和请求类型。

connection refused 或脚本读取失败

检查网络、代理、证书和 PowerShell 请求环境。在错误原因不清楚时，不要改用来源不明的镜像脚本，也不要直接授予管理员权限。

七、我最后保留的迁移清单

[ ] 只读取 base_url、model 和必要的认证字段
[ ] 没有复制完整 auth.json 或 .codex 目录
[ ] Base URL 没有重复拼接 /v1
[ ] 模型 ID 与展示名称分开填写
[ ] Trae 保存成功后又做了最小对话测试
[ ] VS Code 的扩展、CLI、配置、认证和网络分别检查
[ ] 远程脚本先保存、查看，再决定是否执行
[ ] Key、Authorization、Cookie 没有进入截图、日志或 Git