发布日期：2026-09-16｜适用系统：macOS、Windows、Linux｜资料来源：OpenAI 官方文档与项目仓库

Codex Desktop 是 OpenAI 在 ChatGPT 桌面应用中提供的软件开发工作区，可读取本地项目、修改文件、运行命令并管理并行任务。本文覆盖下载安装、官方登录与 API Key、自定义模型提供方、CC Switch、Codex++、插件和 Skills，并区分官方功能与第三方增强工具。初次使用建议先完成官方配置，再按需要添加社区工具；任何第三方 API、安装包或脚本都应独立核验来源、计费、密钥存储和数据处理规则。

Codex Desktop 是什么？

Codex Desktop 是面向真实项目的 AI 工作区，适合代码理解、功能开发、故障修复、代码审查以及需要本地文件和终端的长任务。

它与 Codex CLI、IDE 扩展并非完全独立的产品：三者可以读取同一套用户级 ~/.codex/config.toml，但界面能力和可用功能会受客户端、登录方式、账户方案与灰度发布影响。

一、下载安装 Codex Desktop

OpenAI 官方文档在 2026 年列出 macOS、Windows 和 Linux 3 类桌面系统。最稳妥的安装来源是 ChatGPT 官方下载页，Linux 用户再按官方发行版指南操作。

安装步骤

  1. 打开官方下载安装页，选择与系统和 CPU 架构匹配的版本。

  2. 安装并启动 ChatGPT 桌面应用，使用 ChatGPT 账号登录。

  3. 在产品入口中选择 Codex，再打开一个本地文件夹或已保存项目。

  4. 首次打开仓库时确认信任范围；项目级 .codex/ 配置只会在受信任项目中加载。

  5. 用一个低风险任务验证读取、修改、终端和审批流程，例如“解释项目结构，不修改文件”。

如使用 API Key 登录，部分桌面功能可能不可用。团队账号还可能受到管理员设定的模型、插件、网络及权限策略约束。

二、第一次使用应完成哪些设置？

首次配置的重点不是“放开全部权限”，而是确定工作目录、模型、推理强度和审批边界。

设置

建议起点

原因

工作目录

单个项目目录

减少无关文件暴露

模型

账户默认推荐模型

避免固定到即将退役的版本

推理强度

默认或 Medium

在速度与任务质量间平衡

沙箱

workspace-write

允许项目写入，同时限制系统范围

审批

on-request

高风险动作执行前暂停确认

网络搜索

cached

降低实时网页提示注入风险

Codex 官方配置共有 7 层优先级：命令行、项目配置、Profile、用户配置、云端托管默认值、系统配置和内置默认值，越靠前优先级越高。来源：OpenAI 配置文档，2026

一个保守的用户级配置如下：

# ~/.codex/config.toml
approval_policy = "on-request"
sandbox_mode = "workspace-write"
web_search = "cached"
model_reasoning_effort = "medium"

不要把 API Key 直接写进可提交到 Git 的项目配置。密钥应放在工具支持的系统钥匙串、受保护的凭据存储或环境变量中。

三、Codex Desktop 如何接入模型？

方案 A：使用 ChatGPT 官方登录

官方登录是功能兼容性最完整的路径。登录后可在输入框下方选择账户可用模型和推理强度；实际列表取决于方案、发布范围与管理员策略。

方案 B：使用 OpenAI API Key

API Key 适合需要 API 账单或独立认证的用户，但它与 ChatGPT 订阅额度不是同一计费体系。不要假设订阅权益会自动抵扣 API 用量。

方案 C：配置兼容提供方

OpenAI 官方文档说明，Codex 可指向支持 Responses API 或 Chat Completions API 的模型与提供方；其中 Chat Completions 支持已经标记为弃用，后续应优先选择 Responses API。

自定义提供方属于高级配置，应先确认服务端确实兼容所选协议，再在用户级 config.toml 中声明。字段以当前官方配置参考为准，不应照抄来源不明的配置片段。

# 示例结构；请将名称、URL、模型 ID 与环境变量名替换为服务方正式文档中的值
model = "YOUR_MODEL_ID"
model_provider = "custom_provider"

[model_providers.custom_provider]
name = "Custom Provider"
base_url = "https://YOUR_PROVIDER_HOST/v1"
env_key = "YOUR_PROVIDER_API_KEY"
wire_api = "responses"

配置后先用脱敏的小任务测试文本输出、工具调用、流式返回、错误码和上下文长度。协议“能请求成功”不等于完整兼容 Codex 的工具链。

在兼容 Responses API 的前提下，多款主流大模型服务也可作为候选；例如七牛云 AI 提供标准化接口，但具体模型可用性、上下文、工具调用和数据条款应以控制台与最新文档为准。

四、如何用 CC Switch 管理第三方模型？

CC Switch 是社区维护的跨平台配置管理工具，不是 OpenAI 官方组件。它可管理 Codex、Claude Code 等多个客户端的 Provider、MCP、Skills 和提示词配置。

截至 2026-09-16，farion1231/cc-switch GitHub 仓库约有 13.3 万 Star，并提供 Windows、macOS、Linux 构建。来源：CC Switch GitHub，2026

推荐配置流程

  1. 只从项目声明的官网或 GitHub Releases 下载，并核对仓库、版本与签名信息。

  2. 安装后进入 Codex Provider 管理，新增自定义服务方。

  3. 按服务方文档填写 Base URL、API Key、协议和模型 ID。

  4. 先执行连通性测试，再切换为当前 Codex 配置。

  5. 重启 Codex Desktop，用无敏感数据的小任务验证工具调用。

  6. 如需回退，切回官方 Provider，并检查 ~/.codex/config.toml 与认证状态。

