feat(trigger-user-auth): 按触发人身份调用 CLI（默认关闭）

[xiaoxueSunn]

背景

同一个 bot 被多人使用时，botmux 调 lark-cli / bytedcli / git 用的是这台机器登录的是谁，而不是这条消息是谁发的。后果有三个：操作全部归到机器主人名下、别人的权限被无意借用、审计里写错人。

顺带修一个已存在的静默 bug：user token 只按 appId 存一份，同一个 bot 里第二个人 /login 会直接覆盖第一个人，之后所有人都在用最后授权那个人的权限，没有任何提示。目前没暴露只因实际上只有一个人在 /login。

改动

一条规则：CLI 调用用本轮消息发送者自己的凭证，或者没有；唯一允许的降级是「bot 自己的 tenant 身份」（不属于任何人），绝不退回到另一个人的登录态，owner 也不例外。

• token 按 (app, 授权人) 存储：user-token-<appId>-<openId>.json。归属以 user_info 回读的真实授权人为准，不信任发起人声明——/login 链接被转给别人点时按真实授权人落盘并明确告知。删掉 FEISHU_USER_ACCESS_TOKEN 全局旁路（设一次就让所有 bot、所有人共用一个身份，且无痕迹）。
• 凭证走文件不走 env：一个会话是一个长驻 CLI 进程，env 在 spawn 时被内核定死。env 注入会把身份冻结在起会话那个人身上，之后任何人发言都还在用他的权限。文件每次调用重读，换人零成本且不重启会话。
• 每轮发布身份：挂在 noteTurnReceived（源码注释里明确的 per-message acceptance point）。取不到当轮发送者的 token 时改写文件，不是「不刷新」——留着等于下一条命令用上一个人的身份跑。无人类发送者的轮次（定时/hook/会议/bot 交接）同样不给身份，且不借用「最后一个说话的人」。
• 凭证绑定轮次：daemon 在消息被接收时发布凭证，但 CLI 有自己的队列。A 的轮次还在跑时 B 发消息，B 的凭证会覆盖文件，A 后续的工具调用就用了 B 的权限——普通的 type-ahead 就能触发。daemon 单独关不掉这个窗口（输入直接进 worker，worker 不等 daemon）。所以两边都声明轮次：凭证带上所属 turnId，worker 发布正在执行的 turnId，不一致就拒绝执行。代价是 A 轮次尾部的调用会失败——这正是这个功能的取舍：命令失败可恢复，用错人的权限不可恢复。
• git 归因：GIT_ASKPASS 问被 wrapper 包过的 bytedcli，自动继承当轮身份。
• bot 级开关，默认关闭，缺失即关闭。配置里刻意没有「用机器登录态」这个选项，写了会被明确拒绝并说明「永不可用」。
• 两个 CLI 都支持按人鉴权，机制不同：lark-cli 注入 OAuth user token；bytedcli 走 ByteCloud SSO 设备码流程，每人一个私有 HOME（~/.botmux/data/bytedcli-home/<openId>）。不对称的只是未授权时的兜底：lark-cli 可以降级到 bot 身份，bytedcli 没有 bot 身份，所以即使配 fallback=bot-identity 也返回 fail。
• bytedcli 存目录不存 JWT：ByteCloud JWT 只活 2 小时，底层登录活约 3 周，bytedcli 内部自动续期。实测跨过期点：01:48:03 过期的 token，01:49 再取拿到 iat=01:48:08 的新 token，无人介入。存 JWT 会让人每 2 小时重扫一次码去续一个根本没过期的东西，所以每轮现取，只有 3 周的登录真到期才打扰人。
• 无凭证 = 拒绝执行，不是「裸跑」：见下方「一处我此前判断错误」。

一处我此前判断错误（评审重点）

我此前在代码注释和结论里都写过「不给 env，lark-cli 就以 bot 身份跑」。这是错的，而且正是它让这个功能在未授权路径上完全失效。实测：

env -u LARKSUITE_CLI_APP_ID -u LARKSUITE_CLI_USER_ACCESS_TOKEN lark-cli whoami
→ identity: user, onBehalfOf: <本机登录的那个人>

不给任何 env，lark-cli 读的是磁盘登录态（~/Library/Application Support/lark-cli/<appId>_<openId>.enc），以机器主人的身份执行。原 wrapper 在没有凭证文件时直接 exec 真实工具，等于每个未授权的人都在用机器主人的全部权限跑命令——无声无息，审计里还写着机器主人的名字。根因：我最初那次 --as bot 验证跑在已登录的机器上，所以假结论看起来被验证过。

