OmX 0.12.2 补丁列车解析Windows 原生团队 Worker 启动/关闭安全、postLaunch 竞态恢复与 HUD skill 状态收敛【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex0.12.2是 OmXOh My codeX在v0.12.1..v0.12.2区间累积发布的补丁列车版本核心覆盖五大主题Windows 原生 psmux 拆分窗格下团队 Worker 的启动与关闭安全、postLaunch模式状态的 shutdown 竞态恢复、HUD/Overlay/关键词检测器/MCP 状态四面的 skill 状态可见性收敛、监控驱动退出时团队状态的保留以及发布配套文件的同步对齐。读完本文你将理解这批修复背后的竞态根因、各修复在源码中的落点以及如何在升级到 0.12.2 后针对遗留风险做定向监控。版本定位一次目标明确的补丁列车根据 docs/release-notes-0.12.2.md 的 Summary0.12.2不是大版本功能迭代而是把v0.12.1之后累积的跨模块缺陷修复打包发布的 patch train。与之对应的 docs/qa/release-readiness-0.12.2.md 给出了明确的发布评审结论以v0.12.1..HEAD为对比基线整体判定为GO可进入分支推送与 PR 交接阶段。整个补丁列车可以拆成五个彼此独立、但都围绕进程生命周期与状态一致性展开的修复点Issue主题影响面#1358psmux 拆分窗格关闭时保护 leader pane团队运行时进程树#1360postLaunch模式状态 shutdown 竞态恢复CLI 启动清理流程#1362Windows 原生团队 Worker 的 PowerShell 启动路径Windows 平台 Worker 启动#1367HUD skill 状态可见性收敛HUD / Overlay / 关键字检测 / MCP 状态#1369监控驱动退出时保留团队状态runtime-cli退出行为#1358拆分窗格关闭时保护 leader pane在共享窗口shared-window的 tmux 会话中调用方 leader 客户端与 Worker pane 之间存在进程树血缘重叠overlapping ancestry如果关闭团队窗格时盲目执行进程树级 prekill很容易把 leader 自身的进程也一并信号掉。修复的核心逻辑位于 src/team/runtime.ts 的shouldPrekillInteractiveShutdownProcessTreesexport function shouldPrekillInteractiveShutdownProcessTrees(sessionName: string): boolean { // Shared-window tmux sessions can expose overlapping ancestry around the // invoking leader client. Rely on pane-targeted teardown there so shutdown // does not signal the leader while tearing down worker panes. if (sessionName.includes(:)) return false; // Detached session teardown still benefits from process-tree prekill, // including native Windows prompt-worker ancestry where pane-targeted // teardown alone is insufficient. return true; }判定规则可以概括为会话名中包含:即 psmux 风格的共享/拆分窗格会话时跳过进程树 prekill改用 pane 定向拆除pane-targeted teardown确保关闭 Worker pane 不会误伤 leader独立detached会话仍保留进程树 prekill 收益——包括 Windows 原生 prompt-worker 那种仅靠 pane 定向拆除不够干净的场景。也就是说这个修复不是一刀切禁用 prekill而是根据会话类型在两种拆除策略之间切换保证 leader 安全与 teardown 彻底性兼得。对应测试位于 src/team/tests/runtime.test.ts。#1360postLaunch模式状态的 shutdown 竞态恢复另一个典型的竞态场景发生在 CLI 的postLaunch阶段会话关闭shutdown与模式状态文件的写入几乎同时发生导致清理程序读到空的或半截truncated的 JSON 文件——例如文件刚被创建尚未写入完成、或写入中途被中断。针对这类写入竞态与真·格式损坏的区分src/cli/index.ts 做了精细的三分类处理缺失missing文件不存在ENOENT按正常路径跳过可恢复recoverable文件内容为空、或属于已知的写入未完成 JSON 语法错误Unexpected end of JSON input、Unterminated string in JSON、Expected property name or }等判定为瞬时竞态。此时最多重试 2 次、每次间隔 10ms见常量POST_LAUNCH_MODE_STATE_MAX_READ_ATTEMPTS 2与POST_LAUNCH_MODE_STATE_RETRY_DELAY_MS 10仍失败则把状态恢复为最小化的 inactive 记录结构性损坏malformedJSON 结构完整可解析但不是合法状态对象如数组、非对象顶层说明这不是写入竞态而是真正的脏数据此时仅告警、不做覆盖保留原文件供人工排查。恢复时写入的最小化记录由buildRecoveredPostLaunchModeState与buildRecoveredPostLaunchSkillActiveState生成src/cli/index.ts前者产出{ active: false, mode, current_phase: cancelled, completed_at, last_turn_at }后者产出{ version: 1, active: false, skill: , phase: complete, active_skills: [] }——既保证后续读取方不会因缺字段崩溃又不会把竞态残留误判为仍在活跃。同时src/cli/index.ts 对 malformed 结果输出[omx] postLaunch: skipped malformed mode state ...的告警后跳过处理与 release notes 中structurally complete malformed JSON is warned and left untouched的描述完全对应。对应测试见 src/cli/tests/index.test.ts。#1362Windows 原生团队 Worker 的 PowerShell 启动路径此前团队 Worker pane 的统一启动方式走 POSIX 风格exec /bin/sh ...见 src/team/tmux-session.ts 的/bin/sh脚本路径在 Windows 原生环境下 Worker 根本无法正常上报 ready。0.12.2 为 Windows 引入了独立的 PowerShell 启动路径解析 PowerShell 位置resolveNativeWindowsPowerShellPathsrc/team/tmux-session.ts依次探测System32\WindowsPowerShell\v1.0\powershell.exe等系统候选路径最终回退到powershell.exe注入环境与 PATH启动命令先执行$env:PATH leaderNodeDir $env:PATH形式的前置赋值src/team/tmux-session.ts把 leader 侧 Node 可执行目录与所需环境变量注入 Worker 会话Base64 编码整条命令encodePowerShellCommandsrc/team/tmux-session.ts与quotePowerShellArgsrc/team/tmux-session.ts配合最终以powershell.exe -NoLogo -NoProfile -ExecutionPolicy Bypass -EncodedCommand base64的形式启动src/team/tmux-session.ts避免引号转义与执行策略拦截问题。decodePowerShellEncodedCommandssrc/team/tmux-session.ts还会把命令中的-EncodedCommand参数解码为 UTF-16LE 明文用于进程树识别与状态判定——也就是说解码逻辑与编码逻辑成对存在保证监控侧能读懂 PowerShell 启动的 Worker。回归覆盖在 src/team/tests/tmux-session.test.ts 中。#1367HUD skill 状态可见性收敛这是本次补丁列车中覆盖面最广的一项改动。此前 HUD 显示当前活跃 skill/badge依赖各模式的独立状态文件容易产生根级root-only模式徽标存活超过其所属会话的残留问题。0.12.2 将可见性收敛到会话作用域的 skill-active 状态状态文件约定为skill-active-state.json常量SKILL_ACTIVE_STATE_FILE见 src/state/skill-active.ts并定义了标准工作流 skill 集合CANONICAL_WORKFLOW_SKILLSautopilot、autoresearch、team、ultragoal、ralph、ultrawork、ultraqa、ralplan、deep-interviewsrc/state/skill-active.tssrc/hud/state.ts 的readAllState通过readVisibleSkillActiveStateForStateDir(stateDir, currentSessionId)读取会话可见的 skill 状态再用listActiveSkills构建规范映射作为shouldSurfaceCanonicalSkill/mergePhasesrc/hud/state.ts的判定依据仅当规范状态中该 skill 确实活跃、且不是 terminal/inactive 相位时才向 HUD 暴露徽标。这保证 HUD、overlaysrc/hooks/agents-overlay.ts、关键字激活检测src/hooks/keyword-detector.ts与 MCP 状态服务src/mcp/state-server.ts读到的是同一份会话级事实会话结束后根级残留徽标随之失效不再死后显灵。同时mergePhase保留了单 skill 读取的兼容路径使旧式读取方在无规范相位时仍能基于自身详情字段渲染见normalizeCanonicalHudPhase对_→-的归一化src/hud/state.ts。#1369监控驱动的runtime-cli退出保留团队状态runtime-cli在监控monitor模式下探测到终态terminal phase或失败条件时过去可能会直接触发关闭流程导致运营人员还没来得及检查状态团队现场就被清掉了。0.12.2 明确把监控探测到的终态/失败留在仅报告report-only路径上src/team/runtime-cli.ts 在探测到终态时输出[runtime-cli] phase... reached terminal state; preserving team state for inspection.并提示运营者需要显式关闭时执行omx team shutdown teamName需要先完成状态采集时再加--force对应地监控探测到的失败同样被定义为不是显式关闭请求src/team/runtime-cli.ts。也就是说只有运营者的显式关闭指令才会真正触发shutdownTeam监控侧只负责报告相位与任务进度如phase... pending... inProgress... completed...的监控行src/team/runtime-cli.ts。这让团队状态在故障现场得以完整保留供事后检视。测试覆盖见 src/team/tests/runtime-cli.test.ts。发布验证证据与版本配套本版本在本地验证层面全部通过npm run build✅npm run lint✅npm test✅npm run smoke:packed-install✅验证矩阵在 docs/qa/release-readiness-0.12.2.md 中有逐项记录同时 release notes 明确说明这是一次本地验证而非完整 CI 矩阵重跑。此外版本配套文件已同步对齐到0.12.2包括package.json/package-lock.json、Cargo.toml/Cargo.lock、CHANGELOG.md、RELEASE_BODY.md 以及本份 docs/release-notes-0.12.2.md确保 Node 侧与 Rust 侧Cargo workspace 下的 crates元数据一致。遗留风险与升级后监控建议原文档明确列出的遗留风险也是升级后最值得关注的三个监控点Windows 专项缺少真机验证#1358与#1362两个 Windows 相关修复并未在原生 Windows 11 psmux 环境做过 live smoke。升级后应重点跟踪Windows 原生团队 Worker 启动是否稳定上报 ready与拆分窗格关闭遥测若出现 Worker 长时间未 ready 或关闭时误伤 leader优先回查tmux-session.ts的 PowerShell 启动路径与runtime.ts的 prekill 判定HUD 收敛改动面广#1367一次性触碰了 HUD、overlay、keyword detector、MCP state 四个可见面。升级后应观察旧式单 skill 读取方与多工作流徽标渲染是否出现漂移drift特别是会话切换后徽标能否及时失效验证范围有限本地四连验证build/lint/test/smoke不等于完整 CI 矩阵涉及跨平台路径或 tmux 依赖的改动建议在目标平台补齐一轮矩阵后再进入生产使用。小结0.12.2 的价值不在于新增功能而在于把进程生命周期与状态一致性上的五类缺陷系统性收口Windows 与 psmux 下的 leader 保护与 Worker 启动#1358/#1362、postLaunch 竞态下的状态恢复边界#1360、会话级 HUD skill 状态的单一事实来源#1367以及监控与关闭职责的分离#1369。对于正在使用 OmX 团队模式与 HUD 工作流的用户这份补丁列车既降低了 Windows 原生部署的踩坑概率也让关闭后状态残留竞态脏文件这类隐蔽问题有了明确的处理约定。关键源码索引团队运行时 prekill 判定src/team/runtime.tspostLaunch 竞态恢复src/cli/index.tsWindows PowerShell 启动路径src/team/tmux-session.ts、src/team/tmux-session.ts会话级 skill 状态定义src/state/skill-active.tsHUD 状态收敛渲染src/hud/state.ts、src/hud/state.ts监控保留团队状态src/team/runtime-cli.ts发布评审证据docs/qa/release-readiness-0.12.2.md【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考