CC Switch 的核心价值是可视化编辑和切换配置，并不替第三方服务背书。不要因仓库中的赞助商列表或促销内容，跳过对供应商身份、隐私政策和账单规则的核验。

五、如何使用 Codex++？

Codex++ 是面向官方桌面应用的社区增强启动器。它通过 Chromium DevTools Protocol 与本地辅助服务加载供应商管理、会话管理和界面增强，不属于 OpenAI 官方插件体系。

截至 2026-09-16，BigPizzaV3/CodexPlusPlus GitHub 仓库约有 3.1 万 Star，并提供 Windows、macOS Intel 与 Apple Silicon 安装包。来源：Codex++ GitHub，2026

基本使用顺序

  1. 从项目 GitHub Releases 下载匹配系统架构的安装包。

  2. 先打开“Codex++ 管理工具”，确认官方应用路径与运行状态。

  3. 选择官方登录、纯 API 或其他项目支持的供应商模式。

  4. 填写协议、Base URL、模型 ID 与凭据，运行 Provider Doctor 或模型测试。

  5. 从 Codex++ 入口启动官方桌面应用，而不是直接打开原应用。

  6. 官方应用升级后若界面异常，先关闭注入类增强，再等待项目适配。

维度

CC Switch

Codex++

定位

多 AI 客户端配置管理器

Codex Desktop 外部增强启动器

是否官方

否

否

主要能力

Provider、MCP、Skills、提示词切换

Provider、会话与界面增强、脚本

对官方界面依赖

较低

较高，注入功能需适配界面变化

更适合

同时管理多个 AI 编程工具

需要增强 Desktop 管理能力的用户

主要风险

配置与密钥管理、第三方来源

注入兼容性、本地数据与安装包信任

不要同时让多个工具反复改写同一份配置。切换前备份 ~/.codex/config.toml，并记录当前 Provider 与认证方式。

官方配置与第三方工具边界图

六、插件和 Skills 有什么区别？

Skill 是针对单一重复任务的说明书与资源包；插件是可安装的能力集合，可以同时包含 Skills、MCP 服务和生命周期 Hooks。

能力

Skill

插件

主要用途

固化写作、审查、发布等工作流

分发一组工作流并连接外部工具

核心内容

SKILL.md、模板、脚本、参考资料

清单、Skills、MCP、Hooks、可选 UI

调用方式

Codex 中使用 $技能名，也可自动匹配

安装后直接描述任务或选择其能力

适用范围

个人或团队流程标准化

稳定能力的安装、共享和治理

一个最小 Skill

code-review/
└── SKILL.md
---
name: code-review
description: Review changes for correctness, security, regressions, and missing tests.
---

Inspect the diff. Report findings by severity with file and line references.
Prioritize behavioral bugs and security risks over style preferences.

Skill 的描述决定系统何时匹配它。应聚焦一个明确任务，并写清输入、步骤、输出和禁止事项；只有确实需要时才加入脚本和参考资料。

插件适合什么情况？

当你需要把多个 Skills 打包、连接 GitHub 或内部系统、添加 MCP 工具，或者分发给团队时再使用插件。官方提供 $plugin-creator 用于生成兼容清单和目录结构。

七、推荐的安全与排错顺序

最有效的排错方法是逐层恢复到官方最小配置，而不是同时更换模型、插件和权限。

  1. 备份 config.toml，暂时停用 CC Switch、Codex++ 与自定义脚本。

  2. 使用官方登录和推荐模型测试一个只读任务。

  3. 检查项目是否受信任，以及项目级 .codex/config.toml 是否覆盖用户配置。

  4. 逐项恢复自定义 Provider、MCP、Skill 和插件，每次只加一项。

  5. 查看错误是认证、协议、模型 ID、限流、网络还是工具调用不兼容。

  6. 向社区项目反馈时删除 API Key、请求正文、用户名和本地路径。

常见问题

Codex Desktop 和 Codex CLI 应该选哪个？

Desktop 适合可视化管理多个任务、文件与输出；CLI 适合终端工作流、脚本和 CI。两者可以共享用户级配置，因此可以按任务切换，不必二选一。

CC Switch 和 Codex++ 是官方工具吗？

不是。两者都是独立社区项目。CC Switch 偏重多客户端配置管理，Codex++ 偏重桌面应用启动与界面增强；使用前应核验发布来源并备份配置。

为什么第三方模型能对话，却不能正常修改代码？

常见原因是 Responses API、流式事件、工具调用或结构化输出只实现了部分兼容。应先用服务方声明支持的协议测试，再逐项验证 shell、补丁与长上下文。

插件和 MCP 是一回事吗？

不是。MCP 是向模型暴露工具与上下文的协议；插件是安装与分发单元，可以包含 MCP 服务，也可以只包含 Skills 或 Hooks。

安装很多 Skills 会让 Codex 更强吗？

不一定。描述重叠的 Skills 可能造成误触发和上下文浪费。更好的做法是每个 Skill 只解决一个重复任务，使用真实案例测试触发和输出质量。

结论

Codex Desktop 的稳妥使用顺序是：官方安装与登录、最小权限配置、项目验证，再添加自定义 Provider、Skills 和插件。CC Switch 与 Codex++ 能降低第三方配置和管理成本，但它们不改变供应商兼容性、数据安全和计费责任。

本文依据 OpenAI 官方文档及两个社区项目截至 2026-09-16 的公开信息整理。客户端、模型、配置字段与第三方工具更新较快，实际操作前应重新核对官方文档和对应 Release。

codex接入任意模型教程：https://news.qiniu.com/archives/1789008380592

参考资料