OmX 0.12.2 补丁列车解析：Windows 原生团队 Worker 启动/关闭安全、postLaunch 竞态恢复与 HUD skill 状态收敛

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-codex

0.12.2是 OmX（Oh 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 的 Summary，0.12.2不是大版本功能迭代，而是把v0.12.1之后累积的跨模块缺陷修复打包发布的 patch train。与之对应的 docs/qa/release-readiness-0.12.2.md 给出了明确的发布评审结论：以v0.12.1..HEAD为对比基线，整体判定为GO，可进入分支推送与 PR 交接阶段。

整个补丁列车可以拆成五个彼此独立、但都围绕"进程生命周期与状态一致性"展开的修复点：

#1358：拆分窗格关闭时保护 leader pane

在共享窗口（shared-window）的 tmux 会话中，调用方 leader 客户端与 Worker pane 之间存在进程树血缘重叠（overlapping ancestry）：如果关闭团队窗格时盲目执行进程树级 prekill，很容易把 leader 自身的进程也一并信号掉。

修复的核心逻辑位于 src/team/runtime.ts 的shouldPrekillInteractiveShutdownProcessTrees：

export 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。

#1360：postLaunch模式状态的 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 记录；
• 结构性损坏（malformed）：JSON 结构完整可解析但不是合法状态对象（如数组、非对象顶层），说明这不是写入竞态而是真正的脏数据，此时仅告警、不做覆盖，保留原文件供人工排查。

恢复时写入的最小化记录由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。

#1362：Windows 原生团队 Worker 的 PowerShell 启动路径

此前团队 Worker pane 的统一启动方式走 POSIX 风格exec /bin/sh ...（见 src/team/tmux-session.ts 的/bin/sh脚本路径），在 Windows 原生环境下 Worker 根本无法正常上报 ready。0.12.2 为 Windows 引入了独立的 PowerShell 启动路径：

1. 解析 PowerShell 位置：resolveNativeWindowsPowerShellPath（src/team/tmux-session.ts）依次探测System32\WindowsPowerShell\v1.0\powershell.exe等系统候选路径，最终回退到powershell.exe；
2. 注入环境与 PATH：启动命令先执行$env:PATH = <leaderNodeDir> + $env:PATH形式的前置赋值（src/team/tmux-session.ts），把 leader 侧 Node 可执行目录与所需环境变量注入 Worker 会话；
3. Base64 编码整条命令：encodePowerShellCommand（src/team/tmux-session.ts）与quotePowerShellArg（src/team/tmux-session.ts）配合，最终以powershell.exe -NoLogo -NoProfile -ExecutionPolicy Bypass -EncodedCommand <base64>的形式启动（src/team/tmux-session.ts），避免引号转义与执行策略拦截问题。

decodePowerShellEncodedCommands（src/team/tmux-session.ts）还会把命令中的-EncodedCommand参数解码为 UTF-16LE 明文，用于进程树识别与状态判定——也就是说，解码逻辑与编码逻辑成对存在，保证监控侧能读懂 PowerShell 启动的 Worker。回归覆盖在 src/team/tests/tmux-session.test.ts 中。

#1367：HUD 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_SKILLS：autopilot、autoresearch、team、ultragoal、ralph、ultrawork、ultraqa、ralplan、deep-interview（src/state/skill-active.ts）；
• src/hud/state.ts 的readAllState通过readVisibleSkillActiveStateForStateDir(stateDir, currentSessionId)读取会话可见的 skill 状态，再用listActiveSkills构建规范映射，作为shouldSurfaceCanonicalSkill/mergePhase（src/hud/state.ts）的判定依据：仅当规范状态中该 skill 确实活跃、且不是 terminal/inactive 相位时，才向 HUD 暴露徽标。

这保证 HUD、overlay（src/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）元数据一致。

遗留风险与升级后监控建议

原文档明确列出的遗留风险，也是升级后最值得关注的三个监控点：

1. Windows 专项缺少真机验证：#1358与#1362两个 Windows 相关修复并未在原生 Windows 11 + psmux 环境做过 live smoke。升级后应重点跟踪Windows 原生团队 Worker 启动是否稳定上报 ready与拆分窗格关闭遥测，若出现 Worker 长时间未 ready 或关闭时误伤 leader，优先回查tmux-session.ts的 PowerShell 启动路径与runtime.ts的 prekill 判定；
2. HUD 收敛改动面广：#1367一次性触碰了 HUD、overlay、keyword detector、MCP state 四个可见面。升级后应观察旧式单 skill 读取方与多工作流徽标渲染是否出现漂移（drift），特别是会话切换后徽标能否及时失效；
3. 验证范围有限：本地四连验证（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.ts
• postLaunch 竞态恢复：src/cli/index.ts
• Windows PowerShell 启动路径：src/team/tmux-session.ts、src/team/tmux-session.ts
• 会话级 skill 状态定义：src/state/skill-active.ts
• HUD 状态收敛渲染：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