CC Switch + Claude Code CLI + Codex CLI：一套本地实战配置，少走很多弯路

最近一段时间，我本地开发环境里最常用的三样东西，就是 Claude Code CLI、Codex CLI 和 CC Switch。

前两个负责干活，后一个负责把配置切换这件事从“改 JSON / 改 TOML / 改环境变量”里解救出来。

如果你只用单一官方账号，其实还没那么痛。但只要你开始碰这些场景：

一会儿走官方登录，一会儿走 API Key
手里不止一个账号，或者团队里不止一个源
Claude 和 Codex 都在用，希望切换时别各改各的
想顺手把提示词、MCP、技能配置也一起管起来

那你很快就会发现，纯手改配置文件这条路，能走，但很烦。

这篇我不讲虚的，就按一套能真正在本地跑起来的思路来写，主线是：

先把 Claude Code CLI 装好
再把 Codex CLI 装好
最后让 CC Switch 接管切换工作

我这里以 Windows 本地开发 为主。如果你本来就长期在 WSL 里开发，文中我也会把那条路顺手讲清楚。

先把角色分清楚

先别急着安装，先把这三样东西各自干嘛的搞明白，不然后面很容易装着装着就拧巴了。

Claude Code CLI 干什么

Claude Code CLI 本质上就是 Anthropic 的命令行编程助手。装完以后，你在终端里直接跑 claude，它就能读项目、改代码、跑命令、协助调试。

官方文档现在给的安装主线已经偏向 原生安装器，不是早期那种只靠 npm 的方式。

Codex CLI 干什么

Codex CLI 是 OpenAI 的终端编程代理。装完之后跑 codex，也是在终端里直接进工作流。

它支持两种常见登录方式：

用 ChatGPT 账号登录
用 OpenAI API Key 登录

如果你是日常手工使用，本地开发机上直接登 ChatGPT 通常最省心；如果你是在自动化、CI 或固定 API 工作流里跑，API Key 会更合适。

CC Switch 干什么

CC Switch 不替你“发明” Claude Code 或 Codex，也不替你把 CLI 主程序本体装好。它真正有用的地方是：

帮你管理不同 provider / preset
一键切换 Claude、Codex 这类 CLI 的活跃配置
顺手把 MCP、Prompts、Skills 一起管起来

换句话说，它是配置层的中控台，不是 CLI 本体替代品。

我的建议顺序

别上来先装 CC Switch。

最稳的顺序是：

单独把 claude 跑通
单独把 codex 跑通
最后再让 CC Switch 接手切换

原因很简单：如果一开始三样一起上，出了问题你都不知道到底是安装问题、登录问题，还是配置切换问题。

第一步：装 Claude Code CLI

先说结论：Windows 下要么准备好 Git for Windows，要么直接走 WSL。

Anthropic 官方文档写得很明确，Claude Code 在 Windows 上要求 Git for Windows 或 WSL，PowerShell、CMD、Git Bash 都能启动它，而且它内部会用 Git Bash 跑命令。

Windows 原生安装

如果你主要项目就在 Windows 本地目录里，先走原生安装就够了：

irm https://claude.ai/install.ps1 | iex

装完先验证：

claude --version
claude doctor

claude doctor 这个命令很有用。CLI 能不能正常拉起、路径有没有问题、环境有没有缺项，基本都能先看出来。

npm 兼容安装

如果你因为公司环境或者兼容性原因，暂时还得走 npm，也可以：

npm install -g @anthropic-ai/claude-code

但官方明确提醒过，不要用 sudo npm install -g。这类全局安装一旦权限搞乱，后面升级、执行、路径查找都会很恶心。

Claude 登录方式

安装完以后，直接运行：

claude

然后按浏览器提示登录就行。

这里要注意一件事：免费 Claude.ai 账户不包含 Claude Code 权限。官方文档写的是 Pro、Max、Teams、Enterprise 或 Console 账号可以用，所以如果你跑起来直接卡在权限阶段，先别折腾路径，先确认账号类型。

Claude 的配置文件在哪

Claude Code 官方的配置层次比较清楚：

全局用户配置：~/.claude/settings.json
项目共享配置：.claude/settings.json
项目本地私有配置：.claude/settings.local.json

我的实际建议是：

全局文件里放你长期固定的习惯
项目共享文件里放团队都认同的规则
本地私有文件里放你自己的实验项

