magicrew-auth 0.3.5 → 0.3.6

package/CHANGELOG.md

@@ -1,5 +1,22 @@
 # 更新记录
 
+## 0.3.6
+
+**修：添加第二个账号时网页闪一下就关，magpie 里没多出账号**
+
+- 症状：点「添加账号」→ 浏览器正常弹出 → 一两秒内自己关掉；用户确实也登录成功了，但账号列表里没有新账号
+- 根因：登录浏览器**复用**同一个 profile（`~/.cache/magpie/magicrew-login-profile`）。第二个窗口一打开，
+  localStorage 里就是上一个账号的 `MAGIC:user:authorization` / `organizationCode`，`waitForCreds`
+  第一轮（1.5 秒）读到它 → 判定登录完成 → 关窗；magpie 拿到的 `accountId` / `uid` 与已有账号完全相同，
+  按契约「同 accountId + 同 uid → 替换旧账号」→ 不新增
+- 修法：每次登录一个**一次性** profile（`magicrew-login-<pid>-<ts>-<rand>`），`closeSession()` 关窗后删；
+  `launchLoginBrowser()` 开头先 `sweepProfiles()` 清掉历史复用目录与超过 2 小时的一次性目录
+  （只认本插件造的名字，且只动目录 —— 同前缀的 `.log` 不碰）
+- 第二道防线：`waitForCreds(..., { baseline })` —— 窗口打开时就存在的凭据不算登录成功
+- 代价：每次都要在窗口里重新登录一次（独立 profile 本来也没有日常 cookie），换来「读到的凭据一定是本次的」
+- 判据：`node tools/_verify_profile_scope.mjs`（窗口打开 4 秒后 `READ_CREDS` 必须是空串、关窗后目录必须不存在）
+  + `node tests/login-profile.mjs`
+
 ## 0.3.5
 
 **卡片上多一个「承载」徽章：`magpie.carries`**

package/README.md

@@ -115,6 +115,10 @@
 `--remote-debugging-port`），所以登录成功后能用 CDP 在页面上下文里把它自己的
 localStorage 读走，拿到 JWT 和组织码，签完密钥就关窗。
 
+**每次登录都是一个新的 profile，用完就删。** 这是必须的：共用一个 profile 的话，
+添加第二个账号时窗口一打开，页面里已经躺着上一个账号的凭据 —— 插件会以为登录完成、
+立刻关窗，而 magpie 拿到的还是旧账号（同账号 → 替换，不新增）。
+
 > **为什么必须自己拉浏览器？** 因为 magicrew 没有 OAuth 回调通道 —— 它的登录类型只有 13 种、全是「拿凭据换 token」，没有设备码、没有插件授权、没有一次性 ticket；也没有 WorkBuddy 那种 `/v2/plugin/auth/state` + `/v2/plugin/auth/token` 协议。网页登录成功后 token 只在 `www.magicrew.ai` 的 localStorage 里，而 magpie 打开的是你系统默认那个浏览器，插件够不到它的存储。自己起一个，就够得到了。
 >
 > 本机没装 Chrome / Edge 时自动降级：改用系统浏览器打开，登录完把凭证送进剪贴板，插件从剪贴板读。
@@ -162,6 +166,8 @@ magpie plugin list
 
 **两个站要装两次吗？** 不用。一个包导出两个插件，装一次两个供应商都在，各自登录。
 
+**添加第二个账号时，网页闪一下就关了、magpie 里也没多出账号？** 0.3.5 及更早会这样：登录浏览器复用同一个 profile，第二个窗口一打开就读到上一个账号的凭据，于是立刻「登录成功」并关窗 —— 加到的是已有账号。0.3.6 起每次登录用一个一次性 profile（关窗即删），不会再串号。
+
 **npm 上叫 `magicrew-auth`，为什么卡片显示 `Magicrew`？** 卡片标题取包内 `package.json` 的 `name`（`Magicrew`），而 npm 拒绝含大写字母的新包名。发布时用 `publish-npm.mjs` 临时换成 `magicrew-auth`、发完还原 —— 所以 npm 页面是小写包名，git 源装出来是 `Magicrew`。功能完全一样。
 
 **为什么模型列表会变？** 因为清单是从 `/api/v1/flows/models` 实时拉的。订阅档位变了、平台方上下架变了，清单就跟着变 —— 插件里没有需要维护的模型表。

package/docs/internals.md

