opencodex Provider Workspace 账户体系 A 门审计：从账户切换器到多账号状态治理的源码级复盘

【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载导读本文基于 opencodex 仓库 devlog 单元 260718_provider_workspace_accounts_rail 中的 A 门审计文档 011_account_audit.md完整复盘该仓库将 Provider 工作区#providers/workspace改造成账户切换一等公民的过程如何从既有WorkspaceItem、isAccountProvider、authMode、hasApiKey等字段无侵入地推导出认证表面如何在并发刷新与失败网络下保住状态权威性以及审计阶段发现并折叠的四个新增阻塞项。读完本文你将掌握 opencodex 前端账户体系的认证表面判定规则、安全标签masked email/序数回退机制、代码级的状态提交策略以及一套可复用的审计 → 修订 → 验证闭环方法。1. 审计背景与输入一条可独立复现的基线1.1 前置探索结论在正式 A 门之前一条roadmap 前账户探索链独立追踪了完整链路列表list→ 活动 IDactive id→ PUT 切换 → 持久化 → 运行时凭证选择最终返回VERDICT: READY同时给出九条具体的风险/激活发现详见 003_audit_synthesis.md。1.2 新鲜基线命令本阶段 A 的基线测试命令与结果来自 011_account_audit.mdbun test --isolate tests/oauth-accounts-api.test.ts tests/oauth-store-multi.test.ts tests/oauth-public-surface.test.ts tests/codex-auth-api.test.ts tests/provider-workspace-data.test.ts tests/provider-workspace-state.test.ts 118 pass / 0 fail / 398 assertions注意后续账户切片实现后聚焦套件提升至126 pass / 0 fail / 422 assertions见 010_account_switcher.md C 验证收据整合收尾后聚焦套件进一步达到133 pass / 0 fail / 462 assertions见 030_integration_qa.md。1.3 评审委派的真实性记录两个账户专项评审 agent 在各自三次有界等待后均未产出结果而被退役这是同一数据包第二次派发失败。按 000_plan.md 的升级规则主 agent 在两个不同 worker 失败后回收数据包主 agent 回收审计权并完成了本合成。这种失败被记录而非隐藏的做法是仓库审计纪律的一部分C 阶段仍要求全新的实现评审。2. 可行性审计十个判定点011_account_audit.md 对账户切片逐一做了可行性论证ProviderAuthSurface可从既有字段推导——WorkspaceItem、isAccountProvider、isLocalProvider、authMode、hasApiKey、keyOptional均已存在无需发明服务端字段。渲染局部编排——通用按 provider 生成状态是Providers.tsx的渲染局部编排功能性合并可修复当前子集擦除缺陷无需全局 store。切换失败可达——非 2xx 与 rejected fetch 都能触发计划保留旧状态并增加finally恢复。Codex 假成功直接可达——setActive当前忽略res.ok计划只在ok后消费响应并做权威刷新。规范 vs 自定义 forward 判定——必须用isAccountProvider不能用authMode forward。needsReauth已存在于两个 DTO——阻塞变更并暴露恢复路径可达。加载/空/一/多状态——从延迟/失败/真实响应可达Anthropic 有两条真实活跃行、Codex 有四条提供了真实的多账户证明。键盘漫游焦点——现有 React tab 按钮可实现无需依赖浏览器 QA 必须做因为仓库没有 DOM 测试夹具且新增依赖被禁止。无身份单槽 provider 保持诚实——暴露当前返回行但不被描述为池。范围适配一个工作相位——服务端路由/存储不变所有源修改都留在既有 GUI 属主链加一个纯分类器内。3. 主审计追加折叠的四个阻塞项除十个判定点外主审计在 011_account_audit.md 中又发现四个可复现问题并折叠进计划3.1 跨 provider 的陈旧 tab 状态ProviderDetails复用未带 key。修订按 provider 名加 key使 tab/设置状态无法跨 provider 身份串扰。实现后工作区详情按 provider 名重挂载对应 010_account_switcher.md B 收据。3.2 OAuth/账户状态自相矛盾独立请求可能返回陈旧的loggedInfalse覆盖真实活跃行。修订非空权威账户行确立面板的登录摘要两路请求不得在活跃行上方渲染矛盾的未登录。3.3 通用 raw-id 反馈泄漏Providers.tsx文档标注:131,200-203在可见通知/确认中使用了email ?? id。修订所有工作区反馈路径统一走 shared masked-email/ordinal 标签。3.4 Codex raw-id 确认泄漏CodexAccountPool.tsx文档标注:78,85-88可能把 id 放进标签/确认文案。修订只使用 masked email 或 main-account 文案。这四个折叠项与仓库实际落地的安全标签工具相互印证oauthAccountDisplayLabel优先返回 alias → masked email → 本地化序数绝不回退到不透明存储 id见 auth.ts。4. 残余项与主审计结论4.1 记录的残余Codex 池密度完整内嵌 Codex 池仍比通用 OAuth 行列表稠密但不阻塞功能密度修复若进行需留在CodexAccountPool/工作区样式内并先作为 B 偏差补充对应 020_provider_rail.md 的 rail 精修相位。删除后焦点恢复本切片不重新设计账户删除焦点恢复保留现有确认新增可访问标签最终键盘 QA 必须确认非破坏性账户切换后焦点不丢失。4.2 判定所有可达的认证选择阻塞项现在都有精确属主与激活证据不需要后端契约或凭证存储变更。正式评审交付失败被如实记录最终 C/D 仍要求全新实现评审。VERDICT: GO-WITH-FIXES (blockers0)5. 落地对照认证表面的源码级实现本小节以当前仓库源码佐证审计判定帮助读者把审计说了什么映射为代码实际是什么。5.1 纯分类器providerAuthSurfacegui/src/provider-workspace/auth.ts 定义了判定函数export type ProviderAuthSurface codex-accounts | oauth-accounts | api-keys | null; export function providerAuthSurface(item: WorkspaceItem): ProviderAuthSurface { if (isAccountProvider(item.name, item)) return codex-accounts; const mode (item.authMode ?? ).toLowerCase(); if (mode forward || mode local || isLocalProvider(item)) return null; if (mode oauth) return oauth-accounts; const hasKeyMaterial item.hasApiKey true; const keyAuth mode key || hasKeyMaterial || mode ; if (!keyAuth || (item.keyOptional true !hasKeyMaterial)) return null; return api-keys; }规则解读规范 OpenAI forward →codex-accounts只有isAccountProvider为真才拥有 Codex 池。isAccountProvider在 catalog.ts 中定义为名称等于规范 forward provider 且形状为规范 forward 形状name CANONICAL_FORWARD_PROVIDER isCanonicalForwardShape(p)这正是审计点 5必须用isAccountProvider而非authMode forward的实现。自定义 forward / local →null绝不把全局 Codex 池继承给看起来像 forward的自定义代理也绝不给无认证 provider 一个死 tab。oauth→oauth-accounts通用 OAuth 多账户。key 形态 →api-keysmode key、已有 key 材料、或模式为空且非 keyOptional 时映射到 API keyskeyOptional且无 key 材料时返回null。5.2 安全标签回退oauthAccountDisplayLabel同一文件中的安全标签工具实现export function oauthAccountDisplayLabelT extends OAuthAccountIdentity( accounts: readonly T[], account: OAuthAccountIdentity, t: TFn, ): string { const alias account.alias?.trim(); if (alias) return alias; const email account.email?.trim(); if (email) return email; const index accounts.findIndex(candidate candidate.id account.id); return t(pws.accountOrdinal, { count: String(index 0 ? index 1 : 1) }); }优先级为alias → masked email → 本地化序数如Account 2/계정 2绝不暴露存储 id。这正是审计折叠项 3/4raw-id 泄漏的收敛方案。5.3 测试契约测试文件 直接验证了上述两个工具只有规范 OpenAI forwardopenai-responseschatgpt.com/backend-api/codexbaseUrl得到codex-accounts改名为custom-forward或改 baseUrl 即为null。anthropicoauth→oauth-accountspaidkey/configuredhasApiKey: true→api-keysfreekeyOptional: true无 key与ollamalocal→null。标签masked email 原样使用alias 优先无 email 时输出Account 2且断言不含opaque-second未知行 fail-closed 到Account 1。该测试与 010_account_switcher.md 的RED → GREEN8 pass / 0 fail收据一致属于先写契约测试、再生产代码的路径。6. 服务端契约不变化的后端证据审计判定不需要后端契约变更可在当前仓库源码中验证通用 OAuth 账户列表GET /api/oauth/accounts?providerP返回{ activeAccountId, accounts[] }且注释明确Emails are masked; tokens never leave the store见 oauth-account-routes.ts。通用切换PUT /api/oauth/accounts/active校验 provider 与accountId调用setActiveAccount写凭证存储锁内账户集见 src/oauth/store.ts随后清空模型缓存与配额缓存clearModelCache/clearProviderQuotaCache。Codex 侧GET /api/codex-auth/accounts与GET/PUT /api/codex-auth/active承载 canonical Codex 池见 src/codex/auth-api.ts。从源码结构看前端工作区的改造ProviderAuthSurface纯分类器、Providers.tsx状态提交、ProviderAuthPanel/CodexAccountPool失败诚实化完全是 GUI 侧行为与凭证/路由契约解耦——这正是审计点 10 与最终判定仅 GUI 属主链 一个纯分类器的直接证据。7. 后续相位承接与总账A 门审计不是终点它把结论交棒给两个实现相位与一个集成相位010_account_switcher.md账户切换器实现含激活矩阵loading / empty / one / many / reauth / HTTP failure / network failure / stale GET / custom forward / provider change / status race / safe fallback / keyboard tabs / live switch与验证命令。020_provider_rail.mdrail 两行语义行 容器查询响应式修复。030_integration_qa.md整合对抗 QA 与收尾含#providers/workspace深链保持、同步重复切换防护、POST-PUT 刷新诚实性、显式 Codex 键盘切换按钮、诚实登出刷新、可见 DELETE 失败处理、单入口 rail 焦点模型等八项残余修复。整体设计意图来自 000_plan.md 与 001_design_read.md始终一致账户身份成为一等工作区 tabrail 每一行读作一个连贯状态对象活跃状态由服务端权威失败的切换不改变选中行任何可见表面不出现 raw id/全邮箱/不透明账户 id。A 门审计以GO-WITH-FIXES (blockers0)收敛为后续 B/C 的实现与验收提供了精确、可复现的靶心。赞分享【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载相关推荐OpenCodex 工作区账户体系与 Provider Rail 设计规范从多账户切换到语义化响应式布局OpenCodex 工作区账户体系与 Provider Rail 设计规范从多账户切换到语义化响应式布局 导读 本文基于 opencodex 仓库中 devlopencodex Providers Workspace 集成 QA账户切换、Provider Rail 与对抗性验收收尾实战opencodex Providers Workspace 集成 QA账户切换、Provider Rail 与对抗性验收收尾实战 本指南基于 opencode告别账号切换烦恼PrismLauncher多账户管理全攻略告别账号切换烦恼PrismLauncher多账户管理全攻略 你是否还在为管理多个Minecraft账号而频繁登录登出是否在切换不同账号时需要重启启动器Pr桌面应用上一篇JNativeHook测试策略单元测试与集成测试完整指南下一篇GitHub Pages URL Shortener 使用教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考