【免费下载链接】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/_fin/260718_provider_workspace_accounts_rail/单元的基线证据文档为主体完整梳理 GUI 中Providers 工作区#providers/workspace在账户管理与左侧导航rail两个维度的现状包括用户可见的界面故障、真实的多账户库存、底层 OAuth/Codex 账户契约、11 项基线缺陷及其激活场景以及对应的修复切片账户切换器、rail 层级与响应式、集成 QA与验证证据。读完本文你将掌握该工作区的账户状态机缺陷图谱、底层 API 契约形态以及先修账户一致性、再修 rail 布局、最后集成回归的依赖有序改造路径。背景工作区拥有选择权却隐藏了账户能力OpenCodex 的 Provider 工作区承担着 provider 选择的核心职责但基线审计发现工作区拥有 provider 选择权却把已经存在的账户管理能力藏在 Settings 中同时左侧 rail 在受限宽度下会退化为原始碎片或发生碰撞。这是本次改造000_plan.md中定义为 spec-satisfaction repair with two dependency-ordered product slices的触发点。改造目标有二把安全的多账户选择提升为一等公民的 workspace 详情 Tab把 provider rail 改造成紧凑、语义化、无碰撞的导航面。明确排除的非目标包括新认证协议、账户删除重设计、自动配额路由策略变更、provider 目录重设计、品牌资产替换、新依赖、部署与远程推送。一、用户可见故障基线基线证据002_baseline_evidence.md首先记录了改造前真实可见的用户侧问题窄 rail 裁剪下的垂直堆叠用户截图显示状态文本与 trail 控件在窄 rail 裁剪中发生垂直堆叠——这正是后续 rail 改造要消灭的 字符竖排 现象。头部控件争抢宽度rail 头部与添加/搜索控件争抢宽度分割边界主导了整体构图。当前源码渲染对比在http://127.0.0.1:10100/#providers/workspace的本地渲染中桌面端源码渲染虽比早期截图有改进但 rail 仍然重复了页面标题/动作并且把 provider 的名称、badge、模型数、星标、状态、chevron拆成了六个水平 flex 片段。Kimi 详情基线详情仅有 Overview / Models / Usage / Settings即使本地 OAuth 账户端点报告有一个活跃 Kimi 账户Authentication 仍显示 Not logged in。根因是工作区遗漏了 workspace props 的传递而不是后端数据缺失。这四条基线共同指向两个根因工作区没有把账户数据接线到详情面板以及rail 行的水平信息架构缺乏收缩优先级。二、真实多账户库存激活场景的活数据为避免只用 fixture 伪造 UI基线通过只读计数探针采集了本地真实账户库存有意省略 ID 与邮箱anthropic count2 active1 reauth0 xai count1 active1 reauth0 kimi count1 active1 reauth0 cursor count1 active1 reauth0 google-antigravity count1 active1 reauth0 openai-codex count4 main1 reauth0 openai-active presenttrue autoSwitchThreshold0这份库存提供了真实的多账户激活场景Anthropic2 个账户与openai-codex4 个账户、1 个 main直接支撑 many 分支的活体验证Kimi 这类单槽、无稳定账户身份的 provider 暴露了另一个边界它们不应因为通用端点返回一行就被描述为多账户池。三、账户契约证据路由、存储与持久化基线文档给出了账户管理契约的四个锚点这些都能在当前仓库源码中得到印证3.1 通用 OAuth 账户列表GET /api/oauth/accounts?providerP - { activeAccountId, accounts[] }返回带掩码的账户摘要activeAccountId 账户数组对应管理 API 中 oauth-account-routes 的多账户管理路由实现读取 provider 的账户集合后把每个账户映射为summary不含凭据原文并输出activeAccountId。3.2 通用账户切换PUT /api/oauth/accounts/active - 校验后的账户选择 配额缓存清理切换路由位于 oauth-account-routes成功返回{ ok: true, provider, activeAccountId }供前端消费返回值做权威刷新。3.3 持久化setActiveAccount在既有 store 锁下写入 provider 账户集合。在 oauth/store.ts 的实现中切换会更新set.activeAccountId与selectionRevision并为后续的并发检查expected.accountId/selectionRevision见同文件 L982 附近提供依据——这正是 stale-response 防护的底层机制。3.4 Codex 专属契约GET /api/codex-auth/accounts GET/PUT /api/codex-auth/active对应gui/src/components/CodexAccountPool.tsx与src/codex/auth-api.ts。Codex 的账户池比通用 OAuth 更复杂包含 main 账户 pool 账户且有30 秒轮询刷新。3.5 线程亲和性边界一个重要的既有约束Codex 的 active 选择只作用于新路由线程亲和性thread affinity可能让已存在的线程停留在其早期账户上src/codex/routing.tsL341 之后。这是设计边界而非缺陷改造必须保持这一语义。四、十一项基线缺陷与激活场景基线文档把缺陷按可复现的激活场景编号列出是本次改造的验收清单雏形#缺陷激活场景1Workspace 接线缺失Providers.tsx只提供oauthEmail而ProviderDetails已接受被省略的账户 props泛 OAuth 提供商在 Settings 中看不到账户面板2通用加载状态失真{}同时代表未加载/加载失败/加载后为空激活是失败或延迟的账户 GET3通用陈旧响应账户拉取直接整体替换 map无 generation 归属旧 GET - 切换 - 新 GET - 旧 GET 解析顺序颠倒4通用网络失败缺口switchAccount缺少try/catch激活是 rejected fetch产生未处理的 rejection5Reauth 可切换通用行在needsReauth: true时仍可切换激活是非活跃行上的 needsReauth6Codex 假成功setActive忽略res.ok并直接改本地状态激活是 400/500 的 active PUTUI 却显示成功7Codex 轮询重叠30 秒轮询与用户刷新无 generation 排序重叠加载乱序解析旧结果覆盖新结果8认证面归属每个authModeforward都嵌入 Codex 池激活是非规范 OpenAI 的自定义 forward provider9Tab 语义缺失现有 Tab 缺 controls/panels/箭头导航激活是纯键盘导航10Rail 语义缺失listbox 容器与每个 option 都是 Tab stop激活是键盘遍历 rail 时出现双重焦点停留11CSS 漂移provider workspace 使用了未定义的--fg/--fg-muted激活是任一主题下的 active filter/tab 状态这 11 项中第 1 项是入口缺陷ProviderDetails早已接受oauth、accounts、keys等 props 与处理器见 ProviderDetails.tsx 的签名但调用方 Providers.tsx 只传了oauthEmail——账户面板实现了却未被接线。审计文档003_audit_synthesis.md将其列为第一阻断项并在010_account_switcher.md中以精确 diff 的方式闭环。五、既有聚焦证据独立探索器的验证基线改造前已经有两组独立只读探索结果为基线背书独立账户契约探索器118 个相关 API/store/workspace 测试全部通过0 失败独立设计系统探索器57 个 catalog/state/payload 测试全部通过0 失败。同时基线明确了一条必须区分对待的 lint 债ProviderOverview.tsx报告react-hooks/set-state-in-effect该错误属于改造前就存在的基线债——实现不得掩盖它收尾时要把基线 lint 债与新引入的失败分开报告。六、浏览器基线观察viewport 请求宽度 ≠ 有效 CSS 宽度浏览器基线记录了三个关键事实默认桌面端现有 rail 可读但水平过度指定over-specifiedworkspace 详情没有账户 Tab。1024 请求宽度源码仍渲染完整的三栏app/rail/detail组合详情内容被明显压缩页面动作逼近 viewport 边缘。768 请求宽度陷阱应用内能力检测到请求 768 时实际有效 CSS 宽度为 960px——请求宽度与有效宽度不一致。因此最终证据必须同时记录 requested 与 effective 两种宽度并补充一个真正跨越760px CSS 边界的宽度采样。这条观察直接决定了后续 rail 改造的验证矩阵不能只按请求宽度断言必须以documentElement.clientWidth的实际测量为准020_provider_rail.md的最终矩阵中1440→1800、819→1024、768→960、312→390、256→320 的成对记录正是这一规则的结果。基线还保证基线采集过程中未发生任何破坏性账户变更。七、从缺陷到修复两条依赖有序的切片基线证据是改造的问题清单而本单元后续文档给出了闭环方案。结合000_plan.md的架构图改造前的组件责任链是gui/src/pages/Providers.tsx 拥有 config、oauth 状态、通用账户集合、key 池、变更操作 - ProviderWorkspaceShell.tsx拥有 rail 过滤/选择与详情槽 - ProviderRail.tsx - ProviderDetails.tsx - Overview / Models / Usage / Settings - ProviderAuthPanel.tsx已实现但未被工作区接线 - CodexAccountPool.tsx规范 OpenAI forward provider src/server/management-api.ts GET/PUT/DELETE /api/oauth/accounts* src/codex/auth-api.ts GET/PUT /api/codex-auth/accounts|active修复按依赖顺序分三个相位切片一账户切换器010_account_switcher.md先修账户状态一致性再把新 Tab 与既有账户面接线新增纯分类器 gui/src/provider-workspace/auth.tsproviderAuthSurface(item)复用isAccountProvider与isLocalProvider返回codex-accounts | oauth-accounts | api-keys | null。关键规则是规范 OpenAI forward 映射到 codex-accounts非规范 forward 映射到 null——自定义 forward 代理绝不能因为同用 forward 认证就继承全局 Codex 账户池缺陷 #8 的闭环。同一文件提供安全账户标签oauthAccountDisplayLabel返回已有掩码邮箱、alias或基于位置的本地化序号如계정 2/Account 2绝不回退到不透明账户 ID。通用账户读取改为按 provider 的 generation 约束提交 函数式 map 合并子集刷新不再抹掉其他 provider缺陷 #2/#3检查response.ok、try/catch/finally包裹切换、拒绝needsReauth行、成功后才刷新该 provider 的账户集/OAuth 状态/配额缺陷 #4/#5CodexAccountPool增加初载/刷新加载状态、请求 generation、切换 idPUT 后消费返回的 active id 并做权威刷新失败保留旧 active缺陷 #6/#7ProviderDetails用key{item.name}在 provider 切换时重挂载避免跨 provider 残留失效的 Accounts Tab审计补充项Tab 实现 WAI-ARIA 语义tablist/tab/tabpanel、aria-controls、aria-labelledby、rovingtabIndex、ArrowLeft/Right/Home/End 激活缺陷 #9。切片二provider rail 层级与响应式020_provider_rail.md账户切片稳定后再修 rail行结构从六个水平 peer 收敛为icon copy trail三段主行放显示名与 Free/Local 例外 badge次行放模型数与仅冲突时出现的config id状态文本留在分组标题与本地化按钮 name/title8px 状态点保持空且aria-hidden缺陷 #10/#11 及历史 raw-text 泄漏防线删除 rail 本地重复的 Providers / Add provider 标题与按钮——页面头部已拥有listbox 不再作为额外 Tab stoproleoption的原生按钮独占焦点ArrowUp/Down/Home/End 由 listbox 的冒泡 key 事件处理用命名容器 shell 局部容器查询替换纯 viewport 断点有效工作区宽度低于约 640px280px rail gap 320px 可用详情时堆叠 rail/detailmin-width:0、ellipsis、white-space:nowrap杜绝字符竖排未定义的--fg/--fg-muted替换为既有语义 token--text/--muted原色 provider SVG 继续走providerIconSrc-img路径不做 workspace 色调 mask。切片三集成 QA 与收尾030_integration_qa.md集成阶段又发现并修复了一个路由层缺陷加载/刷新#providers/workspace会立即变成#providers——readPageFromHash()正确接受子视图后缀但页面同步 effect 拿完整 hash 与#providers比较挂载时把合法子视图覆盖掉。修复方式是只白名单精确的providers/workspace子路由直达/刷新保留 workspace#providers/typo归一化到#providers。同时补齐了通用注销与删除的失败诚实性、rail 的单一 roving Tab 入口focused/selected/first visible选一其余-1。八、验证证据自动化门禁与活体浏览器 QA自动化门禁最终收据聚焦集成套件8 个文件 133 pass / 0 fail / 462 assertions GUI 生产构建 TypeScript PASS 聚焦 ESLintApp/Providers/Codex pool/shell/rail 0 errors / 0 warnings privacy scan / git diff --check PASSlint:i18n 的唯一阻塞项是改造前已记录的ProviderOverview.tsx:152 react-hooks/set-state-in-effect基线债与本次切片无关。活体浏览器 QA关键结论Anthropic渲染 5 个关联 Tab 与 2 个掩码账户行恰好一个可聚焦的aria-current行ArrowRight 移动 Accounts-SettingsHome 移动 Settings-Overview切换后aria-currenttrue由权威刷新确认收尾时恢复原始活跃账户并校验相等ID 从不打印。规范 OpenAI渲染 main 三个 pool 账户掩码标签与配额条切换经确认对话框目标卡片变card-active原始账户被恢复校验。Codex显式Set as Next Session原生按钮挂在每个非当前可用账户上无整卡可点击容器remove 标签含掩码邮箱。响应式矩阵请求宽度 - 有效 CSS 宽度 - 工作区状态1440-1800 宽分栏rail 280 / detail 960819-1024 约束分栏rail 240 单列 overview无垂直 URL 断行768-960 堆叠312-390 与 256-320 移动端堆叠文档与 shell 的scrollWidth clientWidth水平溢出为零。主题与 localeproviderimg报告filter: none明暗两主题均保留源色英文与韩文窄屏无竖排字符、无行内 Ready 文本。控制台/网络零 error/warn仅预期的账户 GET/PUT 与配额刷新。九、设计系统 SoT 同步与治理规则改造遵循现有设计系统权威原则docs/design-system/*与既有 token并约定SoT 同步只在 C 阶段渲染行为被证实后进行docs/design-system/components.md 现已记录 provider workspace 的完整契约——rail 行语法原色品牌图标 | 两行 copy | 状态 trail、基于容器宽度的分栏/堆叠行为、原始颜色 SVG 规则、detail tab 语义、账户行状态规则与 no-raw-ID 隐私契约。流程治理同样值得注意账户契约探索器与设计系统探索器均在 A 门禁给出VERDICT: READY而多位外部评审 Agent 因提供方配额或超时未返回结果按000_plan.md的升级规则主 Agent 收回审计并如实记录投递失败绝不把未返回的评审伪装成通过——最终 C 阶段仍要求全新独立评审最终裁决为VERDICT: PASSaccount-switcher与VERDICT: PASSprovider-rail-polish。结语基线证据驱动的契约—缺陷—激活—验证闭环002_baseline_evidence.md的价值在于它把模糊的 UI 观感问题翻译成了可复现的契约缺陷与激活场景从工作区只传oauthEmail到Codex 假成功、从{}三态混淆到listbox 双重 Tab stop每一项都有源码锚点、真实账户库存和浏览器观测支撑。后续两个切片分别以B 实现收据C 验证收据的方式逐一闭环最终以 133 pass / 0 fail 的集成套件、全宽度零溢出矩阵与活体账户还原校验收官。对于想理解 OpenCodex GUI 账户管理现状的读者本文列出的契约GET/PUT /api/oauth/accounts*、GET/PUT /api/codex-auth/*、缺陷清单与修复路径构成了可直接复用的排查与验收模板。赞分享【免费下载链接】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 OAuth/Codex 账户重新认证Re-auth全链路解析PR 171 后端-GUI 契约深度评审opencodex OAuth/Codex 账户重新认证Re auth全链路解析PR 171 后端 GUI 契约深度评审 本文围绕 opencodex 仓opencodex 管理 API 凭证契约全解Codex 账户池、OAuth 多账号与 API-Key 池的调用协议opencodex 管理 API 凭证契约全解Codex 账户池、OAuth 多账号与 API Key 池的调用协议 本文基于 opencodex 仓库中 dOpenCodex 提供者工作区账户切换与 Provider 导航栏重构实战从多账号隐藏到一等公民OpenCodex 提供者工作区账户切换与 Provider 导航栏重构实战从多账号隐藏到一等公民 本篇文章基于 OpenCodex 开源仓库Univers创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
