CodexBar Qwen Cloud 浏览器 Cookie 导入修复实证：从 Chrome-only 到 Chrome + Brave 的完整验证流程

CodexBar Qwen Cloud 浏览器 Cookie 导入修复实证：从 Chrome-only 到 Chrome + Brave 的完整验证流程

【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar

导读

本文基于 docs/qwen-cloud-proof/README.md 这份实测记录，完整还原 CodexBar 中 Qwen Cloud（千问云）浏览器 Cookie 导入缺陷从发现、修复到验证的全过程：一个只在 Brave 中登录 Qwen Cloud 的用户，为什么会在 CLI 中收到 "No Qwen Cloud session cookies found in browsers" 的错误？修复如何将导入浏览器列表从 Chrome-only 调整为 Chrome + Brave？读完本文，你将掌握 Qwen Cloud 提供商的 Cookie 导入架构、登录票据判定逻辑、Keychain Safe Storage 授权流程，以及一份可复现的"真实行为证明"方法论。

问题背景：登录了 Brave，导入器却只搜 Chrome

现象：Chrome-only 导入导致会话"凭空消失"

在修复前的提交529cc6c24（"Keep Qwen imports Chrome-only"）中，Qwen Cloud 的浏览器 Cookie 导入顺序被硬编码为只探测 Chrome：

$ CodexBarCLI usage --provider qwen-cloud --format text --no-color [error] No Qwen Cloud session cookies found in browsers. Sign in to Qwen Cloud in Chrome, allow CodexBar to access Chrome Safe Storage in Keychain Access, or paste a manual Cookie header.

问题在于：该用户确实已登录 Qwen Cloud，但登录发生在Brave而非 Chrome。会话票据login_qwencloud_ticket就真实存在于 Brave 的 Cookie 存储中：

~/Library/Application Support/BraveSoftware/Brave-Browser/Default/Cookies

由于导入器从不探测 Brave，即使浏览器里躺着有效的登录票据，导入流程仍返回"无会话"。这是典型的"导入范围过窄"缺陷：凭据存在，但检索路径没覆盖它。

项目策略的冲突与权衡

这一缺陷并非简单疏漏，而是与 CodexBar 的"提示规避策略"（prompt-avoidance policy）直接冲突。见 AGENTS.md：

Cookie imports: default Chrome-only when possible to avoid other browser prompts; override via browser list when needed.

也就是说，默认只导入 Chrome是有意为之——每次访问其他浏览器的 Cookie 存储都可能弹出 macOS Keychain 授权对话框或浏览器存储访问提示，在自动刷新场景下会严重打扰用户。因此修复的关键不是"把所有浏览器都加上"，而是在最小必要范围内覆盖真实用户场景。

修复方案：browserOrder 收敛为 Chrome + Brave

修复后的效果

在分支diagnose/qwen-cloud-cookie-error（PR #3147）上，browserOrder被调整为[.chrome, .brave]。用户对修改后的二进制授予 macOS Keychain 访问权限后，同一个 CLI 命令返回了真实的用量数据：

$ CodexBarCLI usage --provider qwen-cloud --format text --no-color == Qwen Cloud (web) == Weekly: 20% left [==----------] Resets in 2d 2h Plan: Pro

同时可用--format json查看结构化的完整载荷（以下为脱敏快照）：

{ "source": "web", "provider": "qwencloud", "usage": { "identity": { "providerID": "qwencloud", "loginMethod": "Pro" }, "secondary": { "usedPercent": 79.97, "windowMinutes": 10080, "resetsAt": "2026-08-25T01:21:00Z", "resetDescription": "31,987.03 / 40,000 credits used" }, "updatedAt": "2026-08-22T23:11:11Z" } }

为什么是 Brave 而不是其余五个浏览器？

源码中的注释完整说明了取舍理由，见 QwenCloudProviderDescriptor.swift：

// AGENTS.md L48: "Cookie imports: default Chrome-only when possible to // avoid other browser prompts; override via browser list when needed." // The override here is the minimum necessary: Chrome + Brave. The full // 7-browser list (chromeBeta, edge, arc, firefox, safari) is // deliberately omitted so automatic refreshes do not surface unwanted // Keychain / browser-store access prompts on browsers that don't carry // a Qwen Cloud session. Brave is kept because it shares the same // Chromium Safe Storage format as Chrome and is a common Qwen Cloud // authentication target. let browserOrder: BrowserCookieImportOrder = [ .chrome, .brave, ]

决策依据有三点：

1. Chromium Safe Storage 格式兼容：Brave 与 Chrome 同为 Chromium 内核，Cookie 加密使用同一套 "Safe Storage" 密钥派生机制，导入代码可复用同一套解密路径，实现成本最低；
2. 真实用户分布：大量 CodexBar 用户通过 Brave 完成 Qwen Cloud 登录，这是被实测数据证实的主要场景；
3. 提示规避策略的延续：完整 7 浏览器列表（chromeBeta、edge、arc、firefox、safari）被刻意排除，避免自动刷新时对不含 Qwen Cloud 会话的浏览器弹出无意义的 Keychain / 浏览器存储访问授权。