@@ -442,7 +442,7 @@ linux   xclip -selection clipboard -o
 launchLoginBrowser(url)
   → findBrowser()          Edge / Chrome / Brave / Chromium，按平台列路径逐个 existsSync
   → spawn(exe, [
-      --user-data-dir=~/.cache/magpie/magicrew-login-profile,
+      --user-data-dir=~/.cache/magpie/magicrew-login-<pid>-<ts>-<rand>,   ← 一次性，见下面 ②
       --remote-debugging-port=0,      ← 0 = 让系统挑空闲端口
       --no-first-run, --no-default-browser-check,
       url,
@@ -473,10 +473,28 @@ JSON.stringify({ jwt: pick("MAGIC:user:authorization"), org: pick("MAGIC:user:or
 抛 SecurityError，被 `catch` 吞掉→看起来像「一直读不到」。必须只认 URL 匹配的 target，
 匹配不上返回 null 让轮询继续。实测：启动 → 页面就绪只需 **1.5 秒**，但必须等到它跳转。
 
-**② profile 目录不能删。**
-独立 profile 意味着用户在这个窗口里要重新登录一次（没有他日常浏览器的 cookie）。
-下次登录还用它，登录态就还在 —— 所以目录固定为
-`~/.cache/magpie/magicrew-login-profile`，只 `kill()` 进程，不删目录。
+**② profile 目录必须一次性，用完删。**（2026-10-27 更正 —— 这里原先写的是「不能删」）
+
+原先固定复用 `~/.cache/magpie/magicrew-login-profile`，理由是「登录态留着，下次不用重登」。
+那会制造一个很隐蔽的串号 bug：**添加第二个账号时，浏览器一打开，localStorage 里就躺着
+上一个账号的 jwt + org**，`waitForCreds` 第一轮（1.5 秒内）命中 → 立刻关窗；magpie 拿到的
+`accountId` / `uid` 与已有账号一模一样，按契约「同一 accountId + 同一 uid → 替换旧账号」，
+于是**不新增账号**。用户看到的就是「网页闪一下就没了，登录成功但 magpie 里没多出账号」。
+
+现在的做法：
+
+```
+newProfileDir()        → magicrew-login-<pid>-<ts36>-<rand>，每次登录一个
+sweepProfiles()        → launch 开头先清：历史复用目录一律删、一次性目录超过 2h 删
+                         （只认本插件造的名字，且只动目录 —— 同前缀的 .log 不动）
+closeSession()         → 关窗后删掉这一次的目录；删不掉留给下次 sweep
+waitForCreds(..., { baseline })  → 第二道防线：窗口打开时就有的凭据不算登录成功
+```
+
+代价是每次都要在这个窗口里重新登录一次 —— 独立 profile 本来也没有他日常浏览器的 cookie。
+
+判据（可复跑）：`node tools/_verify_profile_scope.mjs` —— 窗口打开 4 秒后
+`READ_CREDS` 必须返回**空串**，关窗后目录必须不存在。单元测试见 `tests/login-profile.mjs`。
 
 **③ `authorize()` 里可以 await 启动浏览器（~270ms），但不能 await 用户操作。**
 `launchLoginBrowser` 实测 273ms 返回，可接受；`waitForCreds` 必须放到 `callback()` 里。
@@ -656,129 +674,129 @@ mgw_8f9a…（18:14 又一次续期换的）       → 网关请求 HTTP 200 正
 key-store 是空的（第一次跑或文件被清）时，从 magpie 的 `plugin-auth.json` 里
 **接管一次** `access` / `refresh` / `expires` 并落盘，之后完全自管。接管来的那把如果
 已经不够新鲜，紧接着就走续期。
-
----
-
-## 十五、key 按账号隔离 + 双槽（0.3.3）
-
-### 为什么必须按账号分文件
-
-同一个站点可以登多个账号（magpie 里显示成 `magicrew` / `magicrew#1` / …）。
-key 若按站点存一份，第二个账号登录时会把第一个账号的 key 覆盖掉 —— 第一个账号从此 403，
-而且看起来像"随机失效"。
-
-落盘：`~/.cache/magpie/magicrew-key-<站点>__<账号>.json`，账号用 `org`（组织码，登录后固定）。
-
-### 双槽怎么转
-
-```
-a 槽 ← 正在用
-b 槽 ← 上一次的，还活着（回退用）
-
-续期：  b 槽写新的 → current 切到 b → a 槽那把留着自然过期
-403 ：  当前那把标失效（expiresAt=0）→ current 切到另一槽 → 重试一次
-两槽都空：从 magpie 的 plugin-auth.json 接管一次
-```
-
-**为什么敢双槽**：实测同一账号两把 `mgw_` key 可以同时有效。
-**为什么不需要"闲置池"**：实测一把 key 并发 6 个请求全成功 —— 它是账号级无状态凭据，
-不存在"被占用 / 打架"。
-
-### 实测记录（2026-10-27）
-
-```
-续期前 槽a = mgw_55accec4…  | refreshToken: 有
-续期后 槽b = mgw_06713b5e…  | 到期 20:23:17
-回退槽 = mgw_55accec4…      ← 保留
-新 key 打上游 /v1/models → 正常返回模型列表
-
-账号隔离：h97gkbu8bruj 与 otherOrg999 各自一份文件，互不覆盖
-
-并发：同一把 key 发 6 个 chat.completions → #0✓ #1✓ #2✓ #3✓ #4✓ #5✓（18.1s）
-```
-
-### ⚠ 已知未解决
-
-`403 自动切槽`在实测里没触发成功过一次（单独测 `switchSlot` 是好的，接进 loader 后
-没观察到切换）。下次排查先看：`key.apiKey` 与 `switchSlot` 里比较的那把是否同一个对象、
-`body` 是否真的是字符串。
-
-### ⚠ 升级到按账号命名时，旧文件必须清掉
-
-0.3.2 之前文件叫 `magicrew-key-<站点>.json`（按站点）；
-0.3.3 起叫 `magicrew-key-<站点>__<账号>.json`（按账号）。
-
-两套命名并存时，旧文件**不会被新代码读到**（文件名不匹配），但它会让人误判现场：
-排查时看到 `magicrew-key-magicrew.json` 里躺着一把旧 key，会以为那是在用的。
-
-实测踩到：旧文件残留 + magpie 重启，网关连续 502 `token无效`；
-删掉旧文件后立刻恢复 200。**升级时先 `rm ~/.cache/magpie/magicrew-key-*` 再重启。**
-
-### ⚠ 重启时序
-
-magpie 刚起来时 `getAuth()` 可能还返回 null（账号未加载完），此时
-`accountOf(auth)` 会退成 `default`，读不到该账号的文件 → 用 magpie 暂存那把（可能死）→ 403。
-几次请求后账号加载完就正常。**排查时若看到 `__default.json`，就是这个时序。**
-
----
-
-## 十六、上下文窗口必须查库，不能填保守值
-
-**症状**：`pi-ai detected context overflow for model "magicrew/deepseek-v4.1-flash"`，
-而会话实际还没到模型的真实上限。
-
-**根因**：magicrew 这两个接口**都不返回上下文窗口**：
-
-```
-GET /api/v1/flows/models  → value / label / vision / tags / configs
-GET /v1/models            → id / object / created_at / owner_by
-```
-
-（早前记的「/v1/models 有 context_length」是看错了 —— 那是 magpie 网关自己补的，
-不是上游给的。）
-
-于是插件一律填 `256_000` 当保守值。对 `deepseek-v4.1-flash` 来说这是错的：
-它真实窗口 **1,048,576**，填 256K 等于把容量砍掉四分之三，agent 拿这个数判断"放不下"
-就拒绝了 —— 保守值在这里反而变成了故障源。
-
-**修法**（0.3.4）：向 magpie 自己的模型库查 —— `~/.cache/magpie/models.json`，
-每条带 `limit.context`，magpie 自己会更新它。
-
-匹配顺序：全名 → 尾段（`deepseek-ai/deepseek-v4.1-flash` ↔ `deepseek-v4.1-flash`）→
-同尾段取最大（同一个模型挂多个厂商前缀时，取真能收的那个）。查不到才退回 256K。
-
-实测值（2026-10-27）：
-
-| 模型 | context |
-|---|---|
-| deepseek-v4.1-flash | 1,048,576 |
-| deepseek-v4-flash | 1,048,576 |
-| qwen3.5-flash | 1,000,000 |
-| kimi-k3.1-pro | 1,048,576 |
-| mimo-v2.6-flash | 1,048,576 |
-| glm-5.3-flash | 262,144 |
-
-⚠ 保守值的方向要想清楚：**填小了会让 agent 过早拒绝（这次就是这个）**，
-填大了会让 agent 以为有余量、请求超了上游才报错。有权威来源时用权威来源，
-没有时才选保守 —— 而"保守"在两者之间是矛盾的，得看哪个代价更小。
-
-### 上下文窗口的优先级（0.3.5 起）
-
-```
-① magpie GUI 里「上下文窗口」那一行手选的     ← 最优先，magpie 直接采用
-② ~/.cache/magpie/models.json 的 limit.context  ← 插件查到的真实值
-③ 兜底 1_048_576
-```
-
-**兜底为什么给大不给小**：
-- 给 1M 而实际只有 128K → 上游超限报错，**用户看得见**
-- 给 256K 而实际有 1M → agent 主动拒绝本可以处理的对话，**静默损失能力**，
-  表现成 `pi-ai detected context overflow`，比报错难查得多
-
-参照官方社区插件：
-- **Qoder** 纯硬编码（`{ id: "ultimate", context: 1_000_000 }`）
-- **WorkBuddy** 硬编码一张 `[id, name, context, efforts]` 表，再从自家 `/v3/config`
-  的 `maxInputTokens` 覆盖（`m.context = d.maxInputTokens`）
-
-magicrew 既不返回 `maxInputTokens`（`flows/models` 的 `configs` 只有 temperature），
-`/v1/models` 也只有 `id / object / created_at / owner_by` —— 所以走模型库这条路。
+
+---
+
+## 十五、key 按账号隔离 + 双槽（0.3.3）
+
+### 为什么必须按账号分文件
+
+同一个站点可以登多个账号（magpie 里显示成 `magicrew` / `magicrew#1` / …）。
+key 若按站点存一份，第二个账号登录时会把第一个账号的 key 覆盖掉 —— 第一个账号从此 403，
+而且看起来像"随机失效"。
+
+落盘：`~/.cache/magpie/magicrew-key-<站点>__<账号>.json`，账号用 `org`（组织码，登录后固定）。
+
+### 双槽怎么转
+
+```
+a 槽 ← 正在用
+b 槽 ← 上一次的，还活着（回退用）
+
+续期：  b 槽写新的 → current 切到 b → a 槽那把留着自然过期
+403 ：  当前那把标失效（expiresAt=0）→ current 切到另一槽 → 重试一次
+两槽都空：从 magpie 的 plugin-auth.json 接管一次
+```
+
+**为什么敢双槽**：实测同一账号两把 `mgw_` key 可以同时有效。
+**为什么不需要"闲置池"**：实测一把 key 并发 6 个请求全成功 —— 它是账号级无状态凭据，
+不存在"被占用 / 打架"。
+
+### 实测记录（2026-10-27）
+
+```
+续期前 槽a = mgw_55accec4…  | refreshToken: 有
+续期后 槽b = mgw_06713b5e…  | 到期 20:23:17
+回退槽 = mgw_55accec4…      ← 保留
+新 key 打上游 /v1/models → 正常返回模型列表
+
+账号隔离：h97gkbu8bruj 与 otherOrg999 各自一份文件，互不覆盖
+
+并发：同一把 key 发 6 个 chat.completions → #0✓ #1✓ #2✓ #3✓ #4✓ #5✓（18.1s）
+```
+
+### ⚠ 已知未解决
+
+`403 自动切槽`在实测里没触发成功过一次（单独测 `switchSlot` 是好的，接进 loader 后
+没观察到切换）。下次排查先看：`key.apiKey` 与 `switchSlot` 里比较的那把是否同一个对象、
+`body` 是否真的是字符串。
+
+### ⚠ 升级到按账号命名时，旧文件必须清掉
+
+0.3.2 之前文件叫 `magicrew-key-<站点>.json`（按站点）；
+0.3.3 起叫 `magicrew-key-<站点>__<账号>.json`（按账号）。
+
+两套命名并存时，旧文件**不会被新代码读到**（文件名不匹配），但它会让人误判现场：
+排查时看到 `magicrew-key-magicrew.json` 里躺着一把旧 key，会以为那是在用的。
+
+实测踩到：旧文件残留 + magpie 重启，网关连续 502 `token无效`；
+删掉旧文件后立刻恢复 200。**升级时先 `rm ~/.cache/magpie/magicrew-key-*` 再重启。**
+
+### ⚠ 重启时序
+
+magpie 刚起来时 `getAuth()` 可能还返回 null（账号未加载完），此时
+`accountOf(auth)` 会退成 `default`，读不到该账号的文件 → 用 magpie 暂存那把（可能死）→ 403。
+几次请求后账号加载完就正常。**排查时若看到 `__default.json`，就是这个时序。**
+
+---
+
+## 十六、上下文窗口必须查库，不能填保守值
+
+**症状**：`pi-ai detected context overflow for model "magicrew/deepseek-v4.1-flash"`，
+而会话实际还没到模型的真实上限。
+
+**根因**：magicrew 这两个接口**都不返回上下文窗口**：
+
+```
+GET /api/v1/flows/models  → value / label / vision / tags / configs
+GET /v1/models            → id / object / created_at / owner_by
+```
+
+（早前记的「/v1/models 有 context_length」是看错了 —— 那是 magpie 网关自己补的，
+不是上游给的。）
+
+于是插件一律填 `256_000` 当保守值。对 `deepseek-v4.1-flash` 来说这是错的：
+它真实窗口 **1,048,576**，填 256K 等于把容量砍掉四分之三，agent 拿这个数判断"放不下"
+就拒绝了 —— 保守值在这里反而变成了故障源。
+
+**修法**（0.3.4）：向 magpie 自己的模型库查 —— `~/.cache/magpie/models.json`，
+每条带 `limit.context`，magpie 自己会更新它。
+
+匹配顺序：全名 → 尾段（`deepseek-ai/deepseek-v4.1-flash` ↔ `deepseek-v4.1-flash`）→
+同尾段取最大（同一个模型挂多个厂商前缀时，取真能收的那个）。查不到才退回 256K。
+
+实测值（2026-10-27）：
+
+| 模型 | context |
+|---|---|
+| deepseek-v4.1-flash | 1,048,576 |
+| deepseek-v4-flash | 1,048,576 |
+| qwen3.5-flash | 1,000,000 |
+| kimi-k3.1-pro | 1,048,576 |
+| mimo-v2.6-flash | 1,048,576 |
+| glm-5.3-flash | 262,144 |
+
+⚠ 保守值的方向要想清楚：**填小了会让 agent 过早拒绝（这次就是这个）**，
+填大了会让 agent 以为有余量、请求超了上游才报错。有权威来源时用权威来源，
+没有时才选保守 —— 而"保守"在两者之间是矛盾的，得看哪个代价更小。
+
+### 上下文窗口的优先级（0.3.5 起）
+
+```
+① magpie GUI 里「上下文窗口」那一行手选的     ← 最优先，magpie 直接采用
+② ~/.cache/magpie/models.json 的 limit.context  ← 插件查到的真实值
+③ 兜底 1_048_576
+```
+
+**兜底为什么给大不给小**：
+- 给 1M 而实际只有 128K → 上游超限报错，**用户看得见**
+- 给 256K 而实际有 1M → agent 主动拒绝本可以处理的对话，**静默损失能力**，
+  表现成 `pi-ai detected context overflow`，比报错难查得多
+
+参照官方社区插件：
+- **Qoder** 纯硬编码（`{ id: "ultimate", context: 1_000_000 }`）
+- **WorkBuddy** 硬编码一张 `[id, name, context, efforts]` 表，再从自家 `/v3/config`
+  的 `maxInputTokens` 覆盖（`m.context = d.maxInputTokens`）
+
+magicrew 既不返回 `maxInputTokens`（`flows/models` 的 `configs` 只有 temperature），
+`/v1/models` 也只有 `id / object / created_at / owner_by` —— 所以走模型库这条路。

package/docs/npm-publish.md

@@ -0,0 +1,77 @@
+# 发 npm：`magicrew-auth`
+
+> 线上：https://www.npmjs.com/package/magicrew-auth
+> 首次发布 2026-10-27，`0.3.5`。**这个包名已经是我们的，之后只增版本，不再改名。**
+
+## 一条命令
+
+```bash
+npm run publish:npm                 # 真发
+npm run publish:npm -- --dry-run    # 预演，看包名与打包面，不上传
+```
+
+脚本是 `publish-npm.mjs`，做的事只有一件：**发布那一下把 `name` 换成 `magicrew-auth`，跑完还原。**
+
+## 为什么必须换名
+
+registry 拒绝含大写字母的**新**包名，而 `package.json` 的 `name` 要同时喂两个地方：
+
+| 谁读 | 读哪份 | 决定什么 |
+|---|---|---|
+| `bun`（`magpie plugin add github:…`） | 仓库里的 `package.json` | 依赖键 → **卡片标题 `Magicrew`** |
+| `npm publish` | 同一份 | npm 上的**包名** → 必须小写 `magicrew-auth` |
+
+所以 npm 装的卡片标题是 `magicrew-auth`，git 装的卡片标题是 `Magicrew` —— 功能一样，只是标题。
+FAQ 里对用户写过这条，别把它当 bug 修。
+
+还原是硬要求：脚本在 `finally` 之外还挂了 `exit` / `SIGINT` 钩子。实测跑完
+`sha256sum package.json` 与跑前逐字节一致。
+
+## 发之前的三条
+
+1. **bump `version`** —— 同版本号 publish 会被 registry 拒。
+2. **`npm view magicrew-auth version` 看现在线上的版本**，别发重复。
+3. README 会随包发出去，成为 magpie 卡片正文 —— **npm 用户的卡片只有发版才更新**
+   （git 源用户 push 即见）。所以 README 改完要跟着一个版本走。
+
+## 发完之后会看到 `0.0.0-stage`，别慌
+
+registry 上会先多出一个占位版本：
+
+```json
+{ "version": "0.0.0-stage", "stub": true,
+  "description": "Temporary package placeholder for staged publishing" }
+```
+
+`dist-tags.latest` 可能先指向它，几秒后指向真版本；`npm stage list` 显示「没有 staged 版本」。
+判据：
+
+```bash
+curl -s https://registry.npmjs.org/magicrew-auth | python -c "import json,sys;d=json.load(sys.stdin);print(d['dist-tags'])"
+# {'latest': '0.3.5'}
+curl -s -o /dev/null -w '%{http_code}\n' https://registry.npmjs.org/magicrew-auth/0.3.5
+# 200
+```
+
+## 验收（2026-10-27 实测）
+
+```
+npm view magicrew-auth version     → 0.3.5
+npm view magicrew-auth dist-tags   → { latest: '0.3.5' }
+npm i magicrew-auth && node -e "import('magicrew-auth')"
+  → exports: MagicrewAuthPlugin, MagicrewIntlAuthPlugin, SITES, _internal
+tarball 26 files / 118.5 kB，README 是当期版本
+```
+
+## ⚠ npm 搜索搜不到，不等于包有问题
+
+magpie 的发现搜索是 `/-/v1/search?text=<query> opencode`。实测：
+
+| 查询 | 结果 |
+|---|---|
+| `text=magicrew` | total 1，命中 |
+| `text=magicrew opencode` | total 18500，**前 250 条里没有它** |
+| `text=letsmagic` | total 1，命中 |
+
+零下载的新包在混合查询里会被 opencode 生态的高下载包淹没。**能保证被发现的路径是 GitHub topic**
+（仓库已带 `magpie-plugin` / `magpie` / `opencode` → Discover → Unofficial）。搜索排名随下载量积累会好转。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "magicrew-auth",
-  "version": "0.3.5",
+  "version": "0.3.6",
   "description": "超级麦吉 / MagiCrew for magpie and OpenCode — one package, two providers: letsmagic.cn (国内) and magicrew.ai (international). Password or web-JWT sign-in, the account's own live model list, points balance, newcomer rewards, invite codes.",
   "type": "module",
   "main": "./index.mjs",

package/src/browser-login.mjs

@@ -13,22 +13,69 @@
 // 页面是我们自己开的，告诉 magpie 「别再开一次」。
 //
 // ⚠ 独立 profile 意味着用户要在这个窗口里登一次（没有他日常浏览器的 cookie）。
-//   所以 profile 目录**不删**，下次还能复用登录态：~/.cache/magpie/magicrew-login-profile
+//   **每次登录一个一次性 profile，用完删** —— 为什么不能复用，见下面 newProfileDir()。
 
 import { spawn } from "node:child_process"
-import { existsSync, readFileSync, mkdirSync } from "node:fs"
+import { existsSync, readFileSync, mkdirSync, readdirSync, rmSync, statSync } from "node:fs"
 import { homedir } from "node:os"
 import { join } from "node:path"
 
-/** 复用同一个 profile：第二次登录时里面已经有 cookie 了 */
-function profileDir() {
-  const d = join(homedir(), ".cache", "magpie", "magicrew-login-profile")
-  try {
-    mkdirSync(d, { recursive: true })
-  } catch {}
+const BASE = () => join(homedir(), ".cache", "magpie")
+
+/**
+ * 每次登录一个**一次性** profile 目录，登录结束就删。
+ *
+ * ⚠ 这里曾经刻意复用同一个目录（旧注释：`复用同一个 profile：第二次登录时里面已经有 cookie 了`），
+ *   那是个 bug —— 现象是「添加第二个账号时，网页正确弹出、然后瞬间关闭，
+ *   magpie 里也没多出账号」：
+ *
+ *     ① 复用目录里的 localStorage 还躺着**上一个账号**的 jwt + org；
+ *     ② 浏览器一打开，`waitForCreds` 第一轮（1.5 秒内）就读到它 → 判定「登录完成」→ 关窗；
+ *     ③ magpie 拿到的 accountId / uid 与已有账号一模一样，按契约
+ *        （同一 accountId + 同一 uid → 替换旧账号）不会新增账号。
+ *
+ *   一次性目录把这条路彻底堵死：读到的凭据只可能是本次登录写进去的。
+ *   代价是每次都要在这个窗口里重新登一次 —— 独立 profile 本来也没有他日常浏览器的 cookie。
+ */
+export function newProfileDir() {
+  const d = join(
+    BASE(),
+    `magicrew-login-${process.pid}-${Date.now().toString(36)}-${Math.random().toString(36).slice(2, 8)}`,
+  )
+  mkdirSync(d, { recursive: true })
   return d
 }
 
+/**
+ * 清残留：超过 maxAgeMs 的一次性 profile，以及历史上那个**复用**目录
+ * （`magicrew-login-profile`，里面装着别的账号的 cookie —— 正是上面那个 bug 的来源）。
+ * 只删本插件自己造的名字，别的一概不碰。
+ */
+export function sweepProfiles({ maxAgeMs = 2 * 3600_000 } = {}) {
+  let names = []
+  try {
+    names = readdirSync(BASE())
+  } catch {
+    return 0
+  }
+  let removed = 0
+  for (const name of names) {
+    const legacy = name === "magicrew-login-profile"
+    if (!legacy && !/^magicrew-login-/.test(name)) continue
+    const p = join(BASE(), name)
+    try {
+      // ⚠ 只动目录：同前缀的日志文件（magicrew-login-*.log）不是 profile
+      const st = statSync(p)
+      if (!st.isDirectory()) continue
+      // 遗留的复用目录不管多新都删；一次性目录只在过期后删（可能正有别的账号在登）
+      if (!legacy && Date.now() - st.mtimeMs < maxAgeMs) continue
+      rmSync(p, { recursive: true, force: true, maxRetries: 3, retryDelay: 200 })
+      removed++
+    } catch {}
+  }
+  return removed
+}
+
 /** 按平台找浏览器；找不到返回 null，调用方降级 */
 export function findBrowser() {
   const plat = process.platform
@@ -91,8 +138,11 @@ export async function launchLoginBrowser(url) {
   const exe = findBrowser()
   if (!exe) throw new Error("本机没找到 Chrome / Edge / Bravo / Chromium")
 
-  const dir = profileDir()
-  // ⚠ 上一次的残留会让这次「看起来起来了、其实什么都没做」：
+  // 先扫掉上一次登录留下的临时 profile（含历史复用目录），再开一个全新的
+  sweepProfiles()
+  const dir = newProfileDir()
+  // ⚠ 残留会让这次「看起来起来了、其实什么都没做」—— 一次性目录里通常没有，
+  //   但 sweep 失败、或目录被复用时它们就是根因，清一遍几乎不花钱：
   //   DevToolsActivePort  —— 不清掉，waitPort 会立刻返回一个已失效的旧端口
   //   SingletonLock / SingletonCookie / SingletonSocket / lockfile
   //                       —— 不清掉，新进程判定 profile 被占用，把 URL 转交给
@@ -128,6 +178,9 @@ export async function launchLoginBrowser(url) {
     try {
       child.kill()
     } catch {}
+    try {
+      rmSync(dir, { recursive: true, force: true, maxRetries: 2, retryDelay: 150 })
+    } catch {}
     throw new Error("浏览器进程起来了，但 8 秒内没写出调试端口 DevToolsActivePort（多半是 profile 被一个已退出的实例占着）")
   }
   return { port, dir, child }
@@ -229,16 +282,31 @@ const READ_CREDS = `(() => {
 
 /**
  * 盯着那个浏览器，直到页面里的 localStorage 出现完整凭据。
- * @returns {Promise<{jwt:string, org:string} | null>}
+ *
+ * `baseline` = 「窗口打开时就已经在 localStorage 里的那份」。传进来的话，
+ * 只有**跟它不一样**的凭据才算登录成功。一次性 profile 下它恒为空，
+ * 留着是第二道防线：万一哪天又改回复用目录，这条判据能挡住「读到上一个账号」。
+ *
+ * @param {{jwt:string, org:string}|null} [opts.baseline]
+ * @param {(port:number, host:string, expr:string)=>Promise<string>} [opts.probe] 测试注入用
+ * @returns {Promise<{jwt:string, org:string, name?:string} | null>}
  */
-export async function waitForCreds(session, hostFragment, { timeout = 300_000, interval = 1500 } = {}) {
+export async function waitForCreds(
+  session,
+  hostFragment,
+  { timeout = 300_000, interval = 1500, baseline = null, probe = evaluate } = {},
+) {
+  const base = baseline ?? session?.baseline ?? null
   const deadline = Date.now() + timeout
   while (Date.now() < deadline) {
     try {
-      const raw = await evaluate(session.port, hostFragment, READ_CREDS)
+      const raw = await probe(session.port, hostFragment, READ_CREDS)
       if (raw) {
         const o = JSON.parse(raw)
-        if (o?.jwt?.startsWith("eyJ") && o?.org) return o
+        if (o?.jwt?.startsWith("eyJ") && o?.org) {
+          const same = base && o.jwt === base.jwt && o.org === base.org
+          if (!same) return o
+        }
       }
     } catch {
       // 页面还在加载 / target 换了 —— 下一轮再试
@@ -249,13 +317,17 @@ export async function waitForCreds(session, hostFragment, { timeout = 300_000, i
 }
 
 /**
- * 关掉这个浏览器窗口。profile 留着，下次复用登录态。
+ * 关掉这个浏览器窗口，然后把这一次的临时 profile 删掉。
  *
  * 两条路都要走：
- *   ① CDP 的 `Browser.close` —— 走浏览器自己的退出流程，cookie 会被刷到磁盘
- *      （profile 里没有落盘的 cookie，下次登录还得再来一次）
+ *   ① CDP 的 `Browser.close` —— 走浏览器自己的退出流程，进程干净退出
  *   ② 兜底 kill —— ①在 2 秒内没关掉就强杀整棵进程树
- *      （Windows 上 kill() 只杀主进程，渲染/GPU 子进程会留着占住 profile）
+ *      （Windows 上 kill() 只杀主进程，渲染/GPU 子进程会留着占住 profile，
+ *        后面的 rmSync 也会因为文件锁失败）
+ *
+ * ⚠ profile 是**一次性**的，删掉是对的：里面只有这次登录的 cookie，
+ *   留着只会让下一次登录读到上一个账号（见 newProfileDir 的注释）。
+ *   删不掉不影响正确性 —— 下次 launch 会先 sweepProfiles()。
  */
 export async function closeSession(session) {
   if (!session) return
@@ -302,21 +374,35 @@ export async function closeSession(session) {
 
   // ② 兜底：还活着就强杀整棵进程树
   const pid = session.child?.pid
-  if (!pid) return
-  try {
-    if (process.platform === "win32") {
-      await new Promise((resolve) => {
-        const k = spawn("taskkill", ["/PID", String(pid), "/T", "/F"], { stdio: "ignore", windowsHide: true })
-        k.on("exit", resolve)
-        k.on("error", resolve)
-        setTimeout(resolve, 3000)
-      })
-    } else {
-      try {
-        session.child.kill("SIGKILL")
-      } catch {}
+  if (pid) {
+    try {
+      if (process.platform === "win32") {
+        await new Promise((resolve) => {
+          const k = spawn("taskkill", ["/PID", String(pid), "/T", "/F"], { stdio: "ignore", windowsHide: true })
+          k.on("exit", resolve)
+          k.on("error", resolve)
+          setTimeout(resolve, 3000)
+        })
+      } else {
+        try {
+          session.child.kill("SIGKILL")
+        } catch {}
+      }
+    } catch {}
+  }
+
+  // ③ 删掉这一次的临时 profile。文件锁通常要等子进程死透才放，
+  //    所以给它几次机会；删不掉就算了，下次 launch 会 sweep。
+  const dir = session.dir
+  if (!dir) return
+  for (let i = 0; i < 5; i++) {
+    try {
+      rmSync(dir, { recursive: true, force: true, maxRetries: 2, retryDelay: 150 })
+      return
+    } catch {
+      await new Promise((r) => setTimeout(r, 200))
     }
-  } catch {}
+  }
 }
 
-export const _internal = { READ_CREDS, profileDir, waitPort, evaluate }
+export const _internal = { READ_CREDS, newProfileDir, sweepProfiles, waitPort, evaluate }