正确做法已实测确认：给 LARKSUITE_CLI_APP_ID + LARKSUITE_CLI_APP_SECRET 才会真的解析成 identity: bot（本机有用户登录也一样），而且此时再加 --as user 返回 token_missing，不会绕回磁盘凭证——所以 bot 身份是个可靠的地板，不是 agent 能绕开的默认值。

现在凭证文件带显式 mode（user / bot / denied）。文件缺失、为空、写了一半、或者从环境变量注入 mode，一律拒绝执行（exit 77），并在 stderr 说清「缺谁的授权 + 发哪条命令去补」——只说「拒绝」的话，命令失败的人只会反复重试同一条。

第二处判断错误：bytedcli「不支持按人鉴权」

同一类错误又犯了一次。我此前写「bytedcli 只有 SSO 个人登录，没有按人鉴权的路径」，并据此让它无条件 fail、还建议把它从默认工具列表里摘掉。这个结论我从来没验证过。 实测：

BYTEDCLI_USER_CLOUD_JWT=<bogus> bytedcli auth userinfo
→ HTTP 401 invalid jwt token        （注入的 JWT 优先，坏 JWT 直接失败，不会静默回落到本机登录态）

HOME=<空目录> bytedcli auth status
→ not logged in                      （本机明明登录着）

所以 bytedcli 既有可用的注入变量，也有真正的 HOME 隔离，还有完整的非阻塞设备码流程（auth login --begin 返回链接 + resume token，--complete 收尾）。缺的只是 botmux 这边没接——是没做，不是做不了。本 PR 已补上。

两次错误的共同点：在一台已登录的机器上观察一下，就把现象当成工具的能力边界。这轮后续的结论（HOME 隔离、JWT 优先级、自动续期）都是在干净环境里实测的。

借鉴与如实说明

git 那三条加固来自读 @byted/orchestra 已发布二进制（仓库无权限），我们原实现有同样暴露：调 bytedcli 前置 GIT_CONFIG_COUNT=0 GIT_SSH_COMMAND=false 防递归、bytedcli 取不到 JWT 时 HTTP 兜底、insteadOf 把 SSH 远端改写成 HTTPS。端点与 host 走配置不写死（本仓库有域名门禁）。

本期不做内核级凭证隔离。 现状是：不开文件沙盒时，agent 与 botmux 跑在同一个系统用户下，有能力直接读取 ~/.botmux/data/ 里其他人的 token 文件。按人存储解决的是归因与覆盖问题，不解决这个。

替代方案是 system prompt 里的 <botmux_credentials> 约束块——这是行为约束不是安全控制，挡不住有意的用户，也挡不住 prompt injection。它针对的是最可能真实发生的情况：agent 排查鉴权失败时顺手 grep 数据目录。因此块里同时给出替代动作（凭证已注入、失败就提示 /login），光写禁令会让排查中的 agent 无路可走。

内核隔离已在 macOS 上验证可行（cat / .tmp sidecar / spawn 后新建文件全部 DENIED），留待下一期；Linux 侧因为 credential-only bwrap 顺带带 PID/IPC namespace 隔离，需要先实测副作用。

影响面

• 默认关闭时行为不变。特意确认过一处：早期实现里 noteTurnReceived 的 await 是无条件的，会让每个 bot 的每一轮多让出一个 microtask，重排 single-flight 依赖的并发顺序（daemon-rename-route 因此失败）。已改成同步判断，关闭的功能不改变任何时序。
• 三处内部 token 消费点各自的正确答案不同：图片下载跟随本轮 sender（本来就有 app→user fallback）、文档评论用订阅创建者（长期任务无当轮 sender）、feed 打标固定 owner（那是 owner 收件箱里的东西，bot 没有收件箱）。
• feed-group 走 resolveOwnerUserToken：存量安装的 owner token 存在未标注归属的旧文件里，严格按人取会让标签功能升级后静默失效。这道口子只放宽「哪个文件算 owner 的」，不放宽「可以借谁的身份」。owner 本身改为 getOwnerOpenId() 派生，ownerOpenId 只作兜底——那是 bots.json 的原始字段，实际部署里几乎没人填（评审那边 55 个 bot 一个都没有）。
• 存量已授权的人需要重新 /login 才能拿到新增的文档 scope。这是 OAuth 的性质，不是可以绕过的实现细节。
• ZDOTDIR 作用于整个 CLI 进程，所以该会话里 spawn 的任何 zsh 都会先读 shim 目录的启动文件。shim 会先 source $HOME 下的同名文件，功能等价；但如果用户的 .zshrc 依赖 ZDOTDIR 指向 $HOME，行为会变。只影响开了 triggerUserAuth 的会话。
• turn 绑定依赖沙箱才不可绕：agent 自己写 <sid>.turn 就能复活旧凭证，沙箱把它授成 readOnly 挡住了这条路。与本 PR「本期不做内核级隔离」的自述一致，此处写明以免被当成独立保证。