注意：browserOrder的默认值在 QwenCloudCookieImporter.swift 中是Browser.defaultImportOrder，Qwen Cloud 通过 ProviderDescriptor 的browserCookieOrder字段（见 QwenCloudProviderDescriptor.swift）显式覆盖它；QwenCloudWebFetchStrategy也镜像维护了一份相同的browserOrder，源码注释要求两者保持同步（见 QwenCloudProviderDescriptor.swift）。

配套的测试断言同步更新

修复同时更新了 QwenCloudProviderTests.swift，将原先对 Chrome-only 的断言改为对[.chrome, .brave]的断言：

let expectedOrder: BrowserCookieImportOrder = [ .chrome, .brave, ] #expect(metadata.browserCookieOrder == expectedOrder) #expect(QwenCloudWebFetchStrategy.browserOrder == expectedOrder)

并且在非 macOS 平台上断言browserCookieOrder == nil（Cookie 导入本身是 macOS-only 能力）。

验证流程：一份可复现的"真实行为证明"

原文档给出了完整的验证路径，全部在 macOS 环境下执行：

1. 构建：在 worktree（/tmp/codexbar-main）中执行swift build成功；
2. 单元测试：执行swift test --filter QwenCloudProviderTests—— 7 个测试套件共 32/32 个测试全部通过；
3. 打包：执行./Scripts/package_app.sh debug，产出 ad-hoc 签名的CodexBar.app；
4. 安装：安装到/Applications/CodexBar-QwenFix.app（不带 quarantine 属性，避免 Gatekeeper 拦截）；
5. GUI 首次刷新授权：通过菜单栏触发首次刷新，macOS 弹出针对Brave Safe Storage的 Keychain 授权对话框，选择 "Always Allow" 后获得永久 ACL 访问权限；
6. CLI 验证：此后带CODEXBAR_ALLOW_BROWSER_COOKIE_IMPORT=1环境变量执行 CLI，稳定返回上述真实用量数据。

其中第 5 步是整个链路的关键：macOS 不会静默允许应用解密其他浏览器的 Cookie 库。即使导入器探测到了 Brave，也必须由用户在 Keychain 对话框中显式授予 "Brave Safe Storage" 的访问权限，解密后的 Cookie 值才能被读取。这也解释了修复前错误信息中那句 "allow CodexBar to access Chrome Safe Storage in Keychain Access" 的来源。

从源码看，这个错误文案本身就是随修复一起演进的：在 QwenCloudSettingsReader.swift 中，missingCookie的错误描述同时点名 Chrome 与 Brave 及各自的 Safe Storage 条目：

let base = "No Qwen Cloud session cookies found in browsers. " + "Sign in to Qwen Cloud in Chrome or Brave, " + "allow CodexBar to access the corresponding Safe Storage in Keychain Access " + "(Chrome Safe Storage and/or Brave Safe Storage), " + "or paste a manual Cookie header."

对应测试 QwenCloudProviderTests.swift 专门断言了错误文案必须同时包含 "Chrome"、"Brave"、"Safe Storage"、"manual Cookie header" 与 "Keychain Access"——否则 Brave-only 用户会被错误地引导去 Chrome 登录，永远找不到正确路径。

深入底层：Qwen Cloud Cookie 导入器如何判定"已登录"

修复只动了浏览器列表，判定逻辑本身是一套精心设计的会话验证机制，见 QwenCloudCookieImporter.swift：

扫描的 Cookie 域

Qwen Cloud 复用阿里云 one-console 认证后端，因此会话 Cookie 分布在 qwencloud.com 与 alibabacloud/aliyun 护照域上：

static let cookieDomains: [String] = [ "qwencloud.com", "home.qwencloud.com", "account.qwencloud.com", "signin.qwencloud.com", "www.qwencloud.com", "alibabacloud.com", "account.alibabacloud.com", "aliyun.com", "console.aliyun.com", ]

认证票据白名单

导入器用以下三种 Cookie 判定会话是否真实登录（QwenCloudCookieImporter.swift）：

static let authTicketCookies: Set<String> = [ "login_aliyunid_ticket", "login_qwencloud_ticket", "qwen_sso_ticket", ]

• login_qwencloud_ticket：Qwen Cloud 直连账号的登录票据；
• login_aliyunid_ticket：阿里云护照票据，覆盖 legacy/联邦账号；
• qwen_sso_ticket：SAML/SSO 登录场景的票据。

isAuthenticatedSession（QwenCloudCookieImporter.swift）只要票据集合与 Cookie 名集合有交集即判定已登录。

为什么必须排除"伪会话" Cookie

