如果你最近在用 Codex CLI 这类 AI 编程助手并且同时接触了两三家大模型服务商的 API那你大概率已经体会过这种痛苦换一家供应商就要去翻配置文件、改 base_url、换 API Key然后重启终端运气不好还要被一长串英文报错砸脸。我第一次遇到 CC Switch就是在被这种报错折磨到快没脾气的时候。它是 GitHub 上的一个开源桌面工具核心作用一句话能讲清楚把「Codex / Claude Code 这类命令行 AI 工具背后的模型服务商切换」这件事从手动改配置变成鼠标点两下。它同时支持 Windows、macOS 和 Linux而且三个平台用的是同一套界面和操作逻辑基本不存在某个平台功能残缺的情况。这篇教程我按自己从零开始装到用顺手的顺序写先讲清楚它到底是干嘛的再分别给出三平台的安装步骤然后带你完成第一个 Provider 的配置和 Codex 对接最后把最容易遇到的 400 / 401 / 404 报错一次性讲透。不管你是第一次听说这个工具还是已经装上但被转发层报错卡住应该都能在这里找到答案。1. CC Switch 是什么为什么写代码的人需要它1.1 没有 CC Switch 之前的日常改配置改到怀疑人生先说一个很典型的场景。你同时在用两三家大模型服务商比如 DeepSeek 处理日常代码题某个本地模型跑私密数据偶尔还要切回 OpenAI 官方接口做兼容性验证。Codex CLI 这类工具的全局配置通常放在一个 TOML 文件里路径大致是这类位置macOS / Linux~/.codex/config.tomlWindowsC:\Users\你的用户名\.codex\config.toml文件内容长这样model deepseek-chat model_provider deepseek [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY wire_api chat只要你想换一家服务商就得手动改model、model_provider还要在[model_providers.xxx]下面新增一段配置填 base_url 和 API Key 的环境变量名。听起来不复杂但实际用起来有很烦的几个点第一记不住。每个服务商的 base_url 格式不一样有的要求末尾带/v1有的要求带完整版本路径有的只兼容/chat/completions这种格式多写一个斜杠都能给你脸色看。第二容易改坏。TOML 对缩进和字段顺序敏感手一抖多打了个引号整个文件解析失败Codex 直接起不来。这时候你还得先排查是语法问题还是配置问题非常浪费时间。第三多台机器重复劳动。公司电脑、家里电脑、临时借的机器每台都要配一遍配完还要担心两边配置不一致导致行为不一样。我自己最早是靠 shell 脚本切换的写了一个switch_deepseek.sh和一个switch_openai.sh本质就是备份再覆盖 config.toml。但脚本的问题也很明显没有可视化确认切换完不知道到底成没成而且脚本一旦写错后果比手改还隐蔽。所以当我发现 CC Switch 这种东西存在时第一反应就是这痛点终于有人做了 GUI。1.2 CC Switch 的核心能力拆解CC Switch 是个挺典型的 Tauri 桌面应用体积小、跨平台、界面干净。它的核心能力可以拆成四块能力解决的问题使用方式Provider 配置管理把各家服务商的 base_url、API Key、模型列表集中存一处GUI 里增删改查一键切换不用手改 TOML点一下就把 Codex / Claude Code 的配置改好选择目标 Provider 后点切换/应用本地转发服务给 Codex 一个固定入口请求由 CC Switch 转发到真实服务商开启后把 Codex 的 base_url 指向本机地址接口兼容层在/responses和/chat/completions之间做转换转发服务自动处理其中前两块很好理解就是用 GUI 替代手改配置。第三、四块是你在网上搜CC Switch 报错时最常碰到的东西。所谓本地转发服务通俗点说就是 CC Switch 在你电脑上开了一个小门卫Codex 不管配置成哪个服务商请求都先到这个门卫门卫根据你当前选中的 Provider把请求转给真实的服务商再把结果原样送回来。这样做的好处是你只需要让 Codex 认识这一个地址后面想换哪家服务商全在 CC Switch 界面里切换不用再动 Codex 的配置。坏处是多了一层中间环节只要转发这一层有点问题报错信息就会同时包含 Codex、CC Switch、上游服务商三方面的信息看起来特别唬人。后面第五部分我会专门拆这些报错。2. 全平台安装实操Windows / macOS / Linux 逐个过2.1 下载前先确认两件事系统架构和安装包格式CC Switch 的安装包通常发布在项目的 Releases 页面下载之前必须先确认两件事否则装不上或者装错版本白折腾一小时。第一你的 CPU 架构。绝大多数 Windows 和 Linux 电脑是 x64对应安装包名字里的x86_64或amd64Apple Silicon 的 Mac 要选arm64/aarch64Intel 的老 Mac 选x64。判断方法很简单Mac 看关于本机Linux 执行uname -mWindows 在设置-系统-系统信息里看系统类型。第二操作系统对应的安装包格式。我把常见情况整理成一张表平台安装包格式安装方式Windows.exeNSIS 安装向导或.msi也有便携 zip双击运行或解压直接用macOS.dmg镜像或.app压缩包打开 dmg 后拖进 ApplicationsLinux.debDebian/Ubuntu、.rpmFedora/RHEL、.AppImage通用包管理器安装或直接运行还有一个细节Windows 有少数 ARM 设备比如骁龙 X 芯片的笔记本如果下载错成 x64 版也不是不能跑但为了稳定最好选 arm64 的安装包。macOS 同理Apple Silicon 上跑 x64 版要靠 Rosetta 转译能用但没必要。2.2 Windows 安装步骤含 SmartScreen 拦截处理Windows 下安装是最简单的双击下载好的cc-switch_x.x.x_x64-setup.exe一路 Next 就行。但有两点在实际操作里经常卡住新人第一SmartScreen 蓝色弹窗。因为 CC Switch 是开源软件没有购买微软的代码签名证书Windows Defender SmartScreen 基本都会跳一个Windows 已保护你的电脑。这不是病毒处理方式是点更多信息然后点仍要运行。我第一次遇到时以为是下载错了文件换了三四个版本下载后来才发现每个都一样纯粹是签名问题。第二安装完成后程序在桌面或开始菜单里叫 CC Switch注意别和某些同名软件混淆。装完第一次启动如果提示缺少运行库一般是因为系统太老比如 Windows 10 早期版本去装一下 WebView2 Runtime 基本就能解决。我自己在 Win10 和 Win11 上都装过Win11 上最省心几乎零依赖。如果你不想装系统级应用也可以下载便携 zip 版解压后直接运行里面的 exe。便携版的好处是换机器不用重装缺点是它不会帮你创建开始菜单快捷方式和文件关联。2.3 macOS 安装步骤含 Gatekeeper 的两种绕过方式macOS 上装这类开源软件最大的障碍不是安装本身而是 Gatekeeper。正常的操作流程是双击 dmg把图标拖进 Applications 文件夹然后在启动台打开。但第一次启动时macOS 大概率会弹无法打开因为无法验证开发者。这时候有两个处理办法方法一鼠标右键或 control单击应用图标选择打开在弹出的对话框里再点一次打开。这个操作只对当前用户生效一次之后就能正常双击打开了。方法二如果你习惯用终端一条命令解决xattr -cr /Applications/CC Switch.app这个命令的意思是清除掉应用身上的隔离属性让系统认为这个 App 是可信的。注意-r表示递归处理目录内所有文件-c表示清除所有相关属性。执行完再双击打开就不会弹窗了。还有一个小坑如果你装的是 dmg 里的老版本升级新版前最好先把旧版从 Applications 删掉再拖新的进去否则偶尔会出现应用已打开无法替换的提示。Apple Silicon 用户还要留意下载时选aarch64还是arm64后缀的文件别误下 x64 版。2.4 Linux 安装步骤deb / rpm / AppImage 全流程Linux 是我实际踩坑最多的平台但摸清规律之后其实很简单。麻烦主要在于不同的发行版包管理方式不同依赖又容易缺。如果你是 Debian / Ubuntu / Deepin / UOS 这类用 dpkg 的发行版下载.deb后执行sudo dpkg -i cc-switch_x.x.x_amd64.deb如果提示依赖缺失再执行sudo apt --fix-broken install这样会自动把缺的依赖补上。Fedora / RHEL / openEuler 这类用 rpm 的发行版执行sudo rpm -ivh cc-switch-x.x.x.x86_64.rpm最通用的是.AppImage文件它不需要安装下载后加执行权限就能跑chmod x CC-Switch-x.x.x.AppImage ./CC-Switch-x.x.x.AppImage但 AppImage 有两个 Linux 老用户都会遇到的问题。第一是缺 FUSE 库报错内容通常包含 FUSE 字样Debian/Ubuntu 系执行sudo apt install fuse就能解决有些新版发行版需要libfuse2对应版本。第二是如果你的系统很精简Tauri 应用依赖的 WebKitGTK 没装应用能启动但界面白屏这时候要补sudo apt install libwebkit2gtk-4.1-0总的来说Linux 上最省事的是 deb 或者 rpmAppImage 适合不想污染系统的场景但依赖问题多一点。我个人的建议是能用包管理器就用包管理器装完还能用dpkg -l | grep cc-switch检查版本后续卸载也干净。3. 第一次使用Provider 配置与 Codex 对接3.1 添加 DeepSeek Provider 的完整步骤安装完成后第一次打开 CC Switch界面基本是空的你需要先添加一个 Provider。我用 DeepSeek 做例子把每一步该填什么讲清楚。第一步点主界面的添加服务商按钮。名称这一栏建议填英文比如deepseek。倒不是说中文不行而是后续生成的配置文件里Provider 名称会作为 TOML 的节点名出现中文节点名在一些老版本工具里会有编码兼容问题白给自己找事。第二步填 Base URL。DeepSeek 的 OpenAI 兼容接口地址是https://api.deepseek.com/v1注意只填到/v1为止不要手贱在后面加/chat/completions。这个字段的语义是服务商的根地址具体请求路径由 CC Switch 自动拼接。不同服务商的地址格式五花八门有的甚至不带/v1所以填之前先看官方文档这是 404 报错最重要的来源之一。第三步填 API Key。先去 DeepSeek 开放平台后台创建一个 API Key通常长这样sk-xxxxxxxxxxxxxxxx。复制粘贴的时候小心别把空格带进去这个错我在团队里见过至少三次报错全是 401。第四步填模型列表。把该服务商下常用的模型名都填上DeepSeek 现阶段主要是deepseek-chat和deepseek-reasoner两个一个偏日常对话一个偏深度推理。多填的好处是后面切换模型时下拉框里有现成的可选不用每次手敲省得拼错。第五步选择接口兼容模式。DeepSeek 支持 OpenAI 兼容格式通常选chat/completions或者自动就行。如果你打算用本地转发服务这个选项关系到 CC Switch 在转发时做不做格式转换选错就会在调用时报错。保存之后你会看到列表里多了一条记录这条记录就代表一个可用的模型服务商组合。3.2 配置 Codex CLI 指向 CC Switch添加完 Provider接下来要让 Codex 真正用上它。CC Switch 提供两种方式我把它们分别叫直接切换模式和本地转发模式。直接切换模式的操作非常直白在 Provider 列表里选中刚才的deepseek点切换或应用按钮CC Switch 会读取 Codex 的配置文件自动把model、model_provider、[model_providers.deepseek]等字段写进去。完成后你打开配置文件看一眼会发现内容和第一节里我贴的那个示例几乎一模一样。这里有个关键点需要你理解CC Switch 帮你做的本质上是写文件它没有对 Codex 做任何运行时注入。所以切换完成后一定要重启 Codex 会话或者干脆退出终端重新进配置才会重新加载。如果切完发现没生效八成是没重启九成是这个原因。另外Codex 读取 API Key 有两个渠道一个是从环境变量读这也是 CC Switch 生成的配置里env_key DEEPSEEK_API_KEY的含义另一个是走 Codex 自己的登录态。我的建议是先用系统环境变量把DEEPSEEK_API_KEY配好Windows 上在系统属性-环境变量里设置macOS 和 Linux 在~/.zshrc或~/.bashrc里加一行export DEEPSEEK_API_KEYsk-xxxx然后source一下。配置好后在终端里跑一句codex exec 你好能正常返回内容说明直接切换模式已经通了。3.3 直接切换和本地转发到底选哪个很多朋友装完 CC Switch 都会困惑既然直接切换模式这么简单为什么还要搞一个本地转发服务出来我自己的理解是两者解决的是不同层次的痛点。直接切换模式适合我明确知道自己现在要用哪家比如上午写业务代码用 DeepSeek下午做评测切到某个本地模型每次切换都是主动的、低频的。它的优点是零附加依赖Codex 直连服务商链路最短报错也最好排查。本地转发模式适合我不想让 Codex 感知服务商变化的场景。比如你在调试一个复杂的 agent 流程需要连续试好几家服务商的模型效果每次都要改配置重启会话会打断思路。这时候开一个本地转发入口Codex 永远只认一个地址你在 CC Switch 界面里随便切上游Codex 那边完全无感。对比维度直接切换模式本地转发模式原理改写 Codex 配置文件本地开一个转发入口统一出口链路长度Codex → 服务商Codex → 本地转发 → 服务商切换成本需要重启 Codex 会话界面切换后基本即时生效报错排查难度较低链路短较高报错信息包含多层适合场景单机单人、明确目的频繁切换、多服务商对比、团队模板我的建议是新手先老老实实用直接切换模式把整个流程跑通。等熟悉了配置结构和报错规律之后再尝试本地转发也不迟。一开始就用转发模式遇到报错你会分不清是自己配置问题、CC Switch 问题还是上游问题容易劝退。4. 本地转发服务原理与实战4.1 本地转发服务在背后做了哪些事要理解本地转发模式得先知道 Codex 默认走的是 OpenAI 的 Responses API也就是请求路径通常是/responses。但很多服务商只实现了更早的 Chat Completions API路径是/chat/completions两者请求格式和返回格式都有差异。这里就出现了一个兼容性问题你不可能让每个服务商都去实现/responses只能让中间层来做转换。CC Switch 的本地转发服务就是这层翻译官。当你开启它时CC Switch 会在本机启动一个 HTTP 服务监听一个本地端口假设叫127.0.0.1:15901具体以你版本界面显示为准一般在设置页能改。然后在 Codex 的配置里把base_url指向这个地址[model_providers.local_gateway] name CC Switch Gateway base_url http://127.0.0.1:15901/v1 env_key CC_SWITCH_API_KEY wire_api responses这样一来Codex 发出/responses请求到达本地转发服务转发服务先看一眼你当前在 CC Switch 里选中的 Provider 是谁然后决定把请求转给哪个真实服务商并且根据该服务商支持的特性做格式转换。如果服务商只支持/chat/completions转发服务就把 Responses 格式翻译成 Chat Completions 格式拿到结果后再翻译回 Responses 格式给 Codex。这个设计在概念上很像家里装了一个智能插座电器的插头规格不变插座自动适配不同的电源。你在 CC Switch 里切换 Provider就相当于换了背后的电源Codex 这个电器完全不需要动。但正因为有了这层中间转换很多问题也随之而来。比如某个字段在转换过程中丢了、某个服务商对请求格式有特殊要求、某个端点路径在本地和上游对不上这些都会变成你在终端里看到的那些local proxy failed类报错。别慌绝大多数都是配置层面的问题不是工具坏了。4.2 不要跳过的一步用 curl 先验证链路无论什么代理类工具我强烈建议你先跳过 GUI直接用 curl 把链路测通。这一步能帮你节省太多排查时间。第一步验证上游服务商本身可用。这个请求直接发到 DeepSeek 官方地址curl https://api.deepseek.com/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-你的真实Key \ -d {model:deepseek-chat,messages:[{role:user,content:你好}]}如果这一步能返回正常的 JSON 结果说明 Key 有效、模型存在、网络没问题。第二步验证本地转发服务。在 CC Switch 里开启转发功能后执行curl http://127.0.0.1:15901/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-任意占位 \ -d {model:deepseek-chat,messages:[{role:user,content:你好}]}注意这里 Authorization 可以填任意占位符因为转发服务会自己用界面里保存的真实 Key 去请求上游。如果这一步也正常说明 CC Switch 的转发功能和路径拼接都没有问题。如果这一步挂了那问题就定位在 CC Switch 这一层你再去检查界面里的 Provider 配置就对了不用在 Codex 那边瞎猜。第三步才是把 Codex 的base_url指过来然后跑codex exec 你好做端到端验证。很多教程把这三步混在一起讲导致出了问题不知道甩锅给谁。分步验证的思路其实也适用于以后排查任何工具链问题。5. 高频报错排查400 / 401 / 404 一次性讲透5.1 HTTP 400thinking mode 的 reasoning_content 回传问题这是网上搜 CC Switch 时最常见的一条报错原文大概长这样cc switch local proxy failed while handling codex endpoint /responses. provider: deepseek; model: deepseek-v4-flash; upstream_status: http 400; cause: the reasoning_content in the thinking mode must be passed back to the api.这条报错信息量很大我拆开解释。local proxy failed while handling codex endpoint /responses意思是 CC Switch 的本地转发服务在处理 Codex 发来的/responses请求时失败了后面跟着的provider: deepseek和model: deepseek-v4-flash说的是当时选中的服务商和模型名upstream_status: http 400说明上游服务商返回了 400而最后那句reasoning_content的报错是真正的病根。reasoning_content是带思考模式thinking mode的模型在返回时附带的一个字段内容是模型推理过程的中间文本。DeepSeek 的deepseek-reasoner类的模型就会返回这个字段。问题在于这类模型在对话历史里要求把上一轮的reasoning_content原样传回否则就报 400。Codex 主打的 Responses API 本身也支持思考模式请求里会带 reasoning 相关参数但这个参数和上游服务商要求的回传格式不一定完全一致。如果 CC Switch 较老版本的转发服务没有把reasoning_content正确回传你就会看到这条报错。解决办法按照代价从低到高排列可以逐个试在 Codex 会话里关闭思考模式。Codex 一般用快捷键比如shifttab或命令切到非 thinking 模式关掉后请求里不再要求回传reasoning_content问题直接消失。换一个不带思考链路的模型。把模型从deepseek-reasoner换成deepseek-chat后者不产生reasoning_content自然没有回传问题。升级 CC Switch 到最新版。这类兼容性 bug 在靠转发层工作的工具里更新得很勤快新版本一般会处理 reasoning 字段的回传。检查模型名是否真实存在。报错里的model: deepseek-v4-flash这类名字如果你只是复制错了上游根本不认识这个模型也会被当成 400 处理。一定要确认模型名和 Provider 支持的模型对得上。5.2 HTTP 401鉴权失败先检查这四处401 的报错信息通常长这样unexpected status 401 unauthorized: cc switch local proxy failed while handling ...。症状很统一上游不认你的身份。但原因五花八门我按出现频率排序分享几个实际排查点。第一API Key 复制出了问题。最常见的是多了一个空格、少了一位字符这种情况肉眼很难看出来。我的习惯是把 Key 粘贴到一个纯文本编辑器里再复制出来避免剪贴板历史工具夹带格式。还有一种情况是 Key 填对了但填到了界面的备注栏而不是 Key 栏等于没填。第二环境变量和界面 Key 不一致。直接切换模式下Codex 走的是env_key指向的环境变量本地转发模式下转发服务用的是 CC Switch 界面里保存的 Key。如果你改了环境变量但忘了同步更新界面里的 Key或者反过来就会出现curl 能通、Codex 却 401的诡异现象。这也是为什么我建议用上面第 4.2 节的分步 curl 验证法它能精准定位是哪一层的 Key 不对。第三服务商的鉴权方式特殊。大部分兼容 OpenAI 的服务商只认Authorization: Bearer key但有个别服务商要求自定义 header比如x-api-key。这种情况你需要在 CC Switch 的 Provider 配置里加自定义请求头而不是把 Key 填到标准 Key 栏。第四Key 过期或账户异常。开源模型的 Key 也有有效期和额度一张欠费的卡或者过期 Key服务商懒得给你区分直接统一回 401。不妨去服务商后台看一眼额度够了没。5.3 HTTP 404endpoint 对不上九成是路径问题404 的报错特征也很明显unexpected status 404 not found: cc switch local proxy failed while handling ...。上游明确告诉你没有这个地址问题基本都出在路径拼接上。最常见的三种情况第一种base_url填得不对。比如服务商要求的是https://api.xxx.com/v1你只填了https://api.xxx.com转发服务把请求拼到了根路径上游自然 404。反过来有的服务商文档里给的是https://api.xxx.com/v1/chat/completions如果你把这个完整地址填进 Base URL 栏转发服务再往后拼/chat/completions就会变成/v1/chat/completions/chat/completions同样 404。牢记Base URL 只填到版本前缀为止。第二种接口兼容模式选错。本地转发模式下如果 Provider 只支持/chat/completions但你在转发时用了/responses的透传上游没有这个端点就 404。这类问题要去 CC Switch 界面里检查 Provider 的接口兼容方式改成自动或 chat 模式并对 Codex 侧的wire_api也做对应调整。第三种自定义模型名引起的路由异常。部分工具会拿模型名做路径参数模型名里带着奇怪的字符或斜杠也会导致上游找不到端点。保持模型名干净只填服务商官方文档里的名称。排查 404 时还是推荐老办法先直接 curl 服务商官方地址确认官方路径是可用的再 curl 本地转发地址对比两者谁 404。官方地址通、本地地址不通问题在转发配置两地都不通问题在网络或 Key 之外的服务商侧。5.4 报错速查表与一条避坑清单把前面几个主要报错整理成一张速查表建议存下来报错特征常见原因首选处理400含reasoning_content思考模式回传逻辑不兼容关思考模式 / 换 chat 模型 / 升级 CC Switch400模型名提示不存在模型名拼写或复制错误核对官方模型名列表401 unauthorizedKey 无效、未传或环境变量同步问题分步 curl 验证检查 Key 和 env 一致性404 not foundbase_url 路径错误 / 兼容模式不对只填到版本前缀检查接口兼容选项连接被拒绝connection refused转发服务没启动或端口被占确认转发开关已开启改端口重试配置不生效切换后未重启 Codex / 未点应用保存并重启 Codex 会话最后一条避坑清单是我踩坑总结出来的不要在一大早精神不好的时候做多个变量同时调整。很多朋友一遇到报错就同时改模型名、改 base_url、改接口模式、重装软件结果完全无法判断是哪个改动救回来的。正确做法是每次只改一个变量改完用 curl 验证再改下一个。磨刀不误砍柴工。6. 进阶用法与个人心得6.1 多 Provider 管理的几个小建议当你的 Provider 列表超过三四个以后取名就会变成一件影响幸福感的事。我的建议是采用服务商-用途-环境三段式命名比如deepseek-main、deepseek-test、ollama-local。名字里有用途和环境切换时一眼就知道自己在用什么避免我明明选了 DeepSeek 为什么回答风格不对的乌龙。团队协作场景下我还会把一份只包含配置不含 Key的 Provider 清单放在内部文档里共享。新同事入职后照着抄名字和 base_url只需要填入自己的 Key十分钟就能把环境搭起来。注意不要共享真实 Key这个是底线。另外CC Switch 这类工具是典型配置即文件的模式它的很多设置其实都对应着某个本地文件。如果你熟悉命令行学会直接查看和备份这些配置关键时刻比 GUI 更可靠。我就曾经因为界面卡死直接改配置文件救回过一次紧急演示。6.2 配置文件的落盘位置你得心里有数不管你用直接切换还是本地转发最终 Codex 读到的配置都在固定位置。我把常见路径再列一次系统Codex 全局配置路径WindowsC:\Users\用户名\.codex\config.tomlmacOS~/.codex/config.tomlLinux~/.codex/config.toml这个目录下除了config.toml通常还有auth.json等登录态文件。如果使用环境变量作为 Key 来源auth.json 的作用会弱化但别手贱随手删。需要备份时整个.codex目录打包走就行。操作上有个小细节改配置前先确认没有正在运行的 Codex 会话否则两者可能互相覆盖。CC Switch 在切换时一般会自己处理好但你手动编辑文件时最好先退出 Codex 进程。备份命令也很简单cp ~/.codex/config.toml ~/.codex/config.toml.bakWindows 下对应的是复制粘贴道理一样。备份永远不嫌多。6.3 关于 API Key 安全的几点提醒用这类 GUI 工具管理多个 API Key 很方便但安全这根弦不能松。我自己经历过 Key 被泄露到代码仓库的尴尬所以要专门提醒几句。第一不要把 Key 明文写在团队共享的配置文件里。CC Switch 支持把 Key 交给系统钥匙串macOS 的钥匙串、Windows 的凭据管理器保管能用这个功能就用。第二环境变量优先。尤其直接切换模式下Codex 的配置里尽量只保留env_key DEEPSEEK_API_KEY这样的变量名真正 Key 放在系统环境变量里。这样即使 config 文件被分享出去也不会连 Key 一起泄露。第三发现 Key 泄露后立即去服务商后台重置/吊销旧 Key不要只是删配置。AI 服务的 Key 一般按用量计费泄露后别人可以在你不知情的情况下消耗额度。我认识的一个朋友就是月末对账时发现多了一笔莫名其妙的费用一查才知道是三个月前某次测试时把 Key 打到了公共仓库里。第四本地转发模式下Key 在 CC Switch 界面里是可见的所以公用电脑上用完记得退出应用有些版本支持设置里加启动密码能开就开。我个人在实际操作中的体会是CC Switch 最大的价值不是省掉了几行配置文件而是让换模型服务商这个心理成本降到了几乎为零。以前我想对比两个模型的效果光是切换配置、重启会话、确认生效就得折腾五分钟很多临时起意的对比测试就这么被拖延症劝退了。现在有了界面化管理我可以随时把 Codex 切到另一个服务商跑一轮再切回来整个过程不会有太大的心态负担。最后再分享一个小技巧无论你用不用本地转发模式我建议你在 CC Switch 里保留一条官方直连的 Provider 作为对照。每次遇到奇怪的报错先切到这条官方配置跑一下如果能通说明出问题的是其他 Provider 的配置或兼容性而不是 Codex 本身或 CC Switch 整体出了毛病。这个对照法让我少做了很多无用功希望你也能用上。
