CC Switch 实测:把 Claude Code、Codex、Gemini CLI 等 10 款 Agent CLI 的配置统一到一处

如果你跟我一样,Mac 里同时装着 Claude Code、Codex CLI、Gemini CLI,偶尔还想试试 Grok Build 或 OpenCode,大概率会被各自散落在 ~/.claude/、~/.codex/、~/.gemini/ 里的配置文件搞烦。切个 Provider 要手改 JSON,加 MCP server 要复制粘贴四五份,换个模型还得记每家不同的环境变量。

这周 GitHub trending 上冒出一个专门解决这事的工具:CC Switch。截至 2026-10-16,仓库 farion1231/cc-switch 已经 144k+ stars,最新版 v4.0.13(10-15 发布)。它把自己定位成「Claude Code、Codex、Gemini CLI、Grok Build、OpenCode、OpenClaw、Hermes、Pi、MiniMax Code」十款 Agent CLI 的统一管理器,用 Tauri 2 写的跨平台桌面应用。

我把它下载下来实测了一遍,结论先放前面:对多 Agent 用户确实有用,但有几个坑必须提前知道——尤其是它会把现有工具的认证 token 一起导入本地数据库,以及 Homebrew 安装的版本明显落后 GitHub Releases。


安装:官网 DMG 比 Homebrew 更稳

CC Switch 官方给了三种 macOS 安装方式:

Bash
# 方式一:Homebrew(当前版本滞后)
brew install --cask cc-switch

# 方式二:GitHub Releases DMG(推荐)
# 下载 CC-Switch-v4.0.13-macOS.dmg 拖进 Applications

# 方式三:zip/tar.gz 解压即用

我先用 brew info --cask cc-switch 查了一下,Cask 当前只到 4.0.9,而 GitHub Releases 已经是 4.0.13。这个差距不大,但说明 brew 同步有延迟。如果你在意最新修复,建议直接下 DMG。

DMG 体积 33MB,Universal 构建(x86_64 + arm64),已经过 Apple 签名与公证。我用 codesign -dv 验证过,Identifier=com.ccswitch.desktop,TeamIdentifier=R8UR22V2F9,无需绕过 Gatekeeper。

Bash
codesign -dv "/Applications/CC Switch.app"
# 输出包含 Authority=Developer ID Application: ...

实测环境:M4 / 16GB / macOS 26.5.2,CC Switch v4.0.13。


首次启动:自动导入现有配置,但也导入了 token

双击启动后,CC Switch 会创建 ~/.cc-switch/ 目录,里面有一个 SQLite 数据库 cc-switch.db、日志、settings.json 和模型定价缓存。我第一次启动时,日志里直接显示:

Plaintext
✓ Imported live config for claude as default provider
✓ Imported live config for codex as default provider
✓ Initialized 4 default skill repositories

也就是说,它会自动识别你已经安装的工具,并把现有配置读进自己的数据库。我查了一下数据库,Claude Code 因为本身没有本地 API key 文件(权限存在钥匙串),导入的是空配置;但 Codex 的 ChatGPT 登录 token 被完整写进了 cc-switch.db 的 providers 表。

这是一个必须提醒的安全点:~/.cc-switch/cc-switch.db 现在包含了你原本放在 ~/.codex/ 里的认证信息。文件权限是 -rw-------(仅所有者可读写),算合理,但如果你用 Time Machine、网盘同步这个目录,等于把 token 也一起备份出去了。建议:

  • 不要把 ~/.cc-switch 放进 Dropbox / iCloud 同步;
  • 在共享电脑前,退出 CC Switch 并删除 ~/.cc-switch;
  • 定期到 Settings → Data 里看备份占用与位置。

三种 Provider 模式,适合不同玩法

CC Switch 的核心是 Provider 管理。它支持三种工作模式:

1. Direct(直连) 工具直接连接你指定的 Provider,CC Switch 只负责改写配置文件。这是最简单、最不容易出错的模式。官方 Provider(Claude Official、OpenAI Official 等)通常只能走这个模式。

2. Routing(本地路由) 请求先经过本机 CC Switch 的代理层,它负责在 Anthropic Messages、OpenAI Chat Completions、OpenAI Responses、Gemini Native 之间做协议转换,并支持 failover 队列、熔断、健康检查。这意味着你可以「在 Claude Code 里用 GPT 模型,在 Codex 里用 Claude 模型」。

不过本地路由也有代价:首次配置要理解 endpoint、协议、模型名的映射关系;且某些上游特性(比如 Claude 的 extended thinking)可能走转换层会丢字段。我这次没有实际跑通端到端请求,因为本机 headless 环境无法启动完整 GUI 去设置路由,这条需要你在自己电脑上补测。

3. Aggregation(聚合) 把多个 Provider 的模型合并到同一个工具的模型列表里。比如 Codex 的模型下拉菜单里同时出现 OpenAI Official、OpenRouter、DeepSeek 等。注意:聚合模式不提供 failover,且 Codex 在列表变化后需要完全重启 CLI/daemon/桌面端。

三种模式里,普通用户先用 Direct 把配置管起来就够了;Routing 和 Aggregation 是给已经把 Agent CLI 当主力工具的人准备的进阶玩法。


MCP、Skills、Prompts 的统一面板