关键设计点在于：locale 偏好、账号 ID 标记、CSRF 票据等 Cookie 被刻意排除在判定之外。原因是只访问过 qwencloud.com 但未登录的浏览器档案同样携带这些 Cookie；若把它们当作已登录，导入器会向 API 发送无票据请求，收到loginRequired后陷入"反复导入同一档案"的死循环。

这一点由测试 QwenCloudProviderTests.swift 直接验证：仅含locale_pref、login_aliyunid_pk、login_current_pk、sec_token的 Cookie 集合不被判定为已登录会话。

修复背后：Cookie 解密与 Keychain 的关系

修复前错误信息与 Keychain 相关，原因是浏览器 Cookie 库的值列是空的。Brave 的 SQLite Cookie 存储中，明文 Cookie 值存放在encrypted_valueBLOB 中，只有用用户的 "Brave Safe Storage" 密钥解密后才能读取。原文档的脱敏说明（Redaction notes）确认：解密后的 Cookie 内容不会出现在任何地方，证明记录中既不包含 Cookie 值，也不包含 Keychain 内容。

这也解释了为何 CLI 首次运行必须经历 GUI 授权：命令行进程无法独立弹出受控的 Keychain 授权 UI，因此在菜单栏 GUI 中先完成一次授权、建立永久 ACL，后续 CLI 调用才能无感读取。实测流程中环境变量CODEXBAR_ALLOW_BROWSER_COOKIE_IMPORT=1即用于显式开启该能力。

从错误到真实数据的完整调用链

修复生效后的数据获取链路（结合 QwenCloudUsageFetcher.swift 梳理）：

1. Cookie 解析：QwenCloudWebFetchStrategy.resolveCookieHeaders按优先级尝试 手动 Cookie（cookieSource == .manual）→ 环境变量 Cookie（QWEN_CLOUD_COOKIE）→ 缓存 Cookie → 浏览器导入，见 QwenCloudProviderDescriptor.swift；

2. sec_token 解析：通过OneConsoleSECTokenResolver从 仪表盘 HTML、sec_tokenCookie 或/tool/user/info.json端点解析出sec_token（三级 fallback）；

3. 三次 API 调用：依次请求 usage、subscription、quota-config 三个端点：

   • zeldaHttp.apikeyMgr./tokenplan/personal/api/v2/usage
   • zeldaHttp.apikeyMgr./tokenplan/personal/api/v2/subscription
   • zeldaHttp.apikeyMgr./tokenplan/personal/api/v2/quota-config

   表单字段固定为product=sfm_bailian、action=IntlBroadScopeAspnGateway、region=ap-southeast-1、language=en-US，加上解析出的sec_token（见 QwenCloudUsageFetcher.swift）；

4. 快照组装：usage 响应提供 5 小时与每周的消耗比例和重置时间，subscription 响应标识当前套餐档位，quota-config 提供该档位的额度数值，三者合并为QwenCloudUsageSnapshot。

整个调用链由测试 QwenCloudProviderTests.swift 用 stub URLProtocol 完整验证，包括 sec_token 预检、三次 API 的请求顺序与参数、套餐名称（如 "Standard"）与 5 小时/每周两档额度的映射。

隐私与脱敏原则

原文档在 Redaction notes 中明确了这份证明的隐私边界，也是本项目处理用户数据的一贯原则：

• loginMethod: "Pro"仅表示套餐档位，不包含账号标识、邮箱、用户 ID、Cookie 值或任何 Keychain 内容；
• 79.97% 的周用量是某个时点的快照数字，不是真实客户数据；
• Brave SQLite Cookie 存储中的encrypted_valueBLOB 只有在持有用户 Safe Storage 密钥时才能解密，解密后的 Cookie 内容不会出现在证明记录中。

相关能力还可参考 docs/qwen-cloud.md（Qwen Cloud 提供商的完整功能说明、手动 Cookie 导入步骤与故障排查指南）以及 docs/providers.md（各提供商特性总览）。

结论与可借鉴的修复范式

这个案例给出了一个可复用的"缺陷修复 + 行为证明"范式：

1. 明确定位：先用 CLI 复现错误，再确认凭据确实存在于某个浏览器（本案例为 Brave 的 SQLite Cookie 库）；
2. 最小范围修复：在项目"默认 Chrome-only"策略与真实用户需求之间取交集，仅追加共享同一 Safe Storage 格式的 Brave，而非无差别放开全部浏览器；
3. 同步更新测试与文案：测试断言、错误提示、源码注释三处保持一致的浏览器列表，确保 Brave-only 用户能被正确引导；
4. 完整的行为证明：以构建 → 单测 → 打包 → 安装 → GUI 授权 → CLI 复验的全链路记录，证明修复在真实环境下生效，同时严守隐私边界。

对于 CodexBar 的其他提供商（如阿里云百炼、Qwen 旗下产品），这套"浏览器 Cookie 导入 + 会话票据判定 + Keychain 授权"的模式同样适用——需要扩展某个提供商支持的浏览器时，只需在其 ProviderDescriptor 中调整browserOrder并同步更新测试与错误文案即可。

【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar