oh-my-openagent 跨平台 CI 失败根因分析实录Windows 控制台、Git worktree 竞态与超时修复全解【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent导读本文基于 oh-my-openagent 仓库中PR-6858评审证据文档 ci-failure-repairs.md完整复盘一次真实的跨平台 CI 修复战役从 Codex Windows 安装器预检超时、Senpi/memory测试在 Bun 5 秒默认超时下的崩溃到 Windows 控制台可见性探针的判定逻辑缺陷再到 macOS 并发git worktree add注册竞态与 8.3 短路径沙箱根归一化问题。读完本文你将掌握 CI 失败分析的标准方法RED → 根因 → 修复 → 本地 GREEN → 全量回归、Bun 测试超时语义、Win32 控制台 API 的正确使用方式以及这些修复在 packages/omo-codex、packages/senpi-task 与 packages/memory-core 中的源码级落点。一、背景第一次修复后分支repaired-head工作流本文记录的修复均来自 oh-my-openagent 第一次以repaired-head修复后分支模式运行的 CI 工作流工作流运行 ID 为31925417976。所谓 repaired-head是指在 PR 评审中先对失败分支进行修复后重跑再依据修复后的结果判断根因是否真正被消除的验证方式。本次战役共涉及三类失败失败类别失败 Job ID具体失败点Codex Windows 安装器预检95112165293install-codex-git-bash-preflight.test.ts首条非 Windows 用例超时60016msSenpi Windows/memory测试95112165321前两条/memory测试超时5016msWindows 控制台探针95112165297探针退出码 1但判定所需的关键 payload 被隐藏三者看似独立实则共享同一主题CI 失败往往不是断言错而是超时错与信息缺失错。超时掩盖了真正的代码缺陷而信息缺失让失败不可诊断。二、Codex Windows平台分支断言拖垮整套用例2.1 RED超时发生在第一个成功的非 Windows 用例失败 Job95112165293的现场是在 Windows 平台上运行 install-codex-git-bash-preflight.test.ts 时第一个非 Windows安装器用例#given non-Windows install #when running installer #then winget is never called耗时60016ms超时。2.2 根因repoRoot: process.cwd()与完整检出复制根因是测试平台的分支断言测试在构造安装器输入时使用repoRoot: process.cwd()即把 CI 上整个仓库工作目录当作安装目标仓库使用。在 Windows 套件并发争抢下对完整检出的递归复制开销巨大直接触顶 60 秒集成超时预算该文件在 Windows 平台将超时从 20 秒放宽到 60 秒见 install-codex-git-bash-preflight.test.ts 中INSTALL_CODEX_INTEGRATION_TEST_TIMEOUT_MS的平台分支。2.3 修复createRepoWithBuiltComponentBins() 自持 teardown修复方案是改为使用 fixture 工厂 install-codex-test-fixtures.ts 中的createRepoWithBuiltComponentBins()它在临时目录下按需生成一份最小化但结构完整的仓库骨架——包括根级package.json、src/index.ts、packages/omo-codex/marketplace.json、plugin/.codex-plugin/plugin.json以及全部EXPECTED_OMO_COMPONENT_BINS组件 bin 声明omo-lsp、omo-rules、ulw、omo-ulw-loop、omo-ultrawork等彻底规避了对真实检出的大规模复制。同时fixture 的生命周期由测试自身持有beforeAll创建、afterAll递归删除install-codex-git-bash-preflight.test.ts即owned teardown不依赖 CI 沙箱的全局清理。2.4 验证本地 GREEN修复后本地聚焦执行该文件6/6 全部通过耗时仅744ms随后完整 Codex 门禁519/519 全部通过。超时从60016ms降到亚秒级验证了根因判断的准确性——问题不在断言逻辑而在平台分支下的 I/O 成本。三、Senpi WindowsBun 的多文件调用 5 秒默认超时陷阱3.1 RED/memory测试在真实 Git fixture 的首次提交上超时失败 Job95112165321中Senpi Windows 套件的前两条/memory测试均以5016ms超时。5016ms这个数字本身就是关键线索——它几乎精确等于5 秒 16ms 抖动。3.2 根因Bun 1.3.12 在多文件调用下恢复 5 秒默认超时根因在于 Bun 测试运行器的语义Bun 1.3.12 在一次调用多个测试文件时会在文件之间恢复 5 秒默认超时。也就是说即便测试文件内已配置更长的超时预算文件切换的边界仍受 5 秒默认值约束。Senpi 的真实 Git fixture 在初始化时需要执行首次 commit这一步在 Windows 上的 I/O 延迟超过了 5 秒导致/memory测试还没真正开始执行就已经被判超时。3.3 修复文件级 30 秒 Windows 断路器其余平台保持 5 秒修复采用文件局部、平台定向的断路器策略仅在该测试文件范围内为 Windows 平台引入30 秒超时预算而其他平台继续使用 5 秒默认值避免掩盖非 Windows 平台上的真实性能退化。3.4 验证精确复现两文件调用9/9 通过修复后本地 CI-Bun 使用与 CI 完全相同的两文件调用方式复现该场景9/9 全部通过总耗时仅1.55s随后完整 Senpi 门禁1568/1568 全部通过。这里尤其值得学习的是验证方法修复后不跑整个目录而是精确复现失败时的多文件调用形态确保修复针对的是真实失败路径。四、Windows 控制台探针失败时隐藏判定 payload 是最大的诊断敌人4.1 RED探针退出 1但决定性 payload 被吞失败 Job95112165297中Windows 控制台探针退出码为 1但测试在先断言状态、后暴露 stdout的顺序下把决定成败的 payload 隐藏了。失败只能看到退出 1看不到是哪个字段不满足等于没有失败信息。4.2 根因MainWindowHandle被当作 hosted-CI 契约 正对照组缺少失败敏感拓扑根因有两层契约选错MainWindowHandle本是交互式桌面语义的句柄却被用作 hosted-CI无桌面会话下的判定契约拓扑不对称正对照组visible-control没有使用与隐藏组hidden-fixed完全一致的分离控制台拓扑导致两组差异无法隔离出真正的控制台可见性行为。4.3 修复五条措施的完整组合修复后的探针逻辑见 windows-console-probe.ts由五条措施组成失败时暴露完整现场status/signal/error/stdout/stderr 全部输出失败可诊断正/负两组使用完全一致的分离控制台拓扑visible-control与hidden-fixed只在windowsHide上不同其余spawn 方式、环境变量、RPC runner完全一致通过 Win32AttachConsole断言控制台分配判定逻辑落在 windows-console-attachment-probe.ts 中——它在一个一次性子进程里依次调用FreeConsole、AttachConsole(pid)、GetConsoleWindow、IsWindowVisible直接通过kernel32/user32FFI 回答该 PID 是否拥有控制台、控制台窗口是否可见替代了原先每次都要冷启动 PowerShell 5.1 csc.exe 编译 C# shim 的重型方案后者单次成本极高恰是探针超时的元凶之一见该文件头部注释保留MainWindowHandle仅作为交互式桌面证明不再充当 hosted-CI 判定契约订阅时机修正在进程关闭前完成订阅并await进程的close事件避免竞态导致退出码丢失windows-console-probe.ts。五、后续 current-head 验证轮次根因修复的收敛过程第一次 repaired-head 工作流之后项目又进行了多轮 current-head 验证每一轮都精准地消灭一类新暴露的问题5.131927904705全检出 fixture 与 5 秒超时的根修本轮确认 Windows Codex 全检出 fixture 超时与 Windows memory 5 秒 fixture 超时已被根修即不再只是放宽超时而是消除超时根源。5.231930067950macOS 并发git worktree add注册竞态macOS 上并发执行git worktree add存在注册竞态。修复采用每仓库管理队列per-repository administration queue仓库级串行化 worktree 变更并配以确定性重叠测试。其实现落点在 worktree-mutation-queue.ts 的withSerializedGitWorktreeMutation()——以resolve(dir)为键维护Mapstring, Promisevoid队列后到的变更必须等待前一个变更 settle无论成败后才执行从而保证同一仓库的 worktree 变更严格串行。5.331931659970Windows 生产驱动不再被跳过Windows 生产驱动此前被跳过说明存在平台判断缺陷。修复后不再跳过且PATHEXT与仓库本地的node_modules/.bin目录被显式解析——避免依赖隐式的 PATH 继承。5.431932110216三线并进的验证结果本轮同时验证了三条路径console host RED报AllocConsole failed: 5——错误码 5拒绝访问在此语境下实际意味着宿主进程已经拥有所需控制台是已附加的合法信号而非失败production route GREENwiringFixed: truePID1084零泄漏child REDBun fs-event 断言失败根因是8.3 短路径沙箱根RUNNER~1形式与规范化路径混用。对应修复同样落为三点Win32 错误码 5 被接受为已附加控制台QA 沙箱根目录使用realpathSync.native归一化一次所有派生路径cwd/agent/XDG/home/trust一律基于该规范化根。5.5 最终 Windows 证明轮次31933958600→31935960840→31938387966→3193950755231933958600两个子进程都继承了宿主显式控制台说明继承不能作为可见性判定依据31935960840CreateNoWindow会生成一个被两个子进程共同继承的无窗口控制台对象——它存在但不可见必须区分有无控制台与控制台是否可见两个维度。据此完成根修Bun 探针父进程调用 Win32FreeConsole可见对照组必须暴露非零、可见的控制台 HWND隐藏子进程必须暴露零可见 HWND 且MainWindowHandle: 0即使测试通过也直接向 stdout 输出原始 payload保证可观测性31938387966控制台与路由证明均通过但一个无关的 Git 缓存测试触发了默认 5 秒 Windows 超时。修复为所有基于 Git 的MemoryBlockCache测试统一改用已有的20 秒 Windows 集成预算31939507552headeffcfe82e7774c5b6458696bc17853a3dfe49d27上每个 CI Job 全部通过战役收官。六、方法论沉淀从本战役可复用的四条 CI 修复准则结合上述全过程可以提炼出四条可直接迁移的准则超时数字是线索不是噪音。60016ms、5016ms、AllocConsole failed: 5这类数字本身就是根因指纹5 秒对应 Bun 多文件调用的默认超时错误码 5 对应已附加控制台。修复后本地重放要精确复现失败形态同样的多文件调用、同样的平台分支而不是跑全量目录。失败必须可诊断payload 永远直接暴露。探针的教训是先断言、后暴露 stdout会让失败退化为无信息的退出码。正确做法是在失败路径上完整输出 status/signal/error/stdout/stderr甚至在通过时也输出原始 payload。正负对照组拓扑必须完全对称。visible-control与hidden-fixed只有一处语义差异其余 spawn 参数、环境变量、runner 配置完全一致才能把差异归因于控制台可见性本身。区分平台语义与本地语义。MainWindowHandle是交互式桌面契约不能套用到 hosted-CI8.3 短路径RUNNER~1必须用realpathSync.native归一化一次并让所有派生路径继承超时预算应平台定向、文件局部既救 Windows 又不掩盖其他平台的退化。七、进一步阅读修复证据原文.omo/evidence/20260816-pr-6858-brutal-review/ci-failure-repairs.mdCodex Git Bash 预检测试install-codex-git-bash-preflight.test.ts最小仓库 fixture 工厂install-codex-test-fixtures.tsGit Bash 解析与安装提示winget /OMO_CODEX_GIT_BASH_PATHgit-bash.tsWindows 控制台探针与 FFI 判定子进程windows-console-probe.ts、windows-console-attachment-probe.ts每仓库 worktree 串行化队列worktree-mutation-queue.ts【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 oh-my-openagent 跨平台 CI 失败根因分析实录：Windows 控制台、Git worktree 竞态与超时修复全解
oh-my-openagent 跨平台 CI 失败根因分析实录Windows 控制台、Git worktree 竞态与超时修复全解【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent导读本文基于 oh-my-openagent 仓库中PR-6858评审证据文档 ci-failure-repairs.md完整复盘一次真实的跨平台 CI 修复战役从 Codex Windows 安装器预检超时、Senpi/memory测试在 Bun 5 秒默认超时下的崩溃到 Windows 控制台可见性探针的判定逻辑缺陷再到 macOS 并发git worktree add注册竞态与 8.3 短路径沙箱根归一化问题。读完本文你将掌握 CI 失败分析的标准方法RED → 根因 → 修复 → 本地 GREEN → 全量回归、Bun 测试超时语义、Win32 控制台 API 的正确使用方式以及这些修复在 packages/omo-codex、packages/senpi-task 与 packages/memory-core 中的源码级落点。一、背景第一次修复后分支repaired-head工作流本文记录的修复均来自 oh-my-openagent 第一次以repaired-head修复后分支模式运行的 CI 工作流工作流运行 ID 为31925417976。所谓 repaired-head是指在 PR 评审中先对失败分支进行修复后重跑再依据修复后的结果判断根因是否真正被消除的验证方式。本次战役共涉及三类失败失败类别失败 Job ID具体失败点Codex Windows 安装器预检95112165293install-codex-git-bash-preflight.test.ts首条非 Windows 用例超时60016msSenpi Windows/memory测试95112165321前两条/memory测试超时5016msWindows 控制台探针95112165297探针退出码 1但判定所需的关键 payload 被隐藏三者看似独立实则共享同一主题CI 失败往往不是断言错而是超时错与信息缺失错。超时掩盖了真正的代码缺陷而信息缺失让失败不可诊断。二、Codex Windows平台分支断言拖垮整套用例2.1 RED超时发生在第一个成功的非 Windows 用例失败 Job95112165293的现场是在 Windows 平台上运行 install-codex-git-bash-preflight.test.ts 时第一个非 Windows安装器用例#given non-Windows install #when running installer #then winget is never called耗时60016ms超时。2.2 根因repoRoot: process.cwd()与完整检出复制根因是测试平台的分支断言测试在构造安装器输入时使用repoRoot: process.cwd()即把 CI 上整个仓库工作目录当作安装目标仓库使用。在 Windows 套件并发争抢下对完整检出的递归复制开销巨大直接触顶 60 秒集成超时预算该文件在 Windows 平台将超时从 20 秒放宽到 60 秒见 install-codex-git-bash-preflight.test.ts 中INSTALL_CODEX_INTEGRATION_TEST_TIMEOUT_MS的平台分支。2.3 修复createRepoWithBuiltComponentBins() 自持 teardown修复方案是改为使用 fixture 工厂 install-codex-test-fixtures.ts 中的createRepoWithBuiltComponentBins()它在临时目录下按需生成一份最小化但结构完整的仓库骨架——包括根级package.json、src/index.ts、packages/omo-codex/marketplace.json、plugin/.codex-plugin/plugin.json以及全部EXPECTED_OMO_COMPONENT_BINS组件 bin 声明omo-lsp、omo-rules、ulw、omo-ulw-loop、omo-ultrawork等彻底规避了对真实检出的大规模复制。同时fixture 的生命周期由测试自身持有beforeAll创建、afterAll递归删除install-codex-git-bash-preflight.test.ts即owned teardown不依赖 CI 沙箱的全局清理。2.4 验证本地 GREEN修复后本地聚焦执行该文件6/6 全部通过耗时仅744ms随后完整 Codex 门禁519/519 全部通过。超时从60016ms降到亚秒级验证了根因判断的准确性——问题不在断言逻辑而在平台分支下的 I/O 成本。三、Senpi WindowsBun 的多文件调用 5 秒默认超时陷阱3.1 RED/memory测试在真实 Git fixture 的首次提交上超时失败 Job95112165321中Senpi Windows 套件的前两条/memory测试均以5016ms超时。5016ms这个数字本身就是关键线索——它几乎精确等于5 秒 16ms 抖动。3.2 根因Bun 1.3.12 在多文件调用下恢复 5 秒默认超时根因在于 Bun 测试运行器的语义Bun 1.3.12 在一次调用多个测试文件时会在文件之间恢复 5 秒默认超时。也就是说即便测试文件内已配置更长的超时预算文件切换的边界仍受 5 秒默认值约束。Senpi 的真实 Git fixture 在初始化时需要执行首次 commit这一步在 Windows 上的 I/O 延迟超过了 5 秒导致/memory测试还没真正开始执行就已经被判超时。3.3 修复文件级 30 秒 Windows 断路器其余平台保持 5 秒修复采用文件局部、平台定向的断路器策略仅在该测试文件范围内为 Windows 平台引入30 秒超时预算而其他平台继续使用 5 秒默认值避免掩盖非 Windows 平台上的真实性能退化。3.4 验证精确复现两文件调用9/9 通过修复后本地 CI-Bun 使用与 CI 完全相同的两文件调用方式复现该场景9/9 全部通过总耗时仅1.55s随后完整 Senpi 门禁1568/1568 全部通过。这里尤其值得学习的是验证方法修复后不跑整个目录而是精确复现失败时的多文件调用形态确保修复针对的是真实失败路径。四、Windows 控制台探针失败时隐藏判定 payload 是最大的诊断敌人4.1 RED探针退出 1但决定性 payload 被吞失败 Job95112165297中Windows 控制台探针退出码为 1但测试在先断言状态、后暴露 stdout的顺序下把决定成败的 payload 隐藏了。失败只能看到退出 1看不到是哪个字段不满足等于没有失败信息。4.2 根因MainWindowHandle被当作 hosted-CI 契约 正对照组缺少失败敏感拓扑根因有两层契约选错MainWindowHandle本是交互式桌面语义的句柄却被用作 hosted-CI无桌面会话下的判定契约拓扑不对称正对照组visible-control没有使用与隐藏组hidden-fixed完全一致的分离控制台拓扑导致两组差异无法隔离出真正的控制台可见性行为。4.3 修复五条措施的完整组合修复后的探针逻辑见 windows-console-probe.ts由五条措施组成失败时暴露完整现场status/signal/error/stdout/stderr 全部输出失败可诊断正/负两组使用完全一致的分离控制台拓扑visible-control与hidden-fixed只在windowsHide上不同其余spawn 方式、环境变量、RPC runner完全一致通过 Win32AttachConsole断言控制台分配判定逻辑落在 windows-console-attachment-probe.ts 中——它在一个一次性子进程里依次调用FreeConsole、AttachConsole(pid)、GetConsoleWindow、IsWindowVisible直接通过kernel32/user32FFI 回答该 PID 是否拥有控制台、控制台窗口是否可见替代了原先每次都要冷启动 PowerShell 5.1 csc.exe 编译 C# shim 的重型方案后者单次成本极高恰是探针超时的元凶之一见该文件头部注释保留MainWindowHandle仅作为交互式桌面证明不再充当 hosted-CI 判定契约订阅时机修正在进程关闭前完成订阅并await进程的close事件避免竞态导致退出码丢失windows-console-probe.ts。五、后续 current-head 验证轮次根因修复的收敛过程第一次 repaired-head 工作流之后项目又进行了多轮 current-head 验证每一轮都精准地消灭一类新暴露的问题5.131927904705全检出 fixture 与 5 秒超时的根修本轮确认 Windows Codex 全检出 fixture 超时与 Windows memory 5 秒 fixture 超时已被根修即不再只是放宽超时而是消除超时根源。5.231930067950macOS 并发git worktree add注册竞态macOS 上并发执行git worktree add存在注册竞态。修复采用每仓库管理队列per-repository administration queue仓库级串行化 worktree 变更并配以确定性重叠测试。其实现落点在 worktree-mutation-queue.ts 的withSerializedGitWorktreeMutation()——以resolve(dir)为键维护Mapstring, Promisevoid队列后到的变更必须等待前一个变更 settle无论成败后才执行从而保证同一仓库的 worktree 变更严格串行。5.331931659970Windows 生产驱动不再被跳过Windows 生产驱动此前被跳过说明存在平台判断缺陷。修复后不再跳过且PATHEXT与仓库本地的node_modules/.bin目录被显式解析——避免依赖隐式的 PATH 继承。5.431932110216三线并进的验证结果本轮同时验证了三条路径console host RED报AllocConsole failed: 5——错误码 5拒绝访问在此语境下实际意味着宿主进程已经拥有所需控制台是已附加的合法信号而非失败production route GREENwiringFixed: truePID1084零泄漏child REDBun fs-event 断言失败根因是8.3 短路径沙箱根RUNNER~1形式与规范化路径混用。对应修复同样落为三点Win32 错误码 5 被接受为已附加控制台QA 沙箱根目录使用realpathSync.native归一化一次所有派生路径cwd/agent/XDG/home/trust一律基于该规范化根。5.5 最终 Windows 证明轮次31933958600→31935960840→31938387966→3193950755231933958600两个子进程都继承了宿主显式控制台说明继承不能作为可见性判定依据31935960840CreateNoWindow会生成一个被两个子进程共同继承的无窗口控制台对象——它存在但不可见必须区分有无控制台与控制台是否可见两个维度。据此完成根修Bun 探针父进程调用 Win32FreeConsole可见对照组必须暴露非零、可见的控制台 HWND隐藏子进程必须暴露零可见 HWND 且MainWindowHandle: 0即使测试通过也直接向 stdout 输出原始 payload保证可观测性31938387966控制台与路由证明均通过但一个无关的 Git 缓存测试触发了默认 5 秒 Windows 超时。修复为所有基于 Git 的MemoryBlockCache测试统一改用已有的20 秒 Windows 集成预算31939507552headeffcfe82e7774c5b6458696bc17853a3dfe49d27上每个 CI Job 全部通过战役收官。六、方法论沉淀从本战役可复用的四条 CI 修复准则结合上述全过程可以提炼出四条可直接迁移的准则超时数字是线索不是噪音。60016ms、5016ms、AllocConsole failed: 5这类数字本身就是根因指纹5 秒对应 Bun 多文件调用的默认超时错误码 5 对应已附加控制台。修复后本地重放要精确复现失败形态同样的多文件调用、同样的平台分支而不是跑全量目录。失败必须可诊断payload 永远直接暴露。探针的教训是先断言、后暴露 stdout会让失败退化为无信息的退出码。正确做法是在失败路径上完整输出 status/signal/error/stdout/stderr甚至在通过时也输出原始 payload。正负对照组拓扑必须完全对称。visible-control与hidden-fixed只有一处语义差异其余 spawn 参数、环境变量、runner 配置完全一致才能把差异归因于控制台可见性本身。区分平台语义与本地语义。MainWindowHandle是交互式桌面契约不能套用到 hosted-CI8.3 短路径RUNNER~1必须用realpathSync.native归一化一次并让所有派生路径继承超时预算应平台定向、文件局部既救 Windows 又不掩盖其他平台的退化。七、进一步阅读修复证据原文.omo/evidence/20260816-pr-6858-brutal-review/ci-failure-repairs.mdCodex Git Bash 预检测试install-codex-git-bash-preflight.test.ts最小仓库 fixture 工厂install-codex-test-fixtures.tsGit Bash 解析与安装提示winget /OMO_CODEX_GIT_BASH_PATHgit-bash.tsWindows 控制台探针与 FFI 判定子进程windows-console-probe.ts、windows-console-attachment-probe.ts每仓库 worktree 串行化队列worktree-mutation-queue.ts【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考