除了 Provider,CC Switch 还提供了三个集中管理面板:

  • MCP:一次添加 server,选择同步到哪些工具(Claude Code、Codex、Gemini CLI、Grok Build、OpenCode、Hermes、Pi、MiniMax Code);
  • Skills:从 skills.sh、GitHub repo 或 ZIP 安装,支持检查更新、批量更新;
  • Prompts:按工具维护 CLAUDE.md、AGENTS.md、GEMINI.md 等 prompt 文件,启用前会自动备份原文件。

这个设计的好处是,你不再需要为了同一个 MCP server 在 ~/.claude/、~/.codex/、~/.gemini/ 里写三份配置。坏处是:如果某个工具更新了配置格式,CC Switch 的同步模板可能滞后。10-15 的 v4.0.13 刚新增 Grok Build 的 MCP/Skills 支持,说明它确实在追赶新工具。


Sessions 阅读视图:一个被低估的功能

CC Switch 会把各工具的 session 日志解析成结构化阅读视图,显示每轮对话改了哪些文件、哪一步失败、token 消耗多少。对于需要复盘 Agent 行为的场景,这比直接翻原始 JSON 日志方便得多。

不过它目前不支持 resume OpenClaw 和 Hermes 的会话,Hermes 只显示最近 500 条。如果你主要用这两款工具,这个功能暂时 incomplete。


实测发现的问题

  1. 没有真正的 CLI,headless 环境无法启动 我尝试用 /Applications/CC Switch.app/Contents/MacOS/cc-switch --version 想打印版本,结果进程挂起等待 GUI。--help 同样不会输出帮助信息。这说明它目前没有独立的命令行界面,纯桌面应用。想自动化管理配置的人可能会失望。

  2. 首次启动在 headless 下会崩溃 我在无图形界面运行时,应用在初始化数据库、导入 provider 后,因为 stderr pipe 断裂而崩溃(Broken pipe (os error 32))。正常 macOS 桌面环境不会有这个问题,但 CI/远程服务器场景要注意。

  3. Homebrew 版本落后 前面提到 brew 只有 4.0.9,GitHub 已经 4.0.13。想体验最新功能请直接下 Releases。

  4. Codex 的 token 被明文导入数据库 再次强调这个安全风险。虽然文件权限收紧了,但 token 确实离开了原本 ~/.codex/ 的目录结构。


适合谁、不适合谁

适合: – 同时用 2 款以上 Agent CLI 的人; – 想统一管理 MCP、Skills、Prompts 的人; – 需要在 Claude Code 和 Codex 之间频繁切换 Provider 的人。

不适合: – 只用一款工具且基本不动配置的人; – 希望完全命令行自动化、不写 GUI 的人; – 对 token 本地存储非常敏感的人。


上手建议

如果你决定试试,建议按这个顺序:

  1. 先备份现有配置: bash cp -r ~/.claude ~/.claude.bak cp -r ~/.codex ~/.codex.bak cp -r ~/.gemini ~/.gemini.bak 2>/dev/null || true
  2. 从 GitHub Releases 下载 DMG,拖进 Applications;
  3. 首次启动后,到 Settings → Data 确认备份位置;
  4. 在 Provider 页把当前工具切到 Direct 模式,确认各 CLI 还能正常工作;
  5. 再逐步尝试 Routing 或 Aggregation,不要一上来就全开。

写在最后

CC Switch 解决的是一个真实痛点:Agent CLI 越多,配置管理越乱。它不是把十个工具合成一个,而是给它们做了一个统一的「遥控器」。对于已经把 Claude Code Mods、Codex CLI 当成日常工具的人来说,能省不少手工改配置的时间。

但它也不是银弹。本地路由的稳定性、token 导入的安全边界、headless 场景的缺失,都是使用中需要留意的点。如果你暂时只用其中一两款工具,先别急着装;如果你已经在三款以上 Agent 之间切来切去,这个 33MB 的小工具值得一下午试用。


相关阅读 – Graft 实测:给 Claude Code 建代码图谱,省下 98% 上下文 token – Headroom 实测:把 Agent 的上下文压缩 97% – CC Switch GitHub 仓库 – CC Switch 官网 – Homebrew Cask: cc-switch

推荐阅读

  • Graft(Trail-Code)实测:给 Claude Code 装上代码地图,10 文件项目 token 直降 98%

    Graft 是 trailhq/Trail-Code 开源的本地代码图谱工具,让 Claude Code 等 Agent 直接查地图而不必读完整文件。本文在 M4 Mac 上实测 @nanonets/…

  • Google 把 5 个嵌入模型压成一个 740M:EmbeddingGemma 2 本地实测,我踩了三个坑才跑通

    Google 开源多模态嵌入模型 EmbeddingGemma 2:740M 参数把文本、代码、图像、音频、视频压进同一个 768 维空间,Apache 2.0 可商用。本文在 Apple M4 上完…

  • Headroom 实测:给 AI Agent 压上下文,token 最高省 98%,但有个默认行为你必须知道

    Headroom 是 GitHub 本周趋势第一的开源上下文压缩层(75k 星、Apache-2.0),在工具输出、日志和 RAG 内容进入大模型前先压一道,帮 Agent 直接砍 token 成本。…

  • 腾讯云 TeamAI 实测:一行命令把团队 Skill 装进 16 种 Agent,未初始化的坑我先踩了

    腾讯云 10 月 10 日开源 TeamAI(teamai-cli),把团队 Skill、Rules、MCP 配置统一放进 Git 仓库,走 PR 评审分发到 Claude Code、Codex、Cu…