验证

• npm run build、tsc --noEmit、audit:domains 全部通过
• 全量单测 21281 passed / 1 failed，唯一失败是 bun-shim-parity——在干净 origin/master（独立 worktree + 真实拷贝的 node_modules，非软链）上同样失败，已直接复现，与本 PR 无关。该用例断言 setTimeout(…, 100) 与 vi.waitFor({timeout: 100}) 的边界相等情形，本质是顺序竞争。
• 期间另有 codex-app-threads / dsh-question-bridge / platform-tunnel-data-bridge 偶发失败：单跑都通过，且本 PR 未触碰对应文件。dsh-question-bridge 那次我一开始没复现就归因为「无关抖动」，这不严谨——补跑两分支各 3 轮同组合、均 0 失败之后才敢这么写。
• 真机端到端已验（独立 daemon 挂 business-agent，隔离 HOME，不影响其余 13 个 bot）：飞书群里真实消息触发 → wrapper 安装 → 凭证按发起人下发 → lark-cli whoami 返回 identity: user / 代操作用户为发起人 / identitySource: strict_mode（strict_mode 证明用的是注入凭证而非本机磁盘登录态）；未授权者同一条命令走 MODE='bot' 兜底；凭证文件里的 BOTMUX_IDENTITY_TURN 与 worker 正在执行的 .turn 完全一致。
• 真实内核 / 真实 shell 验证：wrapper 经真实 /bin/sh 的 5 种拒绝形态、真实 bash -lc / zsh -lc 登录 shell 的 PATH 竞争（含阴性对照）、真实 bytedcli 的 HOME 隔离与 JWT 自动续期（跨过期点实测）、真实 buildSeatbeltProfile 的跨会话拒读。
• 新增约 175 个测试。

未验证

• 多人并发未做真机实测：两个真人在同一会话轮流触发、以及「A 的轮次执行中 B 插话」的轮次绑定，只有单测与构造验证，没有第二个真人配合过。阻碍是 /login 走 canOperate（只认 allowedUsers），协作者默认发不了。
• Linux 侧 credential-only 的 PID/IPC namespace 副作用未测（devbox Kerberos 票过期）
• Windows 为 fail-closed 平台，未在 Windows 上运行
• 新增的 7 个默认文档 scope 尚未在「后台未启用该 scope 的 app」上验证过是否会让整个授权链接 20043 失败。历史上那次 20043 的根因是 scope 名拼错（docs:document.comment 并不存在），「未启用会连带失败」是当时顺手写下的预防性判断、无实测证据。authorize 接口未登录时只返回 302 跳登录页，无法自动化验证这一条。

[deepcoldy]

感谢这个 PR —— 安全方向的设计和其中两处自我纠错（「不给 env 不等于 bot 身份」「bytedcli 并非不支持按人鉴权」）都很扎实。我们做了自动评审并实际跑了验证，结论是建议修改后再合：2 个阻断项 + 若干小项。以下每条都附了判据，方便你复核。

先说明基线：已在本地把分支 rebase 到最新 origin/master（8d2986c71，原基线落后 5 个 commit），零冲突，range-diff 17/17 全等。bun run build ✅、tsc --noEmit ✅、PR 相关 14 个测试文件 601 测试全绿、CI 4/4 绿。以下问题都不是 rebase 引入的。

---

🔴 1. /login 只写 per-person 文件，但一批读者仍走 no-openId 路径 —— 授权了也读不到

探针从生产入口进（generateAuthUrl → handleCallbackUrl），真实回调后盘上只有 user-token-<app>-<openId>.json，然后：

resolveUserToken(app, sec, brand)          => null      ← 无 openId
getTokenStatus(无 openId)                   => 未登录（无 User Token）
getFeedGroupAuthStatus(无 ownerOpenId)      => { authorized: false }