例如我会把项目级限制写得比较保守：

{
  "permissions": {
    "allow": [
      "Bash(git diff:*)",
      "Bash(npm run dev)",
      "Bash(npm run build)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

这个思路很朴素：能放行的命令尽量小范围放行，密钥和环境文件默认拦掉。

第二步：装 Codex CLI

Codex 这边我建议你分两种情况看：

你主要就在 Windows 本机开发，先走原生
你本来就重度依赖 Linux 工具链，或者项目长期放在 WSL，直接走 WSL

最直接的安装方式

官方 CLI 页面给的主命令很简单：

npm i -g @openai/codex

装完直接跑：

codex

第一次运行时，Codex 会提示你登录。官方文档写得很清楚，它支持：

ChatGPT 账号登录
API Key 登录

如果本机是你日常开发环境，我建议优先用 ChatGPT 登录，少配一层；如果你准备做自动化或者明确按 API 账单走，那就用 API Key。

Windows 上到底要不要 WSL

这块最容易被说乱。

OpenAI 现在的文档其实有两个口径，你最好一起看：

CLI 总览页会提醒你：Windows 支持仍然是 experimental，并建议为了更好的体验优先考虑 WSL workspace
但 Windows 专页又给了三种可行方式，而且明确写了：默认优先考虑原生 Windows sandbox，WSL 更适合已经在 Linux 工作流里的场景

Windows 专页给出的三种方式是：

Windows 原生 elevated sandbox
Windows 原生 unelevated sandbox
WSL

所以我的实战建议是：

如果你的项目、Node、终端工作流本来就已经在 WSL，直接留在 WSL
如果你主要在 Windows 本机目录开发，可以先试原生
真遇到沙箱、权限或工具链兼容问题，再切 WSL

别一上来先把系统复杂度拉满。

Codex 的基础配置我怎么写

Codex 的认证缓存通常在：

~/.codex/auth.json

配置文件一般在：

~/.codex/config.toml

我自己的起手配置会偏稳一点：

model = "gpt-5-codex"
approval_policy = "on-request"
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = false
writable_roots = []

[windows]
sandbox = "unelevated"

这里解释一下我为什么这么配：

approval_policy = "on-request"：危险命令别默认乱跑
sandbox_mode = "workspace-write"：默认只在项目范围内写
network_access = false：先锁住网络，真要联网再开
Windows 下先 unelevated：一般更容易起步，后续你环境稳定了再考虑切 elevated

如果你是 Windows 11，而且机器权限足够、策略也放得开，可以再研究 elevated。官方文档对它的评价更高，但不是所有机器都能第一把就顺。

Codex 登录缓存别乱碰

Codex 官方文档专门强调了一点：~/.codex/auth.json 里存的是访问令牌。

这东西的处理原则就一句话：

把它当密码看。

别提交进 Git，别截图乱发，别贴到工单里，别同步到公开仓库。

第三步：上 CC Switch，把切换这件事接管掉

前面两个 CLI 都能独立跑通以后，再装 CC Switch，体验会明显好很多。

CC Switch 的定位

CC Switch 最适合解决的是这类问题：

Claude 和 Codex 都在用，但配置分散
官方登录和中转源要来回切
想统一管理 Prompts、MCP、Skills

它的 README 里已经把思路说得很明白了：别再手改一堆 JSON / TOML / .env，统一在一个桌面应用里切。

Windows 安装

最省事的方式，就是从它的 GitHub Releases 下对应的 Windows 安装包：

CC-Switch-v{version}-Windows.msi

装完以后，建议你先别忙着加十几个源，先做两个最小配置：

Claude 官方登录
Codex 官方登录

把“官方链路”先跑通，后面再加自定义 provider。

我实际怎么配

我的习惯一般是这样：

1. 先建两个官方登录预设

一个给 Claude Code
一个给 Codex

这样做的好处是，后面你就算折腾了别的中转配置，想回官方链路也有个干净的落点，不用再手工回填。

2. 再建自定义 provider

如果你手里有 API Key、团队网关或者别的兼容源，再往里加：

Claude 一套
Codex 一套

切的时候直接在界面点 Enable 就行。

3. 把 Prompt 同步也顺手开起来

CC Switch 的一个很实用的点，是它支持把不同工具的系统提示词统一管理。它 README 里写的同步目标是：

Claude: ~/.claude/CLAUDE.md
Codex: ~/.codex/AGENTS.md

这东西在团队协作时很顺手。你想让两边都遵守一套代码风格、测试习惯、提交原则，写一份统一规范，比每个 CLI 里重复维护要省事得多。

CC Switch 改的是哪些地方

这块我建议你自己把几个关键路径记住，因为排错时一定会用到：

Claude Code 常用配置：~/.claude/settings.json
Codex 常用配置：~/.codex/auth.json 和 ~/.codex/config.toml
CC Switch 自己的数据目录：~/.cc-switch/
CC Switch 的主数据库：~/.cc-switch/cc-switch.db

这点很重要，因为很多人装上之后总觉得“我明明在软件里点了切换，为什么命令行没变化”。本质上就是你得知道，到底是谁在读哪个配置文件，当前终端会不会重新加载它。

CC Switch README 里也专门提了一句：

大多数工具切换后需要重启终端或 CLI
Claude Code 是例外，当前支持热切

所以你切完 Codex 发现没立刻生效，先别怀疑人生，先把终端重开一下。

一套我觉得比较稳的本地组合

如果你问我，别整太花，日常开发该怎么配，我会给下面这套：

方案 A：Windows 主力方案

Claude Code：Windows 原生安装
Codex CLI：Windows 原生安装
CC Switch：Windows 桌面端
项目代码：放在本机开发目录

这套优点是最直观、切换成本最低，尤其适合你本来就主要在 PowerShell / Windows Terminal 里干活。

方案 B：WSL 工具链方案

Claude Code：可原生，也可跟着你的 WSL 工作流走
Codex CLI：直接装在 WSL 里
CC Switch：仍然作为配置中控
项目代码：尽量放到 WSL 的 Linux 文件系统里，比如 /home/xxx/code

这套更适合长期跑 Node、Python、容器、Linux 工具链的人。

但如果你还没形成稳定 WSL 习惯，不建议为了装 Codex 先把整套工作流都搬进去。

我踩过和见过的几个坑

1. 先装 CC Switch，结果 CLI 根本没跑通过

这几乎是最常见的误区。

CC Switch 解决的是“切换配置麻烦”的问题，不是“CLI 装不上”的问题。CLI 本体没装好，切换器再漂亮也没用。

2. 把认证文件当普通配置文件处理

像 ~/.codex/auth.json 这种东西，别手痒往仓库里放，也别跟配置模板一起同步。

模板和认证是两回事。

3. Windows 下路径和权限混在一起

Claude Code 在 Windows 上依赖 Git for Windows 或 WSL；Codex 则有自己的 Windows sandbox 逻辑。如果你一边原生、一边 WSL，再叠加一堆自定义路径，出了问题排查会很慢。

所以我一般建议：

一开始尽量走一条路径
原生就全原生
WSL 就把项目、Node、CLI 都放到 WSL 里

4. 切完源不重启终端

这事太常见了。

CC Switch README 已经写得很直白：多数工具切换后要重启终端或 CLI。你点完 Enable 没效果，先重开终端，再看。

最后给个最省时间的落地顺序

如果你今天刚开始配，我建议直接按这个顺序抄：

安装 Git for Windows
装 Claude Code，跑 claude doctor
装 Codex CLI，先用官方登录跑通一次
确认 claude 和 codex 都能独立工作
安装 CC Switch
在 CC Switch 里先建 Claude / Codex 的官方登录预设
再加你自己的 API Key 或中转 provider
最后再慢慢补 Prompt、MCP、Skills

这样配下来，结构最清楚，后面出问题也最好排查。

总结

把这三样搭起来之后，真正省下来的不是“点一下按钮”的时间，而是你以后每次切账号、切模型、切 provider 时，不用再去翻到底哪个工具读的是哪个文件。

我的理解很简单：

Claude Code CLI / Codex CLI 是干活的
CC Switch 是调度配置的

先把 CLI 跑通，再让 CC Switch 接管，这是我觉得最不容易翻车的顺序。

如果你后面还想继续往下折腾，我觉得下一步最值得做的不是继续加 provider，而是把：

Claude 的 CLAUDE.md
Codex 的 AGENTS.md

这两份团队规则文件整理好。因为真正决定你每天用起来顺不顺手的，很多时候不是模型本身，而是那层“默认工作习惯”有没有立住。