CodexBar Fork 发展路线图解析五阶段演进从分支定位到多账户管理【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBarCodexBar 是一款用于展示 OpenAI Codex 与 Claude Code 用量统计的 macOS 菜单栏应用无需登录即可工作。本文基于仓库中的 docs/FORK_ROADMAP.md 展开系统梳理 CodexBar 分支Fork由 Brandon Charleson 维护的五阶段发展路线从分支身份确立、Augment 诊断增强、Quotio 特性分析、上游同步工作流到多账户管理基础建设。读完本文你将完整掌握该分支的演进脉络、各阶段的技术任务清单、涉及的源码模块与配套脚本以及分支与上游协同开发的工程方法论。路线图概览与文档定位FORK_ROADMAP.md是分支维护者对开发工作的总纲性规划文档记录了自 2026 年 1 月起的阶段性目标。它同时服务于两类读者分支维护者作为每周、每月、每季度规划 fork 工作与评审里程碑的依据上游与社区观察者理解分支与上游steipete/CodexBar 原版及灵感来源quotio之间的关系边界。与本文配套的文档还包括 docs/UPSTREAM_STRATEGY.md多上游协同策略、docs/QUOTIO_ANALYSIS.mdQuotio 特性分析模板与 docs/augment.mdAugment Provider 说明建议结合阅读以获取完整上下文。✅ Phase 1分支身份确立已完成状态已于 2026 年 1 月 4 日完成。本阶段成果清单在 About 界面建立双重归属dual attribution——既保留原项目归属又标识分支维护者更新 README加入 fork 声明与增强说明创建完整的 Augment Provider 文档即 docs/augment.md应用可正常构建与运行。里程碑提交da3d13e— feat: establish fork identity with dual attribution这一阶段的意义在于为后续所有 fork 专属功能确立边界哪些改动属于分支哪些改动适合回馈上游。这一边界在 Phase 4 与上游贡献策略章节中被进一步制度化。 Phase 2增强 Augment 诊断能力目标通过更好的日志与诊断解决 Augment Provider 长期存在的 Cookie 断连问题。任务 1以规范日志替代 print()全程使用CodexBarLog.logger(augment)为调试添加结构化元数据遵循 Claude/Cursor Provider 已有的日志模式。从源码看这条要求已在实现中落地AugmentSessionKeepalive.swift末尾定义了private static let log CodexBarLog.logger(LogCategories.provider(.augment, scope: keepalive))见 Sources/CodexBarCore/Providers/Augment/AugmentSessionKeepalive.swift所有内部日志同时写入回调 logger 与统一日志体系每行均带时间戳与[AugmentKeepalive]前缀。任务 2增强 Cookie 诊断记录 Cookie 过期时间跟踪 Cookie 刷新尝试增加 Cookie 域名过滤诊断记录浏览器来源优先级。对应实现中AugmentCookieImporter.importSession见 Sources/CodexBarCore/Providers/Augment/AugmentStatusProbe.swift会按augmentCookieImportOrder默认浏览器导入顺序依次探测augmentcode.com与app.augmentcode.com两个域名并输出每个浏览器来源中找到的 Cookie 名清单。若找到的 Cookie 不匹配已知会话 Cookie 名会打印警告并提示用户上报新发现的 Cookie 名以帮助扩充检测名单。目前维护的会话 Cookie 名单sessionCookieNames覆盖了 Auth0 与 NextAuth/AuthJS 两套认证体系例如sessionauth.augmentcode.com 认证会话、_sessionapp.augmentcode.com 遗留会话web_rpc_proxy_sessionAugment RPC 代理会话auth0、auth0.is.authenticated、a0.spajs.txsAuth0 会话__Secure-next-auth.session-token、next-auth.session-token、__Secure-authjs.session-token、__Host-authjs.csrf-token、authjs.session-tokenNextAuth/AuthJS 会话。任务 3会话保活监控在调试面板展示 keepalive 状态记录刷新尝试及其成败跟踪距下次刷新的时间增加手动Force Refresh按钮。AugmentSessionKeepalive的公开 API 中forceRefresh()见 Sources/CodexBarCore/Providers/Augment/AugmentSessionKeepalive.swift即为手动强制刷新入口——它绕过限流直接执行performRefresh(forced: true)并在强制刷新时重置失败计数。其核心定时参数为参数默认值说明checkInterval60 秒会话健康检查周期refreshBufferSeconds300 秒Cookie 过期前的提前刷新缓冲minRefreshInterval60 秒两次刷新尝试的最小间隔限流refreshTimeout30 秒会话刷新请求超时maxConsecutiveFailures3 次连续失败上限达到后停止自动重试保活逻辑的核心判断在shouldRefreshSession()它会逐条列出每个 Cookie 的过期状态若全部为无过期时间的会话 Cookie则每 30 分钟做一次周期性刷新否则以最早过期时间与refreshBufferSeconds比较决定是否刷新。会话过期时attemptSessionRecovery()会自动打开https://app.augmentcode.com触发浏览器重新认证等待 5 秒后重新导入 Cookie 并 ping API 验证连续失败达到上限后通过UNUserNotificationCenter发送Augment Session Expired系统通知要求用户手动登录。任务 4调试面板改进新增Cookie Status区块当前 Cookie 与过期时间、最近一次成功导入、使用的浏览器来源、keepalive 状态新增Test Connection按钮显示详细的错误信息。配套的错误模型AugmentStatusProbeError见 Sources/CodexBarCore/Providers/Augment/AugmentStatusProbe.swift区分了notLoggedIn、networkError、parseFailed、noSessionCookie、sessionExpired五类错误并分别给出面向用户的提示文案debugRawProbe()与内存环形缓冲latestDumps()则提供了可粘贴的诊断输出。涉及文件Sources/CodexBarCore/Providers/Augment/AugmentStatusProbe.swiftSources/CodexBarCore/Providers/Augment/AugmentSessionKeepalive.swiftSources/CodexBar/UsageStore.swift调试面板 Phase 3Quotio 特性分析目标从 Quotio 中甄别并挑选有价值的特性借鉴模式而非复制代码。分析领域多账户管理Quotio 如何管理每个 Provider 的多个账户、账户切换 UI 模式、账户状态指示器OAuth 流程改进OAuth 实现模式、Token 刷新机制、错误处理策略UI/UX 模式菜单栏组织、设置布局、状态指示器、通知模式会话管理会话持久化、Cookie 刷新策略、自动重连逻辑。产出物docs/QUOTIO_ANALYSIS.md包含特性对比矩阵实现建议优先级排序工作量估算。仓库中已存在 docs/QUOTIO_ANALYSIS.md 模板其对比矩阵以Feature / CodexBar / Quotio / Notes四列组织如多账户、Provider 数量、Cookie 导入、OAuth 支持、会话保活、菜单栏 UI、设置 UI并将多账户管理列为高优先级、大规模工作量特性。配套的 Scripts/analyze_quotio.sh 脚本会自动拉取 quotio 远端、展示近 30 天提交、按providers/ui/auth区域列出相关文件并生成quotio-analysis-YYYYMMDD.md报告。文档同时强调了法律与伦理边界绝不逐字复制代码、不照搬 UI、不使用对方资产与品牌、尊重许可证所有实现须遵循 CodexBar 自身的约定并在提交与文档中正确标注灵感来源。 Phase 4上游同步工作流目标建立自动化工作流在保持 fork 改动的同时与上游保持同步。任务 1同步脚本规划中的Scripts/sync_upstream.sh负责拉取上游改动、展示 diff 摘要、提供交互式 merge/rebase。仓库中现已落地的相关脚本为Scripts/check_upstreams.shgit fetch上游与 quotio 两个远端统计main..upstream/branch的新提交数、展示提交图与文件变更统计并输出下一步操作提示首次运行会自动添加缺失的远端。Scripts/review_upstream.sh接受upstream或quotio参数自动创建upstream-sync/name-日期审查分支展示待审查提交与文件变更并生成upstream-review-name-日期.txt日志。Scripts/prepare_upstream_pr.sh从upstream/main创建干净的upstream-pr/feature-name分支用于提交不含 fork 品牌的上游 PR。任务 2冲突解决指南记录常见冲突区域制定解决策略提供测试清单。实践要点可参考 docs/UPSTREAM_STRATEGY.md 中的 Troubleshooting对于品牌归属文件如About.swift的冲突直接保留 fork 版本git checkout --ours对于其他文件则手动合并。任务 3自动化检查检测上游变更的 CI 工作流每周同步提醒兼容性测试。仓库中已存在 .github/workflows/upstream-monitor.yml定时任务为cron: 0 9 * * 1,4UTC 每周一、周四上午 9 点支持workflow_dispatch手动触发并可选择检查范围all/upstream/quotio。工作流会计算两个上游的新提交数若检测到变更则通过actions/github-script自动创建或更新带upstream-sync、needs-review标签的 issue正文包含两个上游的提交摘要与审查命令指引。计划创建的文件Scripts/sync_upstream.shdocs/UPSTREAM_STRATEGY.md已存在.github/workflows/upstream-sync-check.yml Phase 5多账户管理基础建设目标为 Provider先从 Augment 开始实现多账户支持。功能规划账户管理 UI按 Provider 添加/移除账户、账户昵称/标签、活跃账户指示器、快速切换账户存储基于 Keychain 的账户存储、账户元数据邮箱、套餐、最后使用时间、凭据安全隔离账户切换从菜单切换活跃账户、保留各账户独立的用量历史、基于额度的自动账户选择UI 增强菜单栏账户下拉、按账户展示用量、账户健康指示器。实施计划从 Augment Provider 入手其已有 Cookie 基础设施创建AccountManager服务更新UsageStore以处理多账户在菜单栏加入账户切换器扩展到其他 ProviderClaude、Cursor 等。从源码结构看UsageStore见 Sources/CodexBar/UsageStore.swift当前以Provider 单账户 Cookie 缓存模式工作AugmentSessionStoreactor见 Sources/CodexBarCore/Providers/Augment/AugmentStatusProbe.swift已具备将 Cookie 持久化到augment-session.json、从磁盘恢复、按需清空的完整会话存取能力可作为多账户存储的参考基础。计划创建的文件Sources/CodexBarCore/AccountManager.swiftSources/CodexBarCore/Providers/Augment/AugmentAccountManager.swiftSources/CodexBar/AccountSwitcherView.swift 未来增强清单短期1–2 周Augment Cookie 问题解决Phase 2Quotio 特性分析Phase 3上游同步工作流Phase 4中期1–2 个月多账户管理Phase 5增强通知系统用量历史跟踪导出用量数据长期3 个月以上自定义 Provider API用量预测/告警成本优化建议团队用量聚合 上游贡献策略适合回馈上游的场景惠及所有用户的 Bug 修复非 fork 专属的 Provider 改进文档改进性能优化。保留在 fork 中的场景多账户管理重大架构变更fork 专属品牌/归属实验性功能面向 topoffunnel.com 用户的专属功能。PR 规范保持 PR 聚焦且小型化附带完整测试遵循上游编码风格记录破坏性变更耐心对待评审流程。docs/UPSTREAM_STRATEGY.md 进一步给出了决策矩阵与提交策略通用 Bug 修复、性能改进、新 Provider 支持、通用 UI 改进、文档与测试应提交上游fork 品牌、多账户特性、实验性功能永远留在 fork。提交信息也按 fork 提交保留全部信息、上游提交通用化、Quotio 启发提交标注灵感来源三类区分。 成功度量指标技术指标零 Cookie 断连问题菜单栏响应时间 1 秒新特性 100% 测试覆盖上游同步零回归。用户指标topoffunnel.com 用户正向反馈活跃使用指标功能请求与参与度社区贡献。这些指标与 docs/UPSTREAM_STRATEGY.md 中的Fork Health / Upstream Relationship / Multi-Source Learning三组健康检查相互呼应并辅以固定节奏每周一运行./Scripts/check_upstreams.sh检查上游、每周四运行./Scripts/analyze_quotio.sh分析 quotio、每月更新QUOTIO_ANALYSIS.md与 fork 文档、每季度进行重大特性规划与路线图更新。 相关文档索引docs/augment.md — Augment Provider 专属文档Cookie 认证、保活、额度解析docs/DEVELOPMENT.md — 构建与测试说明docs/provider.md — 如何创建新 Providerdocs/UPSTREAM_STRATEGY.md — 与上游仓库同步的策略docs/QUOTIO_ANALYSIS.md — Quotio 特性对比与分析结语CodexBar Fork 路线图展示了一条清晰的演进路径先确立分支身份再集中修复 Augment 的 Cookie 稳定性问题继而借鉴 Quotio 的优质模式同时建立与上游steipete/CodexBar和灵感来源quotio之间的自动化同步与贡献机制最终落地多账户管理这一重大架构特性。对于 fork 维护者而言这份路线图本身就是一份可复用的工程模板——它明确了什么该留给 fork、什么该回馈上游的决策框架并用脚本、CI 工作流与成功指标将长期规划落到了可执行的日常节奏中。【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考