受影响的读者有 5 处，其中 3 处是功能关闭时的默认路径，所以「默认关闭」挡不住：

位置	说明
command-handler.ts:3025	/subscribe-lark-doc 前置检查
im/lark/client.ts:1403	图片/文件下载兜底（feature OFF 分支）
im/lark/doc-comment.ts:373	文档评论 drive API（feature OFF 分支）
dashboard/feed-groups.ts:37 + dashboard-ipc-server.ts:5285	Dashboard 标签，传 cfg.ownerOpenId
im/lark/audio-transcribe.ts:109	downloadMessageResource 没传 senderOpenId（对比 session-manager.ts:654 传了）

触发时序：老 per-app 文件还有效时不炸（legacy 读路径完好）；等它过期后本人重新 /login，新 token 进 per-person 文件、no-openId 读者永远 null——人已经授权了、功能仍坏、且零报错。而 /login、/login tags、/subscribe-lark-doc 三条命令路径现在全都归属 senderId，所以这是每个重新登录的人必踩，不是边缘时序。/subscribe-lark-doc 还会死循环：授权完重试 → 3025 行仍是 null → 再提示授权。

补充一个存量数据点：我们这边 bots.json 里 55 个 bot 没有一个配了 ownerOpenId（该字段直接读 bots.json，无派生），开了 feed-group 标签的那几个也没有 —— Dashboard 徽标那条会直接走 undefined。

修法建议：改读者，不建议双写 per-app。 双写有两个实际问题：① refreshToken 只写 per-person，双写出来的 per-app 副本几小时后就是陈旧快照；② feed-group 是 owner 收件箱侧边栏，双写等于用「最后登录那个人」的 token 去操作 owner 的侧边栏，多人 bot 上会把分组建到错的人那里。具体改动都很小：3025 传 message.senderId；1403 无条件传 senderOpenId；373 去掉 feature 门控（订阅记录的 ownerOpenId 是 master 上就有的老字段）；feed-group 改用 getOwnerOpenId()，解析不出时写操作报错而不是借别人的 token。

另外建议补一条回归测试：「/login 之后，no-openId 读者仍能拿到 token」。我们试着给 /login 加双写兼容做变异，user-token-* 那 29 个测试全绿 —— 说明这条路径目前完全没有覆盖。

🔴 2. tmux / zellij / zmx 后端会把 identity wrapper 从 PATH 里丢掉，静默回退机器身份

worker.ts:14475 把 wrapper 目录 prepend 到 childEnv.PATH，但 tmux 系 pane 走 shellCommandArgv，shell 带 -i（zsh 是 -l -i）先 source rcfile，rcfile 常见地重建 PATH（fnm / nvm / pnpm），之后 shellWrapperScript（tmux-backend.ts:783）只重新 prepend botmuxBinDir 一个目录，identity 目录没有同等待遇。buildBotmuxEnvAssignments 的注释本身就写着「Everything else (PATH, HOME, NVM, locale, …) comes from the user's rcfile」。

用真实 shell 复现（含阴性对照）：

rcfile 重建 PATH  → !!! REAL lark-cli RAN (machine identity) !!!   exit=0    ← fail-open
rcfile 不动 PATH  → identity wrapper: refused                       exit=77   ← 对照成立

这正是 refuse instead of falling back to the machine login 那个 commit 要消灭的行为，却在受支持的后端上 fail-open 了。同类还有 herdr（自己拼 export PATH）和远端后端（riff/mojo，wrapper 目录在本地、远端根本不存在）。我们 fleet 目前 54 pty + 1 riff + 0 tmux，所以今天没有线上影响，但配置一改就会静默失效。

建议：pane 脚本给 identity dir 同等的重新 prepend；或者在不支持的后端上拒绝启用并明确报错（远端后端可以只在文档写明「本期仅 pty/direct-spawn 支持」）—— 关键是不要静默。

🟡 小项

• doc-comment.ts 两处 driveApiCall 漏传 fileTokenForIdentity：resolveDocFile 里的 wiki get_node（162 行附近）和 hydrateTruncatedReplies（671 行附近）。feature ON 时这两处 actingUserOpenId 是 undefined → user token 取不到 → 静默回退 tenant，归因就丢了。PR 自己的注释写了「a missed call site cannot silently revert」，可以顺手补上。
• lookupAuthorizedUserName（user-token.ts:262）brand 硬编码 'feishu'，调用方 turn-cli-identity.ts:192 没传；同族的 listAuthorizedUsers 两个调用点都正确传了 normalizeBrand(cfg.brand)。Lark 品牌 bot 的拒绝文案会丢人名（退化成「你」），不影响安全语义。
• renderGitAskpassScript 上方有两段逐字重复的 JSDoc，前一段还缺 exchangeUrl 的说明，删掉前一段即可。
• dashboard-ipc-server.ts:5264 生成授权链接也传了空的 cfg.ownerOpenId，导致 pending.openId 缺失 —— dashboard 这条路径就没有「链接被转给别人点」的 mismatch 校验（命令路径是有的）。和 feed-group 的 owner 解析一起改就行。
• turn 绑定可被 agent 自己写 turn 文件绕过（实测伪造 <sid>.turn 就复活了旧凭证）。沙箱把它授成 readOnly 挡住了，这与 PR 自述「本期不做内核级隔离」一致、不算问题，只是建议在文档里写明「turn 绑定依赖沙箱才不可绕」。

---

已实测确认为真、不需要再自证的部分

• wrapper 用真实 /bin/sh 跑通 5 项：轮次匹配放行 / 轮次不匹配拒 77 / 文件缺失拒 77 / 空文件拒 77 / 截断文件拒 77。注入 BOTMUX_IDENTITY_MODE=user（哪怕自带 token）绕不过，清空 SESSION_DATA_DIR 也只会拒绝 —— 绝不裸跑真实工具，你那个核心修正确实成立。
• 「关闭时不引入 await 边界」经变异证实是承重的：把同步闸改成无条件 await，daemon-rename-route 立刻转红，还原后复绿。这条不是空话。
• 凭证边界 prompt 块两条路径都覆盖（claude 家族走 buildArgs，其余 inline-prompt CLI 走 buildNewTopicPrompt）。
• 沙箱 grant 逐文件授权、不授 cli-identity/ 父目录、readOnly —— 设计正确。

---

以上是自动评审的初步意见，可能有误判，最终以维护者审阅为准。阻断项主要是 1 和 2；其余小项顺手修即可。辛苦！

[deepcoldy]

二轮复审（f28547290，新增 4 个 commit）。先说结论：F5（login shell 里 wrapper 被挤掉）已经修好了，而且修法比我们上轮建议的更根本；F1（/login 后 no-openId 读者读不到 token）原样未动，仍是唯一阻断项。

基线：master 未动，仍是 8d2986c71。rebase 零冲突，原 17 个 commit range-diff 全等，新增 4 个。bun run build ✅、tsc --noEmit ✅、PR 相关测试文件全绿（本机有一处红，见下，是环境问题不是回归）。

---

✅ F5 已修 —— 并且我们上轮的诊断只挖到一半

我们上轮报的是「tmux pane 的 rcfile 重建 PATH 之后只重新 prepend ~/.botmux/bin」。你在真机上独立发现的根因比这深一层：agent 的工具调用本来就走 login shell（bash -lc / zsh -lc）→ /etc/zprofile → path_helper 重建 PATH 并把原有内容追加在后面，wrapper 目录从第 1 位掉到第 12 位。

这条链路 pty 后端同样走 —— 所以我们上轮那句「fleet 0 台 tmux ⟹ 今天没有线上影响」是错的，54 台 pty 一直都是坏的。这个更正记在我们头上，顺着 tmux 那条线查完就收工，没回头问 pty 会不会也中招。

installLoginShellPathShim 的修法我们两边都用真实 shell 独立验证过，都带阴性对照：

• 有 shim：bash -lc / zsh -lc / bash -c / zsh -c 四种形态都解析到 wrapper
• 无 shim：解析到真实工具（对照成立，测试不是因为别的原因通过的）
• 额外一点：本机 /etc/profile 对 root 是覆盖式 PATH= 赋值（比 macOS path_helper 的追加式更狠，继承的 PATH 整个丢掉），shim 照样有效 —— 因为它是从 BOTMUX_IDENTITY_BIN 重建而不依赖继承值。比测试断言覆盖的场景更 robust。

