Skip to content

kimi-work 0.1.11: renew membership tokens and show shared monthly quota - #218

Open
lilongsky wants to merge 7 commits into
magpie-community:mainfrom
lilongsky:feat/kimi-work-refresh-monthly
Open

lilongsky wants to merge 7 commits into
magpie-community:mainfrom
lilongsky:feat/kimi-work-refresh-monthly

Conversation

@lilongsky

@lilongsky lilongsky commented Oct 18, 2026 •

Copy link
Copy Markdown

Expired desktop membership access currently makes Kimi Work quota unavailable. This adds host-managed membership renewal and a single monthly shared-pool meter in 0.1.11, incorporating main through 28f9cbb3b26ccc3a7739c8e21ebee0cda3d929d4 (official kimi-work 0.1.10).

  • Preserve upstream's effort parser, Work model menu (including K3.1 Pro), device headers, desktop platform headers and unauthenticated menu retry. The PR diff contains only packages/kimi-work.
  • Import membership access/refresh only on explicit sign-in. Renewal returns rotated fields for Magpie's conditional commit under its auth-store lock; exact input credentials isolate concurrent/reconnected lineages. Usage never rotates or writes credentials. No desktop configuration write or browser-cookie capture.
  • Give RefreshToken its own observed desktop headers, without Authorization/Cookie. COMPATIBILITY.md compares every captured header, documents JSON/protobuf and optional browser-field differences, and records actual 200 renewal/quota responses.
  • Display amountUsedRatio in one 本月 meter. Code's monthly share remains a text annotation, not a second allowance. Preserve schema conversion and cancellation during body reads.

Existing accounts: every official reference-only sign-in through 0.1.10 must reconnect once (magpie plugin login kimi-work). The card now recognizes the expired-sign-in marker and displays Magpie's localized re-add-account prompt. Earlier PR builds' saved pairs keep their format. If a saved refresh branch is rejected later, reconnect explicitly; usage never silently imports another desktop login.

At f67d742c73baf60ee7b493d22faa2771465b2e9e, local validation passed: 76 plugin tests, 2482 full-repository tests, the focused hook check and 25 total hook checks. An independent code/document re-review is CLEAR. Fork test PR #2 passed the unchanged original workflow on this head/base: Actions run. Its merge tree equals the head tree; this is supplemental CI evidence and does not replace upstream approval.

A fresh isolated login on 2026-10-24 tested both directions: plugin rotation → desktop's natural access expiry and native renewal (200) → plugin's natural access expiry and renewal from its retained branch (200), with monthly stats and desktop Work /models also 200. The record distinguishes the initially forced hook expiry from the later unmodified natural expiry. These are production plugin hooks in an isolated harness plus original native desktop methods, not a new Magpie credential-file commit/UI conversation test or a guarantee of indefinite coexistence.

中文

本次将会员续期和单个月度共享额度窗口合入上游 0.1.10,版本为 0.1.11;保留全部模型目录、K3.1 Pro 菜单、deviceId、请求头及无认证菜单回退修复。相对 main 仅修改 kimi-work。

  • 仅显式连接时导入会员凭证;续期由宿主在锁内核对原 access/refresh 后保存,按精确凭证隔离并发与重连。usage 只读,不写桌面配置、不抓浏览器 Cookie。
  • RefreshToken 使用独立桌面请求头,无 Authorization/Cookie。兼容性记录逐项对比真实官方请求,明确 JSON/Protobuf 及浏览器字段差异,并记录真实续期和月度接口 200。
  • 所有官方旧版至 0.1.10 的已连接账号均需手动重连一次;卡片显示宿主本地化的“登录已失效,请重新添加”提示,详情给出 CLI 命令。此前 PR 保存的凭证格式可继续使用;服务端拒绝旧刷新分支时仍需重连,不会偷偷导入当前桌面账号。
  • 上述完整 SHA 的本地 76 项插件测试、2482 项全仓测试、25 项接口检查通过,独立复审通过;原工作流的 fork PR / 运行记录 对应同一 head/base 和文件树,仅作上游审批之外的补充证据。
  • 使用用户新完成的隔离登录,已真实验证插件先续期后桌面自然过期仍能续期,以及桌面续期后插件自然过期仍能续期;双向均返回新双凭证和 200,会员/月度接口与桌面 Work 模型目录也均为 200。未把这次结果扩大为长期保证,未在本轮测试原生 Magpie 凭证文件提交或 UI 对话。临时凭证资料已清理;未部署或改写日常配置/会话。

