Repository navigation
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
临时关闭并重新打开,以在 fork 中启用工作流后重新触发 CI。 |
|
再次触发 fork Actions 初始化后的 CI。 |
|
Actions workflow 已注册,重新打开以触发完整 CI。 |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1da3d27eac
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| @@ -54,1536 +55,1638 @@ | |||
| "node-pty", | |||
| ], | |||
| "packages": { | |||
| "@electron/asar": ["@electron/asar@3.4.1", "", { "dependencies": { "commander": "^5.0.0", "glob": "^7.1.6", "minimatch": "^3.0.4" }, "bin": { "asar": "bin/asar.js" } }, "sha512-i4/rNPRS84t0vSRa2HorerGRXWyF4vThfHesw0dmcWHp+cspK743UanA0suA5Q5y8kzY2y6YKrvbIUn69BCAiA=="], | |||
| "@electron/asar": ["@electron/asar@3.4.1", "https://bnpm.byted.org/@electron/asar/-/asar-3.4.1.tgz", { "dependencies": { "commander": "^5.0.0", "glob": "^7.1.6", "minimatch": "^3.0.4" }, "bin": { "asar": "bin/asar.js" } }, "sha512-i4/rNPRS84t0vSRa2HorerGRXWyF4vThfHesw0dmcWHp+cspK743UanA0suA5Q5y8kzY2y6YKrvbIUn69BCAiA=="], | |||
There was a problem hiding this comment.
Regenerate the lockfile against the public registry
In a fresh public CI checkout, bun install --frozen-lockfile consumes these persisted tarball URLs; this diff rewrites 817 package entries to bnpm.byted.org, while bunfig.toml:3-20 explicitly documents that public runners cannot resolve this internal host and that a registry setting cannot override URLs already baked into the lockfile. Regenerate bun.lock with --registry https://registry.npmjs.org/ so installation does not fail before any build or test runs.
AGENTS.md reference: AGENTS.md:L23-L23
Useful? React with 👍 / 👎.
| "test": "vitest run --project unit", | ||
| "test:all": "vitest run", | ||
| "test:e2e": "vitest run --project e2e", | ||
| "test:midscene": "bun run dashboard:bundle && midscene-test test/midscene", |
There was a problem hiding this comment.
Compile the Dashboard entry before spawning it
On a clean checkout, this command only runs dashboard:bundle, which creates dist/dashboard-web/ but not the untracked dist/index-dashboard.js; the setup then immediately tries to spawn that missing file at test/midscene/midscene.config.ts:96, so the documented bun run test:midscene exits before the Dashboard becomes ready unless the user happened to run a full build previously. Run the TypeScript build first or launch an entry that exists in a clean tree.
Useful? React with 👍 / 👎.
|
前两轮均在安装依赖前遭遇 GitHub runner 的 npm DNS 解析故障;重新触发一组新 runner。 |
|
Fork CI 已全部通过,接下来提交上游 PR。 |
test/worker-kimi-effort.integration.test.ts 原用 vitest 专有的 expect.poll() 等待 假 CLI 写出 effort 文件;bun:test 无此 API(Bun 1.4 实测 typeof 为 undefined), bun 测试腿在到达断言前即以 expect.poll is not a function 失败。vitest 必需门禁一直 绿、真实覆盖未丢,但每个无关 PR 的 advisory bun 腿都挂同一条红。 改为运行器无关的 15s deadline 轮询(50ms 间隔),超时仍把 worker 日志拼进报错; bun test 与 vitest 两边均恢复通过。另在 test/bun-runner-selectors.test.ts 增加 AST 全仓守卫,禁止再出现 expect.poll(含 expect['poll'] / expect[`poll`] 计算形式); 刻意禁止而非把文件加入 defer 名单——该调用在成功路径上,defer 会丢失真实覆盖。 纯测试改动(2 文件 +83/-2,零 src),影响面仅 advisory bun 腿与 vitest unit。 Co-Authored-By: Claude Code <noreply@anthropic.com>
botmux send --response-kind final 已把本轮最终答案投递飞书后,普通 (非 unified reply)路径的 marker 只写 responseKind='final'、缺 replyCardResponseKind;兜底抑制门只认后者,长度启发式又因中英文内容 长度不同判不覆盖,导致同一轮最终答案双发(中文已发、英文 summary 再发一次)。 统一在时间窗内识别两种 final marker(responseKind 或 replyCardResponseKind 为 final)即抑制;managed-card 的 progress/auxiliary 标记与长度启发式行为不变。覆盖所有走该门的 CLI (emitReadyTurns / emitReadyCodexTurns),无需改任何适配器。 补 5 条回归用例;回退修复后 CN/EN send 与 transcript 两用例会失败, 确认断言非恒绿。 Co-authored-by: huangyuhang.edu <huangyuhang.edu@bytedance.com> Co-authored-by: Claude Code <noreply@anthropic.com>
deepcoldy#1505 收尾:显式 responseKind='final' marker(含纯图片/语音等无 contentLength 形态)在所有 replyDelivery 下均视为本轮答案已投递; markerSetDuplicatesFinal 中「无 contentLength 从不抑制」的宽松口径 仅适用于 progress/无 kind marker。纯注释,无逻辑改动。 Co-Authored-By: Claude Code <noreply@anthropic.com>
…eepcoldy#1466) 双审(Claude + pi)十轮收敛,0 阻断。 - 授权继承续跑:TraeX 长任务遇非业务中断(输出超限/限流/连接/上游)以原用户身份受控续跑;ambiguous 中断(cli_exit/rpc_engine_dead/daemon_restart)一律 awaiting_user 不自动重放;TTL 从首次中断起算;含 startMode 区分、存量 backoff 升级迁移、worker 退出 generation fence。 - 定时任务:claimRun 原子认领防一次性任务重复触发;创建者身份收紧为 daemon 认证当前轮次(含无 owner 会话/沙箱 attestation/在途一次性任务授权保留)。 - RPC actor:cliPid/enginePid 双信任根 + 进程谱系/procStart 复核;跨活会话拒绝。 机器开关默认关闭;CI 9/9 于 rebase 后 head。
Co-authored-by: genglei.88 <genglei.88@bytedance.com>
Fixes deepcoldy#1487 独立二进制 bun build --compile 的模块图位于虚拟 /$bunfs/root,旧实现用 import.meta.url 拼出扩展路径并经 --extension 交给外部独立安装的 pi 进程,该路径在 pi 侧不存在,而 pi 把扩展加载失败当作致命错误直接退出并触发崩溃保护;首条消息含换行、超过 4096 字节或含 控制字符(走 deferred initial prompt 扩展)时必现。 改为把扩展本体写成手写的纯 JS、自包含真源 pi-initial-prompt-extension.mjs(无仓库依赖、 无 TS 语法),构建期由 scripts/generate-pi-initial-prompt-extension.mjs 只读真源原始字节、 以 JSON.stringify 生成并提交字符串常量模块 pi-initial-prompt-extension-data.ts; preparePiInitialPromptArg 落盘时直接写入该常量。落盘文本不经过任何转译器,因此 tsx 源码 直跑(bun run daemon)、node dist、bun 原生与 --compile 二进制写出的扩展逐字节一致、 外部 pi 均可加载,从根上规避运行时对函数 .toString() 在 tsx 下捕获注入 helper(__name) 这一整类问题。 - 扩展仍写入首条提示词已有的 0700 会话目录,复用既有只读沙盒绑定与会话关闭清理 (pi.ts 同步把扩展加入 cleanupPaths),无新依赖、无共用层改动。 - build 在 tsc 前重生成常量,幂等;新 .mjs 为构建期资产,不进入 dist。 - 测试:常量/真源 drift 守卫;剥注释后的自由转译 helper 黑名单;tsx 生成、无转译器 加载并真正调用扩展 factory 的跨加载方用例(两个独立子进程覆盖忙碌 followUp 与空闲 直投及一次性消费语义),并含一个引用自由 __name 的坏扩展正对照;保留独立二进制编译 产物加载用例。 Co-Authored-By: Claude Code <noreply@anthropic.com>
把会话页手动「清理空闲」产品化为可配置的无人值守定时清扫,默认关闭。 - dashboard 进程(全机唯一)按配置周期扫描,候选判定与关闭动作完全复用手动按钮的同一套逻辑(session-cleanup.ts + 代理各 daemon 的 /close),只关空闲/休眠超过阈值的会话;运行中、有 TUI 提示、锁定、待处理仓库、有人 attention、休眠但 web 终端仍开的一律不碰 - 全局设置「定时任务」新增开关 + 阈值(24H/72H/7d,默认 7d)+ 检查间隔(默认 60 分钟,最小 5),坏值丢弃回退默认不崩溃,翻动即时生效无需重启 - 三处 close fan-out 统一带 60s deadline,半死 daemon 不再卡住整轮串行清扫;tick 单飞,慢清扫跨过间隔不重入 - 新 close 路由消费点已登记 close-consumer 守卫;纯新增 global config key,daemon 解析后忽略 验证:tsc 0 错;新增/邻接测试全绿(含同步盖章断言与单飞并发用例,变异验证钉红);bun 腿 16 绿;相对最新主干 rebase 零冲突、patch-id 一致;CI 9/9 通过。 Co-Authored-By: Claude Code <noreply@anthropic.com>
上游 openai/codex#44732 将文件夹信任弹窗的确认项由 \"Yes, continue\" 改为 \"Trust and continue\"(新 onboarding trust_directory 组件)。worker 启动时 自动确认信任弹窗的正则只认旧文案,升级后会话会卡在信任弹窗、停留在 awaitingFirstPrompt。 - TRUST_DIALOG_PATTERN 增加 \"Trust and continue\" 分支,保留 Claude Code 与旧版 codex 文案;新增对应回归测试(仍走 400ms 延迟 Enter 与一次性围栏) - 新文案为单个渲染 span,与旧选项同一编号行结构,可在单个 PTY chunk 完整命中; hooks 审核菜单 \"Trust all and continue\" 不连续包含新串,无误匹配 版本说明:新文案自上游 0.156.0-alpha 起出现(npm latest 0.155.x 仍为旧文案), 现网内置 codex 0.153.4 暂不会遇到,本修复先行合入,待 codex stable 0.156 普及后自然生效;旧文案分支保留以兼容存量版本。 验证:变异测试(回退正则则新测试失败)、信任/启动相关定向与邻近单测、 tsc、build 均通过,CI 全绿;并在 codex 0.156 alpha 真机 PTY 验证新文案 单 chunk 命中,带 --dangerously-bypass-approvals-and-sandbox 与 --dangerously-bypass-hook-trust 启动仍弹窗且可被识别。 Co-authored-by: genglei.88 <genglei.88@bytedance.com> Co-Authored-By: Claude Code <noreply@anthropic.com>
## 改动 新增小米 MiMoCode CLI(`mimo`)适配器,`bots.json` 配 `cliId: "mimocode"` 即可接入。 - 将 `opencode.ts` 重构为 `createOpenCodeLikeAdapter` 工厂(OpenCode 对外行为不变),MiMoCode 复用其 SQLite v1 会话存储、writeInput 提交验证、会话续接与 ask-hook 插件;新增 `mimocode.ts`(二进制 `mimo`、XDG 数据根、目录级 authPaths、`--trust` 跳过工作目录信任提示)与 `services/mimocode-paths.ts`(XDG 兼容路径)。 - 接入全部注册点:CliId、registry、显示名、setup 序号、模型候选、启动带 model 集合、ask-hook、能力矩阵、本地打开器、skill 安装、session-discovery 等;README 中英同步;删除 i18n 中从未被引用的 setup.supported_clis 死代码。 - setup 数字序号:'30'=minimax 已随 v3.21.0 发布,保持原位;mimocode 追加为 '31',并在 resolveCliId 测试锁定已发布序号,防止后续插位。 - 合并主干 deepcoldy#1428 后新增的模型-only 穷举评估表:mimocode 作为 OpenCode fork 且尚无原生程序验证零工具隔离,按 opencode2/mtr 同例登记为 verification_required,不启用执行路径。 ## 影响面 工厂重构仅搬运代码组织,OpenCode 字段与 buildArgs/writeInput/isSessionBusy 行为逐项不变,opencode2 复用的导出未动;其余 20+ CLI 仅共用表各增一键,不受影响。MiMoCode 走通用 Pty/Tmux 后端,话题/群/adopt 会话无差异;CliId 联合类型为纯增量。 ## 测试 bun run build 全绿;cli-adapters、cli-id-roster-derivation、launch-model-capability、zellij 检测、bot-config-editor(含已发布序号锁定断言)、model-only-print(穷举键)、opencode/opencode2 resume、ask-hook、sandbox 等相关用例通过;新适配器/序号断言均经变异验证。作者已在实际 daemon 长期 live 验证会话创建、输入投递与重启后续接。 Co-authored-by: kingchao1024 <kingchao1024@users.noreply.github.com> Co-Authored-By: Claude Code <noreply@anthropic.com>
Co-authored-by: genglei.88 <genglei.88@bytedance.com>
|
对应上游 deepcoldy#1512 已在本轮同步 master、解决锁文件冲突,补上缺失原生 summary 时禁止成功摘要的回归测试,构建与定向测试通过。此 fork PR 的历史 live Feishu 和报告发布失败仍不是全场景通过的证据;下一步先核对 fork 独有的失败原因摘要修复,再与上游实现对齐。真实会话 fixture/访问权限仍待提供,暂不反复运行同一组无法进入会话的 AI 场景。 |
Purpose
Validate the Botmux Midscene migration and the complete repository CI in the contributor fork before the upstream pull request is considered ready.
What this validates
Latest evidence
Skipped-case CI example
The fork intentionally omits the Feishu group URL and authenticated browser state in this example. The workflow still runs the Dashboard Midscene case and keeps every unavailable Feishu case visible instead of dropping them from the report: