Codex 多账号切换不再折腾：OAuth 配对与 Auth 迁移实践

最近我一直在测试各种 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，加入：

cli_auth_credentials_store = "file"

应用不会修改 keyring 或 auto 模式，也不会把 API Key 登录当作订阅账号。配置完成后，按照下面的顺序操作：

1. 保存当前账号：确认 Codex 已经通过 ChatGPT 订阅登录，打开 Codex Auth Switch，为当前登录设置名称并保存；
2. 添加其他账号：选择“OAuth 添加账号”，设置本机名称，再到可信浏览器中输入配对码并完成授权；
3. 日常切换账号：在本机账号库中选择目标账号，点击切换。Codex 下一次请求会读取新的 auth.json；
4. 查看本机用量：进入 Token 用量页，查看今天、近 7 天和近 30 天的本机会话统计；
5. 换机时迁移：只有旧设备准备停止使用该账号时，才生成一次性 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 迁移	把登录交给接收端，发送端随后停止使用

选择方式时，可以先判断账号准备在哪里使用：

flowchart LR
    Start(["选择账号使用方式"])
    SameDevice{"只在同一台电脑<br/>切换多个账号？"}
    LongTerm{"自己的另一台设备是否需要<br/>长期独立使用？"}
    ReplaceDevice{"是否属于换机，且旧设备<br/>准备停止使用该账号？"}

    Local["本机账号库<br/>适合日常切换"]
    OAuth["OAuth 配对<br/>适合长期添加设备"]
    CAS3["一次性 Auth 迁移<br/>只用于换机交接"]

    LocalSteps["① 保存并命名当前登录<br/>② 切换前同步最新凭据<br/>③ 从账号库一键切换"]
    OAuthSteps["① 新设备发起配对<br/>② 同一用户在浏览器授权<br/>③ 新设备独立保存登录"]
    CAS3Steps["① 停止发送端 Codex 会话<br/>② 刷新并生成一次性 CAS3<br/>③ 接收端导入并接管凭据"]

    Start --> SameDevice
    SameDevice -->|"是"| Local
    SameDevice -->|"否"| LongTerm
    LongTerm -->|"是"| OAuth
    LongTerm -->|"否"| ReplaceDevice
    ReplaceDevice -->|"是"| CAS3
    ReplaceDevice -->|"否，两端仍需使用"| OAuth

    Local --> LocalSteps
    OAuth --> OAuthSteps
    CAS3 --> CAS3Steps

    classDef start fill:#fff7ed,stroke:#f97316,stroke-width:3px,color:#7c2d12
    classDef decision fill:#fffbeb,stroke:#d97706,stroke-width:2px,color:#78350f
    classDef local fill:#eff6ff,stroke:#2563eb,stroke-width:3px,color:#1e3a8a
    classDef oauth fill:#f0fdf4,stroke:#16a34a,stroke-width:3px,color:#14532d
    classDef transfer fill:#fff1f2,stroke:#e11d48,stroke-width:3px,color:#881337
    classDef detail fill:#f8fafc,stroke:#94a3b8,stroke-width:1.5px,color:#334155

    class Start start
    class SameDevice,LongTerm,ReplaceDevice decision
    class Local local
    class OAuth oauth
    class CAS3 transfer
    class LocalSteps,OAuthSteps,CAS3Steps detail

    linkStyle 1,7 stroke:#2563eb,stroke-width:2px
    linkStyle 3,6,8 stroke:#16a34a,stroke-width:2px
    linkStyle 5,9 stroke:#e11d48,stroke-width:2px

单机切换账号

Codex Auth Switch 会识别当前 Codex ChatGPT 登录，并把账号快照保存在应用自己的本地账号库中。切换时，它会先保存当前账号可能已经轮换过的凭据，再校验目标账号，最后原子替换 CODEX_HOME 中的 auth.json。

整个切换过程不代理 Codex 请求。替换完成后，Codex 在下一次请求时读取新的本地凭据，账号切换就生效了。

应用也会读取 Codex 会话中的 token_count 元数据，汇总今天、近 7 天和近 30 天的本机 Token 用量。这里的 Token 数字只是本机会话统计，并不等于 ChatGPT 订阅额度；历史会话也不一定能准确归属到某个账号。

官方文档同样区分了 ChatGPT 订阅登录和 API Key 登录；Codex Auth Switch 只管理文件模式下的 ChatGPT 登录缓存，不会把 API Key 当作订阅账号保存。订阅窗口的展示来自兼容性实现，不能视为 OpenAI 承诺稳定的公开 API。

跨设备账号添加

如果想让另一台电脑长期使用某个账号，我更推荐 OAuth 配对，而不是把现有 Auth 发过去。

