“想在 Windows 上使用 Codex，最容易出问题的并不是安装，而是误装同名应用、把代码和密钥交给不明第三方接口。先核验来源，再决定是否配置第三方 API。”

许多人安装 Codex 时，第一反应是搜索、下载、填密钥。但真正容易造成麻烦的，往往是前两步：应用是不是官方来源？第三方接口值不值得接入？⚠️

一、先把“官方安装”和“第三方接口”分开看

Codex 客户端的安装来源，与后续是否接入第三方 API，是两件不同的事。即使客户端来自微软商店，后续把请求转给第三方服务后，数据传输的风险仍要由使用者自己判断。

因此，安装阶段的目标很简单：核验应用信息；配置阶段的目标也很简单：确认接口兼容性，并避免提交敏感内容。

二、从微软商店安装时，重点核对什么

打开 Microsoft Store 搜索“Codex”后，不要只看名称或图标。同名、近似名称的软件可能存在，提议重点核对开发商是否显示为 OpenAI，以及应用页面展示的信息是否与预期一致。

原文提供的应用 ID 为 9PLM9XGG6VKS。若你使用终端安装，可在管理员终端中执行以下命令：

winget install –id 9PLM9XGG6VKS -s msstore

安装完成后，如果后面还要修改客户端配置，提议先彻底退出 Codex，避免运行中的程序覆盖刚刚写入的配置文件。

遇到商店无法搜索、页面空白等情况，先检查系统时间是否自动同步、微软商店服务是否正常，再思考清理商店缓存。不要由于安装受阻，就随意从不明下载站寻找安装包。

三、决定接入第三方 API 前，先接受这条边界

第三方 API 中转服务并不受 OpenAI 监管。请求经过第三方服务器时，代码、提示词和附件都可能暴露在该服务的处理链路中。

所以，这类方案最多适合个人学习和测试。企业源码、客户资料、访问令牌、私钥、数据库连接信息等内容，不应提交给不明第三方接口。

如果你仍决定使用第三方服务，至少先确认自己已拿到三项信息：Base URL、API Key，以及服务商明确支持的模型名称。缺少其中任何一项，都不适合直接开始配置。

四、手动配置时，最常见的失败点

原文给出的思路是：在 Windows 用户目录下找到或新建 .codex 文件夹，再创建 config.toml 文件。配置中一般需要指定模型、服务商名称、接口地址、环境变量名和接口类型。

其中有四个细节最容易出错：

1. Base URL 是否按服务商要求填写。原文示例要求地址以 /v1 结尾，遗漏这一部分可能导致连接失败。
2. model_provider 的名称，必须与后续配置段落中的名称完全一致。
3. API Key 不提议直接写进配置文件，可通过系统环境变量保存，再让配置引用变量名。
4. 模型名称必须是服务商实际支持的名称；名称写错时，一般会出现找不到模型或请求失败的提示。

原文使用的接口类型为 responses，并将 requires_openai_auth 设为 false。这属于第三方兼容方案中的配置选择，是否可用仍取决于客户端版本和服务端是否兼容。️

五、为什么提议把密钥放进环境变量

把 API Key 直接写在配置文件里，看起来省事，但也更容易在截图、备份、同步文件或误发文件时泄露。

在 Windows 中，可通过 Win+R 输入 sysdm.cpl，进入“高级”—“环境变量”，在用户变量中新增密钥变量。配置文件只保留变量名，不直接暴露真实密钥。

完成修改后，需要让 Codex 完全退出再重新启动；必要时重启电脑，确保环境变量已被新进程读取。

六、报错时别急着反复改配置

401 Unauthorized，优先检查密钥是否复制完整、是否带有空格，以及服务商侧的余额或权限状态。

503 Service Unavailable，一般更接近服务端故障或上游限流，不必定是本地配置写错。

一直转圈或没有响应，先确认接口地址，再检查网络环境、防火墙权限，以及客户端是否已经彻底重启。

修改后没有生效，也别只关闭窗口。应退出托盘中的 Codex，并确认相关进程已结束后再启动。

七、最后的取舍：能连上，不等于适合长期使用

第三方接口可能让测试更灵活，但也可能存在功能兼容性、稳定性和数据安全问题。尤其是新功能，不必定能通过兼容接口正常工作。

对新手来说，最稳妥的顺序是：先确认安装来源，再用非敏感的测试项目验证功能，最后才决定是否保留第三方配置。把安全边界想清楚，比“成功连上一次”更重大。