@lilongsky lilongsky changed the title kimi-work 0.1.5: renew membership tokens and show monthly quota kimi-work 0.1.6: renew membership tokens and keep monthly quota readable Oct 22, 2026
@lilongsky

Copy link
Copy Markdown
Author

Supplemental fork CI: passed / Fork CI 补充验证:全部通过

The original, unmodified .github/workflows/pr.yml completed successfully in fork test PR #1: Actions run.

  • PR head tested: 9c5fdb90e5f5ba7a91e6f49d92bc8aed528c7b7f
  • Upstream base used: 1b06308fad9386171c25f377d3ff8fcc4d4f3757
  • Checkout merge commit: ca887579f1ddce369e6a96e7a89d438b9c8fdd94. Its Git tree (7aa68eab0f72c4700614e411f8d8e0b8286b89f7) is identical to the PR head's tree.
  • The workflow blob is unchanged between base and head: 7551ee4ad9c8b93ba1576155043a314aabef88f8. No source or workflow edits were made for this run.
Original job / step Result
test: HOME=$(mktemp -d) bun test 2158 passed, 0 failed, 189 files, 12741 assertions
test: bun scripts/check.mjs All 21 plugin hook checks passed, including kimi-work
on-npm: scripts/new-to-npm.sh Success; informational npm package-status check, no publishing

Environment: GitHub-hosted ubuntu-latest, Node.js 24, Bun 1.4.4. The test branches pin the same head/base as upstream #218, and the fork test PR remains unmerged. No real Kimi credentials or local Magpie configuration/sessions were used. This is supplemental fork CI evidence; it does not approve or replace the upstream run awaiting maintainer approval.

中文

已在自己的 fork 中创建测试 PR #1,使用与本 PR 相同的上述完整 head/base SHA,运行未经修改的原始工作流。云端运行记录已全部通过:2158 项测试通过、0 失败、21 项插件接口检查通过,npm 包状态查询任务也成功。CI 实际检出的合并提交文件树与本 PR 的 head 完全一致。

没有为跑通检查而修改源代码或工作流;没有使用真实 Kimi 凭证,也未改动本机 Magpie 配置或现有会话。结果作为 fork 的补充验证,上游工作流仍需维护者批准;本测试 PR 保持未合并。

@yetone yetone left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

感谢这么完整的验证记录和 fork CI。我在 PR head 9c5fdb90 上看过了这次的全部改动(index.mjs、README、COMPATIBILITY、四个测试文件),在一个沙箱 HOME 里跑了 bun test packages/kimi-work:50 pass / 0 fail。宿主这边我也对照了 magpie 的 host.js:auth.refresh / refreshLead,以及在锁里核对 secretOf(was) 和 access 之后才提交,都和 README 写的一致。设计本身我没有异议。

现在还不能合并,原因有下面几条。