新设备在应用内发起登录后，会显示浏览器地址和短期有效的一次性验证码。同一用户在可信浏览器中登录 ChatGPT、输入验证码并完成授权，新设备随后自动保存并切换到新账号。这个过程不需要导出发送端已经存在的 Auth，也不需要把 ChatGPT 密码交给应用。

这套 Device Code 流程并不是 Codex Auth Switch 自创的协议，而是 Codex CLI 本身就在用的登录方式：当 CLI 运行在没有本地浏览器的环境（例如 SSH 远程服务器）时，同样会显示一个验证地址和一次性验证码，让用户在别处的浏览器完成授权。Codex Auth Switch 只是把这套 CLI 已经在用的登录能力，接入到桌面应用里，用来给同一账号添加新设备，而不是重新实现一套认证协议。

从实现上看，浏览器授权和应用轮询是同时发生的。前端只展示授权地址、一次性验证码和剩余时间；真正的状态查询、令牌交换、账号校验与写入都在 Rust 后端完成：

sequenceDiagram
    autonumber
    actor User as 用户
    participant App as Codex Auth Switch（新设备）
    participant Auth as OpenAI 认证服务（Codex CLI 同款接口）
    participant Browser as 可信浏览器
    participant Local as 本地账号库 / auth.json

    App->>Auth: 申请 Device Code
    Auth-->>App: device_auth_id、user_code、有效期、轮询间隔
    App-->>User: 显示授权地址与一次性验证码

    par 用户完成浏览器授权
        User->>Browser: 登录并输入一次性验证码
        Browser->>Auth: 确认授权
    and 应用等待授权结果
        loop 未授权且验证码未过期
            App->>Auth: 按 interval 查询状态
            Auth-->>App: pending
        end
    end

    Auth-->>App: authorization_code + code_verifier
    App->>Auth: 交换登录令牌
    Auth-->>App: 返回登录材料
    App->>App: 校验 ChatGPT 登录与账号一致性
    App->>Local: 保存账号并原子替换 auth.json
    App-->>User: 登录完成并切换

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，最后才替换正式文件：

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 仍然可以继续使用。

flowchart LR
    UI["React 前端<br/>脱敏账号摘要 / 聚合用量"]
    Core["Rust 后端<br/>校验凭据 / 原子替换 / 迁移处理"]
    Vault[("accounts.v1.json<br/>本机账号库")]
    Auth[("CODEX_HOME/auth.json<br/>当前登录凭据")]
    Codex["Codex<br/>CLI / Desktop / IDE"]
    OAuth["OAuth 配对<br/>授权结果"]
    CAS3["CAS3 一次性迁移<br/>刷新并校验"]

    UI <-->|"Tauri 命令 / 脱敏结果"| Core
    OAuth --> Core
    CAS3 --> Core
    Core <-->|"保存账号快照"| Vault
    Core <-->|"同目录原子替换"| Auth
    Auth -->|"下一次请求读取"| Codex

    classDef ui fill:#fff7ed,stroke:#f97316,stroke-width:2px,color:#7c2d12
    classDef core fill:#eff6ff,stroke:#2563eb,stroke-width:2px,color:#1e3a8a
    classDef storage fill:#f8fafc,stroke:#64748b,stroke-width:2px,color:#334155
    classDef flow fill:#f0fdf4,stroke:#16a34a,stroke-width:2px,color:#14532d

    class UI ui
    class Core core
    class Vault,Auth storage
    class OAuth,CAS3,Codex flow

CAS3 的编码边界

CAS3 是 Codex Auth Switch 自己定义的一次性迁移兼容格式，不是 OpenAI 官方协议。文本形式是 CAS3: 加上 Base64URL(zlib(JSON))；二维码形式则使用 CAS3Q 前缀直接携带压缩后的字节。解压后的字段只有两个：

{
  "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 用量、邮箱私密模式、亮暗主题和应用内更新，本质上都是围绕日常使用补齐的信息。它们可以帮助我确认“现在是谁在用、最近用了多少、更新来自哪里”，但不会改变认证数据只留在本机的前提。

从开发者角度看，这个项目最重要的功能边界同样写在“没有做”的部分：不代理 Codex 请求，不读取提示词和回复，不把账号同步到云端，也不把 API Key 与 ChatGPT 订阅登录混在一起。认证工具的功能可以继续增加，但每增加一条数据流，都应该先解释它为什么必须存在。

END

如果你也有多个 Codex ChatGPT 登录，希望 Codex Auth Switch 能帮你把手动备份和替换 auth.json 的过程收起来。账号切换应该足够顺手，但认证数据仍然值得被认真对待。

项目基于 Tauri + React + Rust 构建并完全开源，欢迎在 GitHub 上 Star、提 Issue 反馈问题，或者直接提交 PR 一起完善凭据管理和迁移流程。

---

若对文章很感兴趣，可以B站关注我ヾ(≧▽≦*)o

点此跳转“爱发电”页面(○｀ 3′○)