Codex 多账号怎么切换？9 款工具与会话保留方案
Codex Plus 额度用完后怎么换账号？对比 Cockpit Tools、CC Switch、OpenCodex 等 9 款工具，讲清官方账号、中转 API、账号池和会话保留的区别。
Codex Plus 的额度撞墙时，麻烦往往不在“再登录一个账号”，而在于正在跑的任务怎么办：换另一个 Plus 账号、改走中转 API，当前对话还能不能接着做？
短答案是：本地历史通常还在，换号后原任务却未必能继续。 能看到旧对话、能重新打开旧对话、能用新账号继续旧任务，是三件不同的事。只要会话里带有账号或 provider 相关的加密上下文，跨账号 resume 就可能失败。
如果只看选型结论：切 Base URL、API Key 和 provider，用 CC Switch；想在一个桌面应用里管理多个 AI 客户端，用 Cockpit Tools；需要运行时账号池和路由，再看 OpenCodex、Codex Tools 或 Codex-Manager。macOS 用户只切 Codex 官方账号，lizhelang/codexbar 和 Codex Switcher 更轻。
“会话保留”至少有四层
讨论切换工具前，需要统一口径。下面四层常被压缩成一句“不会丢会话”，结果买了工具才发现彼此说的不是一回事。
| 层级 | 实际含义 | 换号后的结果 |
|---|---|---|
| 历史文件保留 | ~/.codex/sessions 等本地文件没有被删除 | 记录还在磁盘上 |
| 历史可见 | Codex App 或 CLI 仍能列出旧任务 | 能看到标题和消息 |
| 原账号可续跑 | 切回创建任务的账号后可以继续 | 依赖旧账号仍可用 |
| 新账号可接管 | 换账号或 provider 后，旧任务继续发请求 | 难度最高，可能受加密上下文和 provider 兼容性限制 |
很多工具只负责替换 auth.json 或 config.toml，因此能做到前两层；本地代理和线程亲和路由可以改善第三层。第四层不能仅凭“一键切换”四个字推断。
9 款 Codex 多账号切换工具怎么选
| 工具与适合场景 | 切换方式 | 会话与边界 |
|---|---|---|
| 1️⃣ Cockpit Tools：同时管理多个 AI 客户端和账号 | 桌面端账号管理、本地 API 服务 | 未证明新账号能接管当前任务；功能较重，token 存储方式需单独检查 |
| 2️⃣ CC Switch：官方、中转和本地 provider 来回切 | 改写 Base URL、API Key、provider 配置 | 同一 Codex 目录可保留历史；跨 provider 续跑无保证 |
| 3️⃣ codexbar：macOS 上切 Codex 账号和 provider | 菜单栏改写同一套配置与认证 | 共享 ~/.codex 历史池；仍受跨 provider resume 限制，且仅支持 macOS |
| 4️⃣ codex-auth：想用一条 CLI 命令切官方账号 | 保存并切换账号凭据 | 普通模式需重启；无缝模式仍在实验阶段，额度刷新存在账号策略风险 |
| 5️⃣ Codex Switcher：想要独立 GUI、托盘和额度统计 | 桌面端 OAuth / auth.json 导入 | 切换前可能关闭 Codex；macOS 构建尚未公证 |
| 6️⃣ Codex Tools：需要 GUI、CLI/TUI 和本地代理 | ctc switch 或代理运行时轮换 | 代理模式可减少重启；跨 provider resume 仍可能失败 |
| 7️⃣ OpenCodex：多 provider、ChatGPT 账号池和配额路由 | 本地通用 provider proxy | 旧线程绑定原账号，新会话走健康账号；不会自动接管已耗尽账号的旧线程 |
| 8️⃣ codex-multi-auth：保留官方 Codex CLI，同时增加多账号能力 | OAuth 管理器、可选 wrapper 与本地代理 | 支持会话亲和、运行时轮换和故障转移；更适合熟悉代理链路的用户 |
| 9️⃣ Codex-Manager：团队或重度用户运营账号池 | 桌面端、服务端和 OpenAI 兼容网关 | 通过网关统一路由；部署维护较重，桌面支持偏 Windows |
Cockpit Tools：多 AI 客户端放进一个驾驶舱
Cockpit Tools 适合账号分散在 Codex、Claude Code、Gemini CLI 等多个客户端的人。它把账号切换、额度查看、唤醒和多实例放进桌面界面，还能通过内置的 CLIProxyAPI sidecar 提供本地 API 服务。
“一键切账号，而且主流模型都支持”只能概括它的产品方向，不能外推成“官方账号切到中转后，原任务一定续跑”。它解决的是集中管理和路由入口，具体会话仍受 Codex 本地状态与上游认证约束。
许可也值得看清。仓库公开源码不代表默认允许商业用途，当前 README 标注的是 CC BY-NC-SA 4.0；另外，项目文档明确提到 Grok token 以明文保存在本机。个人机器和团队机器的风险模型不同，安装前应按自己管理的账号类型核对。
CC Switch：切 provider 很顺手，别把它当会话迁移器
CC Switch 覆盖 Claude Code、Codex、Gemini CLI、OpenCode 等客户端，擅长管理 provider、Base URL、API Key、MCP 和配置预设。官方账号、中转站、本地模型经常来回换时，它的价值很直接。
它修改的是客户端配置和认证入口。共用同一套 ~/.codex 时，本地历史通常不会因为换 provider 自动删除；旧任务能否继续发送请求，则取决于认证格式、Responses API 兼容程度和会话中的加密内容。即使配置已经切换，OpenAI auth 识别失败仍可能让当前任务无法运行。
站内已有 CC Switch 安装与配置教程，桌面版和同名 CLI 版不要装混。
codexbar：macOS 上共享同一个历史池
lizhelang/codexbar 是一个 macOS 菜单栏工具。它没有为每个账号创建独立 CODEX_HOME，而是继续使用同一个 ~/.codex，切换时同步 config.toml 和 auth.json，让 sessions 与 archived_sessions 保持在同一历史池里。
这套设计允许账号和 provider 发生变化，同时避免任务列表散落到多个目录。它能证明的是共享历史池与 resume 入口，不是任何 provider 都能解密并接管旧上下文。仓库采用 MIT，当前定位明确偏向 Codex Desktop companion。
codex-auth：官方账号切换的轻量 CLI
Loongphy/codex-auth 走的是轻量路线，codex-auth switch 就能在 Codex CLI、VS Code 扩展和 Codex App 使用的账号之间切换。它还可以导入、导出 CLIProxyAPI token JSON。
普通模式切换后需要重启 Codex 客户端。项目也提供面向 App 的实验性无缝模式，但 README 明确提醒可能破坏应用。额度刷新会直接调用 OpenAI 端点，作者同样提示这类访问可能触发平台策略风险。想要可预测性时，接受一次重启往往比依赖实验补丁更稳。
Codex Switcher：偏桌面用户的独立 GUI
Lampese/codex-switcher 提供跨平台桌面界面、托盘切换、额度统计和定时 warm-up。账号可以通过 OAuth 登录，也可以导入已有 auth.json。
它会检测正在运行的 Codex 会话，必要时在切换前强制关闭客户端。这种处理谈不上“无感”，但边界很诚实：凭据正在被进程使用时，关闭再切能减少状态错乱。macOS 安装包目前没有公证，Gatekeeper 提示和分发信任需要自行评估。
Codex Tools：把静态切换和运行时轮换放在一起
170-carry/codex-tools 同时提供桌面 GUI、CLI/TUI 和本地 OpenAI 兼容代理。轻量用法是 ctc switch；需要根据额度选择账号时，可以使用 ctc switch --best --launch。把 Codex App 或 CLI 接到它的本地代理后，运行期间也能轮换账号，避免每次都关闭 Codex。
这个项目的 README 对会话边界写得比多数工具清楚：provider 同步后，历史里的加密内容可能重新可见；跨 provider resume 仍可能因为加密上下文失败。也就是说，它能把切换动作做顺，不能消除上游会话协议的限制。
OpenCodex：账号池靠线程亲和维持上下文
lidge-jun/opencodex 是面向 Codex、Claude Code 等客户端的本地通用代理，支持 40 多个 provider，也能管理 ChatGPT 账号池并按额度路由。
它对会话的处理方式是 thread affinity：已有线程继续绑定创建它的账号，新会话分配到当前用量较低的健康账号。这个设计能避免同一线程被随机打到不同账号，却也揭示了限制：创建线程的账号额度已经耗尽时，开一个新线程能换健康账号，旧线程不会因为“账号池”三个字自动由另一个账号接管。
项目采用 MIT。README 也提醒，代理使用方式可能违反上游条款或触发账号处置。账号池越自动化，越需要弄清官方订阅和 API 的使用边界。
codex-multi-auth：保留官方二进制的高级方案
ndycode/codex-multi-auth 是官方 Codex CLI 外围的多账号 OAuth 管理器，包含账号切换、健康检查、诊断、项目级存储，以及可选的 wrapper 和 loopback Responses proxy。
启用代理和 wrapper 后，它可以做运行时轮换、会话亲和、额度预测与故障转移；不启用时，官方 codex 仍然掌握执行入口。这个取舍适合不想替换官方 CLI、又愿意理解认证和本地代理的用户。项目说明把它定位在个人开发用途，生产环境仍建议使用官方 Platform API。
Codex-Manager：个人切换器再往上就是账号池平台
qxcnm/Codex-Manager 已经不只是“点一下换号”。它包含账号分组、标签、额度、平台 Key、路由、模型目录、插件和统一的 OpenAI 兼容本地网关，适合把多个账号当成一个可运营的资源池。
能力更全，代价是部署、升级和故障定位都更重。作者对 Windows 桌面端的支持承诺也比其他平台明确。只有两三个自用账号时，上这套系统容易把一个登录问题升级成网关运维问题。
两个 CodexBar 不是同一个项目
- steipete/CodexBar 是 macOS 菜单栏额度与用量监控器，能看多家 AI 服务的限额、重置时间、消费和状态。它不是 Codex 多账号切换器。
- lizhelang/codexbar 才是本文讨论的切换工具，README 明确写了共享
~/.codex会话池、切 OpenAI 账号和兼容 provider。
如果你的问题只是“Plus 还剩多少、几点重置”，前者更对路；要改账号或 provider，应该看后者。产品名相同，仓库作者和功能完全不同。
Codex 切换账号会丢会话吗
通常不会直接删除本地会话文件，但旧任务不一定能用新账号继续。判断时可以看三个位置：工具是否继续使用同一 CODEX_HOME，是否保留 sessions 目录，README 是否明确说明跨账号或跨 provider 的 resume 边界。
同一 CODEX_HOME 下只替换认证文件，历史列表大概率还在。换回原账号后，旧任务也更可能恢复。换成另一个官方账号或中转 provider 时，认证、模型协议、服务端线程和加密上下文都可能变化；任何工具若只展示“历史还在”，都不足以证明任务能继续。
对长任务更实际的做法，是在额度接近耗尽时让 Codex 写一份短交接：当前目标、已改文件、未完成步骤、验证结果和下一条命令。新账号开新任务后读这份交接，比赌跨账号恢复稳定得多。handoff 是降损方案，不是对话迁移协议。
不装工具也能管理多个 Codex 账号
账号之间需要强隔离时，CODEX_HOME 是最朴素的基线方案。每个目录保存独立认证、配置和会话，互不覆盖：
CODEX_HOME=~/.codex-work codex
CODEX_HOME=~/.codex-personal codex它的优点是可解释、容易回滚；代价是历史也被拆到不同目录，无法天然共享同一个任务列表。相反，直接在同一 ~/.codex 里替换 auth.json 可以保留历史池，却扩大了凭据误覆盖和跨账号恢复失败的风险。
不要把长期有效的 token 放进仓库、同步盘或即时通讯记录。手工备份认证文件时，也要按密钥文件管理，而不是把它当普通配置。
最后的选择建议
只有两个官方账号，且能接受切换后重启客户端，codex-auth 足够轻；偏好 GUI，就看 Codex Switcher，macOS 还可以看 lizhelang/codexbar。
经常在官方 API、中转站和本地模型之间切，CC Switch 的职责最贴合。多个 AI 客户端都要管，Cockpit Tools 更省事。
想在额度耗尽时自动挑账号，需要本地代理或账号池。个人开发者可以研究 Codex Tools、OpenCodex 或 codex-multi-auth；账号数量多、还要分组和平台 Key，再考虑 Codex-Manager。
无论选哪款，第一次测试都别拿唯一一条长任务冒险。建一个短对话，切账号，重启客户端，依次验证“历史可见、旧对话可打开、新消息可发送”。这三个勾都打上，才算适合自己的会话保留方案。
常见问题
Codex Plus 额度用完了怎么办？
可以等待额度窗口重置、升级套餐、切换另一个本人持有的官方账号，或改用合规的 API/provider。正在执行的任务应先留下交接记录；换账号后继续同一任务没有通用保证。
Codex 可以同时登录多个账号吗？
官方客户端的默认体验以当前账号为主。第三方工具通常通过保存多份凭据、切换 auth.json、隔离 CODEX_HOME，或让客户端连接本地代理来实现多账号管理。
换 Codex 账号后为什么历史还在，却发不了消息？
历史文件存放在本地，不代表新账号拥有旧线程的服务端状态或解密能力。账号权限、provider 协议、模型支持和加密上下文任一项不兼容，都可能让旧任务只能看不能续。
CC Switch 和账号池工具有什么区别？
CC Switch 主要管理客户端配置和 provider 预设；账号池工具位于请求链路中，会根据额度、健康状态或线程归属决定请求发给哪个账号。后者更自动，也更复杂。
哪款工具最适合保留 Codex 会话？
只谈历史池，lizhelang/codexbar 的设计最直观；需要代理内的线程亲和，可以看 OpenCodex 或 codex-multi-auth。跨账号、跨 provider 继续旧任务仍没有一款工具能对所有场景作出保证。
相关引用
AI 中转站精选
从充值换算、官方价格折扣和访问量三个维度，查看当前有代表性的服务商。