1. 需要 rebase 到当前 main,版本改成 0.1.9。 这个 PR 的 base 还是 1b06308。之后 main 上的 kimi-work 已经发到 0.1.8:

  • 663ce13 0.1.6:某个模型的 effort 列表读不出来时,整个目录不再一起丢掉
  • 0a9415f 0.1.7:用 DescribeKimiWorkConfig(CONFIG、workConfigRows)补充模型
  • 8310fd2 0.1.8(#353):UA 改成 kimi-code-cli/0.36.0,并加上 workHeaders(deviceId) / readDeviceId

所以本 PR 的 "0.1.6" 和已发布的 0.1.6 撞号了。合并 main 后,index.mjs、package.json 和 tests/provider.test.mjs 会冲突(index.mjs 有 7 处)。解决冲突时请注意下面几点:

  • jsonRequest 在 main 上的签名是 (url, token, body, signal, deviceId),而且无条件发送 Authorization:'Bearer '+token。本 PR 的 jsonRequest(REFRESH, undefined, …) 依赖 ...(token?{Authorization:…}:{}) 这个条件分支。合并时要保留这个分支,不然发给 auth.kimi.com 的会是 Bearer undefined。请加一个测试,断言 REFRESH 请求里没有 Authorization。
  • readDesktop 的返回值要同时带上 deviceId: readDeviceId(file) 和 webRefresh。
  • 登录 callback 里探测 /models 时要传 s.deviceId(main 是 jsonRequest(BASE+'/models',s.workToken,undefined,undefined,s.deviceId))。
  • _internal 要同时导出两边的成员(workConfigRows, CONFIG, workHeaders, readDeviceId 和 REFRESH, REFRESH_LEAD, expiry)。
  • README 和 COMPATIBILITY 里所有 "0.1.6"、"upstream 0.1.5" 的说法都要按 0.1.9 重写。

2. 续期请求的请求头。 0.1.8 已经把发给 agent-gw 的请求改成 Kimi 自己客户端的样子了。按本 PR 的写法,发往 auth.kimi.com/.../RefreshToken 的请求走的是非 BASE 分支,只带 User-Agent: kimi-code-cli/0.36.0。这个组合是 Kimi Code CLI 的 UA 去调网页端的 auth 接口,官方客户端里不会出现。请把官方网页端(或桌面端)一次真实 RefreshToken 请求的全部请求头抓下来,和插件发出的逐项对比,然后按官方的发,并把对比结果写进 COMPATIBILITY。对第 1、2 点的修改,也请再跑一次真实续期(换出新的 access 和 refresh,GetSubscriptionStats 返回 200)。

3. 桌面端和插件共用同一条 refresh token 链。 这一点最关键,记录里没有回答。插件导入的是桌面 config.json 里 kimiWeb 的同一对 access/refresh。如果 Kimi 的 RefreshToken 会轮换并作废旧 refresh token(COMPATIBILITY 里观察到 refresh token 确实变了),那会出现两种情况:

  • magpie 续期之后,桌面端手里的旧 refresh token 失效,桌面 Work 被登出;
  • 反过来,桌面端先续期,magpie 存的那份失效,于是续期返回 401,用户又要重连。

0.1.5 之前的代码明确写了 "Never consume its refresh token",就是为了避开这个问题。之前的 live probe 只确认了桌面的 config.json 内容没变,没有确认之后桌面端是否还能正常续期、保持登录。请补一次真实记录:

  • magpie 续期之后,等桌面端自己的 access token 过期,确认桌面 Work 仍然在线;
  • 再在桌面端续期之后,确认 magpie 下一次续期是成功还是 401。

如果结果是两边只能活一个,就需要换方案,比如每次从桌面文件重新读取、只在桌面的 token 过期时才提示用户。还有一种情况:桌面端 token 已经更新,而 magpie 存的那份失效了。这时应该提示用户"重新连接",或者自动重新导入。README 要把这种行为写清楚。

4. 小问题,不阻塞合并。

  • 0.1.5 以前的老用户在 usage 里会直接看到 kimi_work_login_expired,必须手动重连。请确认 magpie 卡片上显示的提示文字能让用户明白要去重新连接,并在 PR 正文里写明这一点对所有已登录用户的影响(参见 LESSONS 里的 "a fix that holds only for new data says what happens to the old")。
  • COMPATIBILITY.md 现在主要是过程记录(独立 review、VM 用例数等),篇幅越来越长。建议只保留当前版本已验证的事实和局限。

rebase 之后,请在 PR 里写明:在新的 head sha 上跑了什么(bun test packages/kimi-work、完整的 bun test、bun scripts/check.mjs kimi-work),以及第 2、3 点真实测试的结果。我会在那个 head 上重新 review。


English summary. At 9c5fdb90, bun test packages/kimi-work passes 50/50, and magpie's host does commit auth.refresh under its lock as the README says. Not mergeable yet:

  1. Rebase onto main (kimi-work is at 0.1.8 there) and ship as 0.1.9. Keep 0.1.6's effort-list fix, 0.1.7's DescribeKimiWorkConfig models and 0.1.8's workHeaders/deviceId. Keep the conditional Authorization header for REFRESH, and add a test that REFRESH sends none.
  2. Diff the RefreshToken request's headers against the official web or desktop client's, and send what it sends. kimi-code-cli UA on auth.kimi.com isn't a real client combination.
  3. Show with a real run whether magpie and the desktop app can both keep renewing from one refresh lineage. If rotation revokes the old refresh token, one side gets signed out. That is why main avoided consuming it.
  4. Minor: say what existing signed-in users see, and trim COMPATIBILITY.md to the facts that are current.

@yetone

yetone commented Oct 24, 2026

Copy link
Copy Markdown
Contributor

谢谢 fork CI 的记录。我核对了一下:这次 fork 运行测的 head 是 9c5fdb90,和我 10:12 那次 change request review 的是同一个 head,运行时间(07:05)也在 review 之前。从那之后这个 PR 没有新的提交,仍然和 main 冲突,所以 review 里的四点都还没处理,现在还不能合并。

另外,main 刚刚又发了一个版本,rebase 的时候请注意:

  • kimi-work 0.1.9(df55294):jsonRequest 发往 www.kimi.com 的请求(非 BASE 分支)不再只带 {'User-Agent':UA},而是 webHeaders(platform),里面有 x-msh-platform(mac/windows)、x-msh-version、R-Timezone。createPlugin 新增了 platform 参数,_internal 新导出了 webHeaders。原因是 DescribeKimiWorkConfig 会根据这些请求头决定返回哪一份菜单,不带的话拿到的是网页版菜单,里面没有 K3.1 Pro(k3d1-agent)。
  • 所以这个 PR 的版本号请改成 0.1.10,而不是之前说的 0.1.9。REFRESH 请求要发什么请求头(第 2 点),也请按同样的原则,用抓到的官方请求来定。www.kimi.com 上的 UA 问题单独开了 kimi-work: www.kimi.com calls carry Kimi Code's User-Agent, not the desktop's #363。

rebase 之后,请在新的 head 上把 review 里列的命令跑一遍,再加上第 2、3 点的真实测试记录,我会在那个 head 上重新 review。


English: the fork run is at 9c5fdb90, the head the change request already reviewed (and it ran before the review). There are no commits since, and the PR still conflicts, so the four points stand. main is now kimi-work 0.1.9 (df55294): www.kimi.com calls send webHeaders(platform) (x-msh-platform/x-msh-version/R-Timezone) instead of a bare User-Agent, because DescribeKimiWorkConfig picks its menu by those headers, and createPlugin takes platform. Please rebase onto it and ship as 0.1.10.

@lilongsky lilongsky changed the title kimi-work 0.1.6: renew membership tokens and keep monthly quota readable kimi-work 0.1.11: renew membership tokens and show shared monthly quota Oct 24, 2026
@lilongsky

Copy link
Copy Markdown
Author

已在新 head f67d742c73baf60ee7b493d22faa2771465b2e9e 处理这四点,请基于此 head 复审。已合入 main 28f9cbb3b26ccc3a7739c8e21ebee0cda3d929d4;main 的 kimi-work 已是 0.1.10,因此本 PR 改为 0.1.11。相对 main 仅有 packages/kimi-work 的差异。

  1. 上游兼容: 保留 effort 容错、DescribeKimiWorkConfig、Work deviceId/headers、desktop webHeaders/platform,以及 0.1.10 的无认证菜单重取。readDesktop 同时返回 deviceId/webRefresh,登录探测传 deviceId,内部导出合并保留;新增断言 REFRESH 不含 Authorization/Cookie。
  2. 真实请求头: 抓取官方 Kimi 3.2.17 原始 AuthService 续期请求,以独立 refreshHeaders 替代 Code CLI UA。完整对比见 COMPATIBILITY:明确列出 Connect JSON/protobuf、locale、浏览器可选字段和传输生成字段的差异。没有复制 Cookie、设备/会话标识或 ShieldData。修改后的真实插件续期换出新 access/refresh,GetSubscriptionStats 为 200。
  3. 双向共存: 新的独立登录,2026-10-24 UTC 时间线:插件 15:21:07 先轮换,桌面仍持旧 pair;桌面 access 于 15:29:47 自然过期,原生 TokenStore 在 15:29:53–54 续期 200/双凭证变化;插件自身 access 于 15:36:07 自然过期,在 15:36:50 使用未修改的存储期限与自己保留的 refresh 分支,再次续期 200/双变化/月度接口 200。桌面会员和 Work /models 在随后检查仍为 200,桌面 pair 未被插件改写。临时浏览器已关闭,插件未重新导入桌面凭证。本轮未出现“两边只能存活一个”,但没有据此承诺永久接受旧 refresh。后续拒绝仍明确提示重连。
  4. 旧账号与文档: 所有官方 reference-only 版本至 0.1.10 的已连接用户需显式重连一次。错误采用宿主识别的 sign-in has expired,卡片显示本地化重新添加提示,详情包含 CLI 命令。COMPATIBILITY 已精简为当前事实和局限;本次隔离生产 hook/native 方法验证没有表述为原生 Magpie 凭证提交或 UI 对话验收。

本地最终 head: bun test packages/kimi-work 76 pass;完整 bun test 2482 pass / 0 fail;bun scripts/check.mjs kimi-work 和全部 25 项 hook 检查通过。独立代码及文档复审 CLEAR,文档的一处 P3 已整改并复审关闭。

同一 head 的原始 fork CI:测试 PR #2 / 运行 40108410843,全部成功。 Bun 1.4.4:2482 pass / 0 fail,215 个文件;test/check 步骤及 on-npm 任务均成功(无发布)。head/base 固定为上述完整 SHA,GitHub checkout 的合并提交 2df85c8e9a297c2066e2638adc6dd0cb16342249 文件树与 head 完全一致;原工作流 blob 未变。本记录不代替上游维护者审批。

公开记录仅含版本、提交、时间、HTTP 状态及脱敏头字段;未附 Kimi 账号名、手机号、用户 ID 或凭证。此次临时登录资料已清理,未部署本机插件或改写日常配置/会话。


English: all four review points are addressed at f67d742c73baf60ee7b493d22faa2771465b2e9e, incorporating main 28f9cbb3b26ccc3a7739c8e21ebee0cda3d929d4 as 0.1.11. Upstream model/menu/device/platform fixes and the unauthenticated CONFIG retry are preserved. REFRESH now uses separately observed desktop headers and sends no Authorization/Cookie; the compatibility record explicitly compares every header and the JSON/protobuf/optional-browser-field differences.

A fresh isolated login tested both branches through natural access expiry: plugin rotation at 15:21 → native desktop renewal at 15:29:53–54 → plugin renewal with its original stored expiry and retained refresh branch at 15:36:50, all 200 with changed access/refresh. Monthly reads and the temporary desktop's Work /models also returned 200. The initially forced plugin-hook expiry is distinguished from the later natural expiries. This demonstrates coexistence over that interval, not indefinite refresh reuse, a new native Magpie credential-file commit test or a UI conversation. All official reference-only sign-ins through 0.1.10 need one explicit reconnect; the host now shows its localized signed-out/re-add-account prompt.

Final-head local validation: 76 focused tests, 2482 full tests, 0 failures, 25 hook checks; independent code/document re-review CLEAR. The unchanged original fork workflow also passed 2482/0 on Bun 1.4.4, with both original jobs successful. Its pinned head/base and identical checkout/head trees are verified. Supplemental fork CI does not replace upstream approval. No Kimi account identifiers or credential values are included; temporary credential profiles were removed and everyday configuration/sessions were not operated on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants