Codex 只认一个账号时，浏览器登录态怎么组织
多个 ChatGPT 账号同时存在时，真正麻烦的是登录态放在哪里。
ChatGPT Web 已经有账号切换器，可以在同一个浏览器会话里保留两个账号；但 ChatGPT 桌面 App 里的 Codex Tab 仍然只有一个当前账号。额度用完后想切到另一个账号，就要退出 App 当前账号，再走一次「Sign in with ChatGPT」的浏览器认证流程。
如果只是每周低频切一两次账号，目标应该很克制：让浏览器提前保留各个账号的登录态，切换时少输密码、少碰验证码，同时不复制 token、不替换 auth.json，也不把登录凭据交给不必要的第三方扩展。
先拆清楚三个登录态
OpenAI 帮助中心把 ChatGPT Web 的账号切换边界写得很明确：账号切换器目前可用于 ChatGPT Web，不支持 Codex desktop 和原生 ChatGPT 手机 App；同一个 Web session 里最多可以保留两个账号。
Codex 的登录机制是另一条链路。Codex Authentication 说明，从 ChatGPT 桌面 App、Codex CLI 或 IDE extension 使用 ChatGPT 登录时，会打开浏览器完成登录，登录后浏览器把凭据返回 Codex。Codex 之后会缓存登录信息，并在使用中刷新 token，正常情况下不需要每次重新走浏览器登录。
这就形成了三层状态：
| 位置 | 能保存什么 | 关键限制 |
|---|---|---|
| ChatGPT Web | 同一浏览器 session 里最多两个 ChatGPT 账号 | 只覆盖 Web，不等于 Codex Tab 同时登录多个账号 |
| Codex Tab | 当前 App 使用的一个 ChatGPT 账号 | 切账号要退出当前账号，再走浏览器认证 |
| 浏览器数据目录 | chatgpt.com 的 Cookie、local storage、已登录状态 |
每个数据目录天然是一套独立浏览器环境 |
浏览器里已经登录目标账号时，Codex 触发的认证流程通常会短很多。但这不代表一定不会验证。OpenAI 登录验证说明提到，新设备、异常位置、敏感操作或安全检查都可能触发额外验证；MFA 文档也说明，开启 MFA 后，登录时可能被要求使用已启用的验证方式。
所以判断口径应该是：浏览器登录态能减少重复登录，不能绕过 OpenAI 的安全验证。验证码是否出现，由账号、设备、位置、MFA 和安全策略共同决定，不是 Codex Tab 每次强制要求。
Edge Profile 为什么用起来重
Microsoft Edge 自带多个 Profile。它可以解决多账号登录态隔离问题，但对这个场景有点重。
Microsoft Edge 的 Profile 文档说明，不同 Profile 会分开浏览器设置、书签、扩展、主题和偏好。这个设计适合长期区分工作和个人浏览环境；如果目的只是「给 Codex 认证时提供一个 ChatGPT 登录态」，切 Profile 会把整套浏览体验一起切走。
Edge Profile 也可以只做本地隔离，不登录 Microsoft 账号。日常使用时，用户仍然要在头像菜单、窗口和默认外部链接 Profile 之间来回确认；切一次账号只为完成一个 OAuth 登录，操作成本会显得很别扭。
更贴近需求的做法，是不用 Edge 的 Profile UI，而是直接给 Edge 指定几个专用数据目录。
用 --user-data-dir 做专用认证窗口
Chromium 支持用 --user-data-dir 指定浏览器数据目录。Chromium 的 Profiles 文档把这个模式描述成：创建一个目录保存新 profile 数据，再用带 --user-data-dir 的快捷方式启动浏览器；如果目录为空，浏览器会自动初始化数据。Microsoft Edge 的 UserDataDir 策略文档也说明，未配置策略时，用户可以通过 --user-data-dir 覆盖默认 profile path。
这和 Edge 右上角的 Profile UI 不是一回事。它更像给同一个 Edge 程序准备几个独立小房间：
%LOCALAPPDATA%\OpenAIAuth\A
%LOCALAPPDATA%\OpenAIAuth\B
%LOCALAPPDATA%\OpenAIAuth\C每个目录都会保存自己的 Cookie、历史、扩展、书签和站点存储。因为这些窗口只服务 ChatGPT 认证，书签和扩展空着也没关系。
Windows PowerShell 里可以这样启动第一个专用窗口：
$authRoot = Join-Path $env:LOCALAPPDATA 'OpenAIAuth\A'
msedge "--user-data-dir=$authRoot" --no-first-run --new-window https://chatgpt.com第二个和第三个账号只改目录名：
$authRoot = Join-Path $env:LOCALAPPDATA 'OpenAIAuth\B'
msedge "--user-data-dir=$authRoot" --no-first-run --new-window https://chatgpt.com$authRoot = Join-Path $env:LOCALAPPDATA 'OpenAIAuth\C'
msedge "--user-data-dir=$authRoot" --no-first-run --new-window https://chatgpt.com第一次打开时，分别登录 ChatGPT 账号 A、B、C。后面这些目录会保留自己的登录态。也可以把命令做成三个桌面快捷方式，例如「OpenAI Auth A」「OpenAI Auth B」「OpenAI Auth C」，平时只在需要切 Codex 账号时打开。
如果 msedge 命令不可用，快捷方式的目标可以写成完整路径：
"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --user-data-dir="%LOCALAPPDATA%\OpenAIAuth\A" --no-first-run --new-window https://chatgpt.com低频切换时怎么操作
日常 Edge 继续按原来的方式使用，专用认证窗口只保存 ChatGPT 登录态。
切换 Codex 账号时按这个顺序来：
- 在 ChatGPT 桌面 App 的 Codex Tab 里退出当前账号。
- 点击
Sign in with ChatGPT。 - App 会用默认浏览器打开认证 URL。
- 立刻复制当前打开的认证 URL。
- 打开对应账号的专用认证窗口，例如
OpenAI Auth B。 - 把认证 URL 粘进去，在这个窗口里完成登录确认。
- 浏览器回跳后，Codex Tab 会拿到对应账号的凭据。
这个流程的关键，是认证仍然发生在同一台机器、同一个 OpenAI 官方登录流程里。复制的是一次性的认证 URL，不是长期 token；浏览器最后回跳给 Codex，Codex 自己缓存当前账号。
认证 URL 仍然要当敏感信息处理。它通常带有一次性状态参数，应该只在自己机器上的浏览器之间复制，不要发到聊天、工单、笔记或截图里。
也不要手动复制或轮换 Codex 的 auth.json。Codex Authentication 说明，Codex 可能把凭据缓存在 ~/.codex/auth.json 或系统凭据库里，并明确提醒 auth.json 含有 access tokens，要像密码一样保护。为了每周切一两次账号去保存和替换这些文件，风险和收益不成比例。
第三方多会话扩展不是首选
能解决「同一个网站多个登录态」的第三方工具确实存在，比如 SessionBox、SessionHub 和一些 Cookie Profile 类扩展。它们的共同目标，是让同一个浏览器里出现多份隔离 session。
这类工具适合测试普通 Web 系统的多账号场景，但不太适合承载 ChatGPT / Codex 登录态。
原因很简单：多会话扩展要管理登录态，就会接触 Cookie、站点存储或隔离容器。Chrome Extensions cookies API 允许具备权限的扩展读取、设置、删除指定站点的 Cookie，也能枚举 cookie stores。这个能力很强，意味着扩展的可信边界会直接进入账号安全边界。
对普通测试账号来说，这可能只是工具便利性问题；对 ChatGPT 和 Codex 来说，Cookie、OAuth 状态和本地凭据都和真实账号、账单、聊天记录、工作区权限、代码仓库访问相关。除非非常信任扩展来源、权限范围和数据处理方式，否则不应该把它放在首选方案里。
更稳的顺序是：
- 先用浏览器自己的数据目录隔离登录态。
- 再考虑独立浏览器，例如 Chrome、Firefox 或 Edge Beta / Dev。
- 最后才考虑多会话扩展，并且只给最小权限。
要不要装 Chrome 或 Firefox
装 Chrome 可以把登录态从日常 Edge 里分出去，但它解决的是「多一个浏览器容器」，不是「一个浏览器账号里有多个 ChatGPT 登录态」。如果只有两个账号，Edge 一个、Chrome 一个，确实很简单；如果有三个账号，Chrome 里仍然会回到 Profile 或 --user-data-dir 的问题。
Firefox 的 Multi-Account Containers 更接近「同一个浏览器 Profile 里多个登录态」。它会按容器隔离 Cookie，Web 日常多账号体验很好。问题在 Codex 登录流程上：外部 App 打开的 OAuth URL 未必能自动进入指定容器，所以最后仍然可能需要手动复制 URL。
Edge Beta、Dev、Canary 也可以和 Stable 并排安装。它们天然有独立数据目录，图标和任务栏也更容易区分。但为了三份 ChatGPT 登录态去装三个浏览器版本，维护成本未必比 --user-data-dir 更低。
低频切换时，专用数据目录已经够用。它不依赖扩展，不改变日常浏览器 Profile，也不需要装新浏览器。
安全边界要写在流程里
这里还有一条容易被忽略的边界：账号额度不足和登录态隔离是两件事。
如果只是本人持有多个付费账号，低频手动切换，浏览器登录态隔离可以减少重复登录成本。它应该保持手动、可见、低频，并且尊重 OpenAI 登录验证。只要系统要求 MFA，就正常完成验证。
如果把这个流程做成自动轮换账号、自动复制凭据、自动替换 token 或规避系统限制，就进入了完全不同的风险区间。OpenAI Terms of Use明确禁止绕过 rate limits、restrictions、protective measures 或 safety mitigations。工具设计上应该避开这条线。
所以这套方案只做三件事：
- 浏览器提前保存本人账号的登录态。
- Codex 切账号时手动选择用哪份登录态完成官方认证。
- 敏感凭据继续由 Codex 和浏览器自己管理。
它不做自动登录，不保存验证码，不读取 Cookie，不复制 auth.json，也不把认证状态交给第三方扩展。
手动、可见、低频
- ChatGPT Web 的账号切换器只解决 Web 侧问题，不代表 Codex Tab 可以同时登录多个账号。
- Codex 登录会走浏览器认证；浏览器已有登录态时，流程通常更短，但额外验证仍可能出现。
- Edge Profile 能隔离登录态，但会一起隔离书签、扩展和整套浏览器体验；如果只为 Codex 认证，它有点重。
--user-data-dir可以把同一个 Edge 程序拆成几个专用认证窗口，每个窗口只保存一个 ChatGPT 账号的登录态。- 第三方多会话扩展能做类似事情，但它们会进入 Cookie / session 安全边界，处理 ChatGPT 和 Codex 账号时不适合作为首选。
- 一周切一两次账号时，手动复制认证 URL 到专用认证窗口，是一个足够省事、也足够克制的折中。