最近我一直在测试各种 Agent 客户端产品，经常要比较同一套模型在不同客户端里的登录、调用和工作流体验。偏偏手上的账号也不止一个：一个是自己付费订阅的 ChatGPT Plus，另一个则通过面向开源维护者的 Codex for Open Source 计划获得了 ChatGPT Pro 20x 权益。
账号多本来是件好事，真正测试起来却很折腾：日常工作想留在 Plus 账号，遇到开源项目又会切到 Pro；每次退出再登录既慢，也很容易弄混当前账号。
手动备份和替换 ~/.codex/auth.json 当然可以，但文件名很快就会变成 auth-old.json、auth-new.json 和 auth-final.json。更麻烦的是，登录凭据在使用过程中可能自动刷新，旧备份并不一定还是最新状态。
于是我做了 Codex Auth Switch：一个基于 Tauri、React 和 Rust 的纯本地桌面工具。它最初只负责保存和切换账号，后来又加入 OAuth 配对、一次性 Auth 迁移、本机 Token 统计、模型提供方归类、订阅额度巡检和只读环境体检。
说明： 本文截图均使用项目内置的脱敏预览数据，并开启邮箱私密模式，不包含真实账号、验证码或认证信息。
简单概括，Codex Auth Switch 解决的是三个不同场景：切换留在本机，添加交给 OAuth，换机才使用一次性迁移。
快速开始
下载安装
Codex Auth Switch 提供 macOS、Windows 和 Linux 安装包，可以从 GitHub Releases 下载；如果 GitHub 速度不理想，也可以使用 CNB Release 镜像。两个渠道提供相同版本。
| 系统 | 架构 | 推荐安装包 |
|---|---|---|
| macOS | Apple Silicon | macOS_arm64.dmg |
| macOS | Intel | macOS_x64.dmg |
| Windows | x64 | Windows_x64-setup.exe，也可选择 .msi |
| Linux | x64 | .AppImage、.deb 或 .rpm |
macOS 下载后打开 DMG，将应用拖入"应用程序"目录。安装包目前使用 ad-hoc 签名，首次启动如果被系统拦截，可以前往"系统设置 → 隐私与安全性"确认打开。Windows 推荐使用 setup.exe；Linux 则按发行版选择 DEB 或 RPM，不想安装时可以直接运行 AppImage。Release 中的 .app.tar.gz、.sig 和 latest.json 是应用内更新使用的文件，手动安装不需要下载。
配置与操作
当前版本只管理 Codex 的文件凭据。安装完成后，先编辑 CODEX_HOME/config.toml，默认是 ~/.codex/config.toml，加入：
toml
cli_auth_credentials_store = "file"应用不会修改 keyring 或 auto 模式，也不会把 API Key 登录当作订阅账号。配置完成后，按照下面的顺序操作：
- 保存当前账号：确认 Codex 已经通过 ChatGPT 订阅登录，打开 Codex Auth Switch，为当前登录设置名称并保存；
- 添加其他账号：选择"OAuth 添加账号"，设置本机名称，再到可信浏览器中输入配对码并完成授权；
- 日常切换账号 ：在本机账号库中选择目标账号，点击切换。Codex 下一次请求会读取新的
auth.json； - 查看本机用量：进入 Token 用量页，查看今天、近 7 天和近 30 天统计、14 天趋势、输入输出构成、账号归属与模型提供方拆分；
- 巡检订阅额度：进入订阅额度页，比较已保存账号的额度窗口、恢复时间线、可用完整重置次数与最早过期时间；
- 检查本机环境：在设置页运行只读体检，检查文件凭据配置、认证结构、文件权限、账号库一致性、切换历史与原子写残留；
- 换机时迁移：只有旧设备准备停止使用该账号时，才生成一次性 Auth 迁移内容；两台设备需要长期使用时，请选择 OAuth 配对。
这样配置一次后，日常使用基本只需要"打开应用 → 选择账号 → 切换"。只有更换设备时，才需要使用一次性 Auth 迁移。
安全提示： 使用边界： Codex Auth Switch 只面向同一用户管理自己有权使用的账号，以及本人控制的可信设备。OpenAI 的账号共享政策允许本人在多个设备上使用自己的账号，但不允许把账号交给其他人；使用条款同样禁止共享凭据，以及规避用量限制或保护措施。本工具不会合并订阅额度或改变服务端限制，请勿用于出租、转售、共享账号或绕过限额。Codex 的登录缓存与 Device Code 说明以官方认证文档为准，条款更新时也应以官方最新版本为准。是否符合条款最终取决于实际使用方式；这里描述的是项目的设计边界，不构成法律意见。项目与 OpenAI 无隶属、赞助或背书关系，Device OAuth、令牌刷新和订阅用量查询中的具体线协议属于兼容性实现，并不是官方保证稳定的公开 API。
思路来源
这个想法最直接的灵感，来自 Jason Young 在 X 上分享的 使用 CC Switch 在两个 Codex 官方账号之间快速切换。帖子通过分别保存两份官方账号配置来减少重复登录，并处理切换后的凭据更新，让我确认："多账号状态如何保持最新"并不是个例。
Codex Auth Switch 没有沿用通用供应商切换的路线，而是只聚焦 Codex 的本地文件凭据。在实际开发和使用中，我又把问题继续拆开：同一台电脑上的账号切换、自己的另一台设备独立登录，以及换机时的一次性交接，本质上是三条不同的流程。这也成为后续 OAuth 配对与 Auth 迁移功能的设计起点。
使用场景
最开始我把"多账号"理解成保存几份 Auth，然后在需要时替换当前文件。真正使用以后才发现，账号切换、给自己的另一台设备添加账号、把登录从旧设备搬到新设备，其实是三件不同的事。
| 场景 | 推荐方式 | 适合做什么 |
|---|---|---|
| 同一台电脑切换账号 | 本机账号库 | 保存当前登录，之后一键切换 |
| 给自己的另一台设备添加账号 | OAuth 配对 | 让新设备独立完成登录，适合长期使用 |
| 从旧设备搬到新设备 | 一次性 Auth 迁移 | 把登录交给接收端，发送端随后停止使用 |
选择方式时，可以先判断账号准备在哪里使用：
单机切换账号
Codex Auth Switch 会识别当前 Codex ChatGPT 登录，并把账号快照保存在应用自己的本地账号库中。切换时，它会先保存当前账号可能已经轮换过的凭据，再校验目标账号，最后原子替换 CODEX_HOME 中的 auth.json。
**整个切换过程不代理 Codex 请求。**替换完成后，Codex 在下一次请求时读取新的本地凭据，账号切换就生效了。
应用也会读取 Codex 会话中的 token_count 元数据，汇总今天、近 7 天和近 30 天的本机 Token 用量。这里的 Token 数字只是本机会话统计，并不等于 ChatGPT 订阅额度；历史会话也不一定能准确归属到某个账号。
除了账号归属，当前版本还会读取每个会话记录的 model_provider，把近 30 天 Token 按模型提供方拆开。OpenAI 默认提供方与各个自定义提供方会分别统计；没有记录 model_provider 的会话则归入未识别。这个字段只表示请求使用的模型提供方，不能证明使用的是 ChatGPT 订阅还是 API Key，也不能据此判断最终计费方式。普通模式只显示配置中的服务主机，不保存 API Key 或完整地址。
官方文档同样区分了 ChatGPT 订阅登录和 API Key 登录；Codex Auth Switch 只管理文件模式下的 ChatGPT 登录缓存，不会把 API Key 当作订阅账号保存。
订阅额度巡检
本机 Token 和在线订阅额度现在是两条独立的数据流。打开 Token 页面只解析本机会话文件，不会访问在线额度接口；订阅额度页则按账号查询窗口状态，并展示最近恢复、完整重置次数与最早过期时间。单个账号查询失败时会独立降级，不影响其他账号，也不会影响账号切换和本机统计。
"额度补给路线"把当前账号、最高窗口使用率、最近恢复与完整重置集中在一条时间线上，下面仍保留每个账号的窗口明细，方便判断应该继续使用当前账号，还是等待窗口自然恢复。这里展示的订阅窗口来自 ChatGPT 兼容性接口，具体端点与字段不是 OpenAI 承诺稳定的公开 API；变化时可能影响额度显示，但不会改变本机 Auth 切换逻辑。
跨设备账号添加
如果想让另一台电脑长期使用某个账号，我更推荐 OAuth 配对，而不是把现有 Auth 发过去。
新设备在应用内发起登录后，会显示浏览器地址和短期有效的一次性验证码。同一用户在可信浏览器中登录 ChatGPT、输入验证码并完成授权，新设备随后自动保存并切换到新账号。这个过程不需要导出发送端已经存在的 Auth，也不需要把 ChatGPT 密码交给应用。
这套 Device Code 流程并不是 Codex Auth Switch 自创的协议，而是 Codex CLI 本身就在用的登录方式：当 CLI 运行在没有本地浏览器的环境（例如 SSH 远程服务器）时，同样会显示一个验证地址和一次性验证码，让用户在别处的浏览器完成授权。Codex Auth Switch 只是把这套 CLI 已经在用的登录能力，接入到桌面应用里，用来给同一账号添加新设备，而不是重新实现一套认证协议。
从实现上看，浏览器授权和应用轮询是同时发生的。前端只展示授权地址、一次性验证码和剩余时间；真正的状态查询、令牌交换、账号校验与写入都在 Rust 后端完成：
OpenAI 认证文档将 Device Code 登录标记为 Beta。个人用户可能需要先在 ChatGPT 安全设置中启用，工作区账号则可能需要管理员开放相应权限。这也意味着 Device Code 的具体接口和字段是 Codex CLI 的内部实现细节，并非官方对外承诺稳定的公开 API，未来可能随 CLI 自身的调整而变化。
需要注意：配对码虽然不是密码，但在有效期内同样可以授权设备，因此只能在本人预期的可信设备上使用，不能提供给其他人。
旧设备迁移
有时并不是要让两台设备一起使用，而是换电脑，希望把登录从旧设备搬到新设备。这时可以使用一次性 Auth 迁移。
应用会先明确提示迁移的使用边界：停止发送端的 Codex 桌面端、CLI 和 IDE 扩展，确认不会继续切换到这个账号，再刷新并准备迁移内容。
发送端会先要求停止使用该账号，然后强制刷新凭据，生成二维码和剪贴板共用的一份 CAS3 迁移内容。CAS3 不再携带 access token、账号 ID、账号名称和刷新时间，只保留接收端兑换所需的数据；接收端导入后会立即联网刷新、校验账号并重建完整 Auth，全部成功后才写入本地。
接收端既可以读取剪贴板中的迁移文本，也可以选择应用生成的二维码图片。无论选择哪种方式，原始令牌都只在 Rust 后端中兑换和校验，不会显示在界面或写入日志。
安全提示： 上图二维码是内置预览数据。真实迁移内容包含可登录凭据，只能导入一次，不要截图留存或交给不受信任的人。接收端迁移成功后，发送端不应继续使用同一账号；需要两台设备长期使用时，请改用 OAuth 配对。
设计与实现
凭据流转
Codex 使用 ChatGPT 订阅登录并启用文件凭据模式后，当前登录会保存在 CODEX_HOME/auth.json，默认位置是 ~/.codex/auth.json。Codex Auth Switch 不修改 Codex 本身，只管理这份当前凭据，以及应用数据目录中的本机账号库。
需要说明的是，本机账号库目前依赖文件系统权限，而非加密存储 ：macOS/Linux 上应用数据目录权限为 0700，账号库和临时认证文件为 0600；系统钥匙串（Keychain/Credential Manager）模式暂不在支持范围内。也就是说，如果设备本身已经被其他高权限用户或恶意程序控制，文件权限无法提供额外保护------auth.json 和账号库都应当被当作与密码同等敏感的数据来对待。
一次账号切换可以拆成三个动作：先读取当前 auth.json，同步保存其中可能已经轮换过的凭据；再校验目标账号快照并写入同目录临时文件；最后通过原子替换更新 auth.json。Codex 下一次发起请求时读取新文件，切换便自然生效。API Key 登录始终走另一套路径，不会被保存成 ChatGPT 订阅账号。
关键路径可以简化为下面这段 Rust。重点不只是 rename，而是临时文件必须与目标文件位于同一目录 ，写完后先 sync_all，最后才替换正式文件：
rust
use std::{
fs,
io::{self, Write},
os::unix::fs::OpenOptionsExt,
path::Path,
};
fn atomic_write(path: &Path, contents: &[u8]) -> io::Result<()> {
let parent = path.parent().expect("auth.json must have a parent");
let name = path.file_name().unwrap().to_string_lossy();
let temporary = parent.join(format!(".{name}.{}.tmp", std::process::id()));
let mut file = fs::OpenOptions::new()
.write(true)
.create_new(true)
.mode(0o600)
.open(&temporary)?;
file.write_all(contents)?;
file.sync_all()?;
fs::rename(&temporary, path)
}这是 Unix 主路径的精简版本；实际实现还会给临时文件加入时间后缀、在失败时清理残留，并为 Windows 提供带备份与回滚的替换流程。这样即使写入中断，原来的 auth.json 仍然可以继续使用。
CAS3 的编码边界
CAS3 是 Codex Auth Switch 自己定义的一次性迁移兼容格式 ，不是 OpenAI 官方协议。文本形式是 CAS3: 加上 Base64URL(zlib(JSON))；二维码形式则使用 CAS3Q 前缀直接携带压缩后的字节。解压后的字段只有两个：
json
{
"d": "<id_token>",
"r": "<refresh_token>"
}其中 d 用于在接收端确认账号身份，r 用于立即刷新并重建完整的 Codex Auth。CAS3 不携带 access_token、account_id、本机账号名称或刷新时间；接收端只有在刷新成功、ID Token 校验通过且账号一致时，才会写入账号库和 auth.json。完整编解码逻辑可以在 auth_share.rs 中查看。
字段少并不意味着它可以公开：id_token 和 refresh_token 仍然属于认证材料，CAS3 内容必须像密码一样保护。格式版本与内部字段也可能随项目升级调整，不能把它当作稳定的第三方集成接口。
OAuth 配对与一次性迁移最终也会回到同一个本地文件，但过程不同。OAuth 由新设备发起 Device Code 流程，授权完成后在本机生成 Codex 可读取的登录缓存；CAS3 迁移只携带接收端兑换所需的数据，接收端必须先刷新令牌并校验账号一致性，全部成功后才写入账号库和 auth.json。
原始令牌的校验、迁移编解码、二维码和剪贴板处理都留在 Rust 后端，React 前端不会拿到可复制的令牌文本，错误信息和日志也不会输出令牌。项目没有自建后端、遥测或分析服务，但这并不等于设备失陷后仍然安全：auth.json 本质上仍是登录凭据，应当像密码一样保护。
扩展功能
最早写原型时，我以为核心工作只是把几份 auth.json 保存起来，再提供一个切换按钮。真正开始处理凭据轮换、OAuth 和换机迁移后才发现，文件替换反而是最简单的一步，难的是让每个失败分支都不会破坏用户当前还能使用的登录。
因此在 Rust 后端里，我给认证操作定了几条硬约束：
- 切换前先同步当前账号可能已经轮换的凭据，目标账号校验失败时不改动现有
auth.json； - 新文件必须先在同目录完整写入，再通过原子替换生效，避免中途退出留下半份凭据；
- OAuth 与 CAS3 保持为两条独立流程，迁移内容只有在刷新成功、账号一致性校验通过后才允许落盘；
- 原始令牌不进入 React 状态，也不能出现在日志或错误信息中。
我选择 Tauri，也不是为了给脚本简单套一个界面。账号切换需要直接处理本地文件权限，迁移又涉及剪贴板、二维码和系统文件选择器，这些操作放在 Rust 中更容易收紧边界；React 的职责则是把当前账号、下一步会发生什么、失败后是否保持原状说明白。
后面加入的 Token 用量、模型提供方归类、独立订阅额度页、邮箱私密模式、亮暗主题和应用内更新，本质上都是围绕日常使用补齐的信息。设置页还提供了一次只读的本地环境体检：由 Rust 检查配置、认证文件、权限、账号库、切换历史与原子写残留，前端只接收检查状态和计数，不接收令牌、账号 ID 或文件内容。
从开发者角度看，这个项目最重要的功能边界同样写在**"没有做"的部分**：不代理 Codex 请求，不读取提示词和回复，不把账号同步到云端，也不把 API Key 与 ChatGPT 订阅登录混在一起。认证工具的功能可以继续增加，但每增加一条数据流，都应该先解释它为什么必须存在。
写在最后
如果你也有多个 Codex ChatGPT 登录，希望 Codex Auth Switch 能帮你把手动备份和替换 auth.json 的过程收起来。账号切换应该足够顺手，但认证数据仍然值得被认真对待。
项目基于 Tauri + React + Rust 构建并完全开源，欢迎在 GitHub 上 Star、提 Issue 反馈问题，或者直接提交 PR 一起完善凭据管理和迁移流程。