整条链也核过了：worker 设三个变量 → child-env 白名单让它们过 tmux pane 的 scrub → codex 用 shell_environment_policy.set 逐键透传（没用 inherit="all"，面窄，这个选择是对的）→ shim 在 path_helper 之后重新 prepend。installedAny=false 和 shim 安装失败都有显式告警，静默 fail-open 那条堵上了 —— 这一条尤其重要，因为它正是真机上最难被发现的形态。沙箱侧也没有新缺口（seatbelt subpath / bwrap --ro-bind 覆盖 .bin 下的 shell/ 子树，且 shim 安装早于 buildFsPolicy，bind 时文件已存在）。

一个 watch-item（不阻断）：ZDOTDIR 作用于整个 CLI 进程，所以这个会话里 CLI spawn 的任何 zsh 都会改读 shim 目录的启动文件。shim 会先 source $HOME 下的同名文件，功能等价；但如果用户的 .zshrc 里有依赖 ZDOTDIR 指向 $HOME 的逻辑，行为会变。只影响开了 triggerUserAuth 的会话，可以接受 —— 建议在 PR 描述里点一句就行。

🔴 F1 仍未修 —— 唯一阻断项

在新 head 上重跑了探针，输出与上轮逐字相同：

/login 回调后落盘：user-token-<app>-<openId>.json （只有这一个）
resolveUserToken(app, sec, brand)      => null
getTokenStatus(无 openId)               => 未登录（无 User Token）
getFeedGroupAuthStatus(无 ownerOpenId)  => { authorized: false }

5 个读者逐字未改：command-handler.ts:3061、client.ts:1403、doc-comment.ts:373、dashboard-ipc-server.ts:5285、audio-transcribe.ts:109。其中 3 个在功能关闭时的默认路径上，所以「默认关闭」挡不住。上一条评论里的修法建议仍然适用（改读者、不双写），另外建议补一条「/login 之后 no-openId 读者仍可用」的回归测试 —— 我们试过给 /login 加双写做变异，user-token-* 那 29 个测试全绿，说明这条路径目前零覆盖，光看 diff 判断不出来改没改对。

上一条里的 F2/F3/F4/F6/F7/F8 本轮也都还没动。

🟡 新加的阴性对照测试建议调整断言

test/cli-identity.test.ts:252「without the shim, bash resolves the real tool」在我们机器上红、CI 上绿（1 failed | 54 passed）。

根因不是你的代码：这台机器以 root 运行，/etc/profile 有一个 root 专属分支把 PATH 覆盖成不含 /usr/local/* 的固定串，于是 bash -lc 之后 realDir 和 wrapperDir 都不在 PATH 里，command -v faketool 什么都找不到，execFileSync 直接非零退出。断言要的是「解析到 realDir」，实际是「什么都解析不到」—— 阴性对照自己的前提在这台机器上不成立。

建议把断言从「解析到 realDir」弱化成「wrapper 没有赢」（catch 住 command-not-found 的 throw，视为合法阴性，断 expect(resolved).not.toBe(wrapperPath)），而不是加前置条件 skip。理由是 botmux 的 fleet 自己就跑 root —— 这不是假想环境，是这个项目的实际运行环境，skip 会让阴性对照恰好在最该跑的机器上不跑。弱化之后两种环境都成立（正常机器解析到 realDir、锁 PATH 的机器解析为空，都满足「wrapper 没赢」），而它要防的那个回归（无 shim 时 wrapper 反而赢了 = 阳性测试失去意义）照样能抓住。

/login scope 改动

7 个 scope 名逐个对过 src/setup/lark-scopes.json，全是真的；DEFAULT_SCOPES ∪ extraScopes 去重，/subscribe-lark-doc、/login tags 两条专项流程不受影响；--scope 走同一份目录校验。只读、排除 contact/calendar 的取舍我们认可。存量已授权的人需要重新 /login 才能拿到新 scope，这是 OAuth 的性质，只是值得在描述里提一句。

「drop the guessy notice」删得对 —— 那个通知在 agent 还没决定用哪个工具时就触发、还是一次性的，而 wrapper 的 stderr 是逐工具、逐次、当场的精确信号，通知确实是它的劣化副本。

---

以上仍是自动评审的初步意见，最终以维护者审阅为准。目前只剩 F1 一个阻断项，其余是建议。辛苦！

[deepcoldy]

三轮 review + 双人交叉复审收敛，0 阻断。本次已在维护者侧解决与主干的两处冲突（claude-code.ts 的 buildArgs 参数列表、session-manager.ts 因 #998 分块重构），并补上 inline prompt 路径的凭证边界块测试（原先该落点零覆盖）。CI 9/9 绿。

[github-actions]

🚀 Released in v3.20.0