企业官网建设流程全解析

oh-my-codex 0.12.5 稳定性补丁深度解析：session 作用域、团队启动恢复与 Windows/tmux 修复

【免费下载链接】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.5是 oh-my-codex（OMX）在0.12.4之后发布的一次大规模稳定性补丁版本，累计合入 25 个 PR、改动 74 个文件，集中修复了 session 作用域、团队启动/关闭、Windows worker 路径与 tmux 工作目录四类相互关联的缺陷，并为团队 worker 引入"当前任务基线分支"护栏，同时收紧多工作流状态管理。阅读本文后，你将完整掌握 0.12.5 的修复全景、每项修复对应的源码实现依据，以及如何通过omx doctor、omx explore等命令在升级后验证环境是否就绪。

版本概览

Summary

0.12.5的核心定位是"广覆盖的稳定性补丁"。它并非引入新功能的大版本，而是把自0.12.4以来积累的一簇 session 作用域、团队启动/关闭、Windows worker 路径以及 tmux cwd 相关 bug 系统性收口，并借机加固团队 worker 的当前任务基线分支保护，同时收紧多工作流状态管理。

验证证据

该版本发布时附带完整验证证据，升级后可在仓库根目录复跑：

• npm run build✅
• npm run lint✅
• npm test✅
• node --test dist/cli/__tests__/version-sync-contract.test.js✅
• npm run smoke:packed-install✅

其中version-sync-contract测试用于确保版本号在各入口间保持一致，npm run smoke:packed-install则验证打包安装链路可用。

版本亮点

多技能规划状态保留：修复混合工作流路由中的状态丢失

ralplan/ralph的规划状态在混合工作流提示词被中途重新路由时不再丢失。此前存在一个静默回归：当复合技能提示词在第二次路由扫描时，ralPlan/ deep-interview 状态会被意外清空。该问题由 PR #1471 修复。

从源码结构看，规划状态由 src/ralplan/runtime.ts 与 src/ralph/persistence.ts 等模块持久化管理，0.12.5 的核心改动在于确保路由重扫过程中不触碰已落盘的规划状态，避免二次路由导致状态被覆盖。

团队启动恢复：启动停滞不再挂死整条启动序列

启动早期停滞的 worker 不再挂死整个团队启动流程。运行时现在能够检测停滞条件并回退到可恢复状态，而不是死锁。该修复来自 PR #1444。

这背后对应团队运行时对启动阶段的超时与状态回退逻辑（src/team/runtime.ts），0.12.5 在此前启动握手基础上补充了停滞检测分支，使得单个 worker 启动失败不会阻塞整个团队的 boot 序列。

Windows 可靠性集群：四项独立修复一次落地

四个独立的 Windows 修复在 0.12.5 一起落地：

• 陈旧 leader-pane 关闭目标（PR #1470）：分割 pane 关闭时，陈旧的 leader-pane ID 不再误导关闭信号。
• psmux worker 启动器路径解析（PR #1469）：原生 psmux worker 启动时，现在从解析后的 Codex launcher 路径启动。
• MCP 孤儿清理（PR #1437）：Windows 下 MCP 子进程在父进程退出后不再存活。
• 退役 MCP 配置修复（PR #1436）：升级时omx doctor与启动路径会重新对齐退役的团队 MCP 配置条目。

需要说明的是，根据项目 README.md 的明确声明，OMX 主要面向 macOS 或 Linux + Codex CLI 路径设计与调优，原生 Windows 并非默认体验，可能表现不一致且支持较少——0.12.5 的这批 Windows 修复属于对这条"非默认路径"的可靠性加固。

tmux/shell cwd 正确性：worker 不再"启动在错误目录"

分离的 tmux pane、受支持的 shell worker 启动以及 Homebrew zsh 路径，现在都会遵循请求的工作目录，修复了长期存在的"worker 启动在错误目录"一类 bug（涉及 #1468、#1460、#1462）。

该主题对应的源码依据见 src/hud/tmux.ts 与 src/team/worktree.ts：团队 worker 的 cwd 与 worktree 解析是同一链路，0.12.5 确保 pane 启动前把规范化后的目录传入 tmux 命令。

HUD 与 session 锚定：HUD 状态严格限定于当前 OMX session

HUD 状态现在严格作用于当前活动的 OMX session，原生 session-id 漂移不再导致传输失败从 HUD 中静默消失（#1453、#1458）。

源码依据在 src/hud/session-attached.ts：HUD 通过display-message -p -t <paneId> '#{session_attached}'判断是否有 tmux client 附着到该 HUD pane 所属的 session，从而锚定 HUD 状态；0.12.5 在此之上修复了 session-id 漂移导致的状态错位。

Ralph stop-hook session 隔离：stop-hook 不再跨 session 泄漏

跨 session 的 stop-hook 泄漏被消除。stop hook 现在在 gating 之前先校验 session 权威性（PR #1466，issue #1461），确保一个 session 的停止钩子不会被另一个 session 误触发。

当前任务基线护栏：团队 worker 锚定正确的起始 commit

新增按任务维度的基线分支跟踪，让团队 worker 始终锚定在其正确的起始 commit 上，避免长时间运行任务期间出现 branch-skew（分支偏移）。该功能由 PR #1419 引入，对应 issue #1407。

新增能力

当前任务基线分支护栏

这是 0.12.5 中少有的"Added"类新增，实现位于 src/team/current-task-baseline.ts。其核心数据结构如下：

export type CurrentTaskStatus = 'active' | 'merged' | 'closed' | 'superseded'; export interface CurrentTaskBaselineEntry { branch_name: string; worktree_path: string | null; base_ref?: string; issue_number?: number; pr_number?: number; pr_url?: string; status: CurrentTaskStatus; created_at: string; updated_at: string; } interface CurrentTaskBaselineFile { version: 1; tasks: CurrentTaskBaselineEntry[]; }

持久化文件位于仓库.omx状态目录下的current-task-baseline.json（version: 1），并提供以下操作函数：

• readCurrentTaskBaseline/writeCurrentTaskBaseline：读写基线文件，读取时校验version === 1且tasks为数组，worktree_path会解析为绝对路径，损坏数据安全回退为空基线；
• listActiveCurrentTasks：仅返回status === 'active'的任务；
• findActiveCurrentTaskByBranch：按分支名查找活动任务；
• upsertCurrentTaskBaseline：以分支名为键做插入或更新，缺失的worktree_path沿用旧值，status默认'active'；
• assertCurrentTaskBranchAvailable：守卫函数，若同一分支已绑定到其他 worktree，则抛出current_task_branch_guard:<branch>:<worktree>错误。

这套机制保证团队 worker 在长时间运行中不会因分支被复用或 worktree 迁移而产生分支偏移。

多工作流重叠支持（不破坏 session 可见性）

规范状态中支持经批准的 multi-workflow 重叠，同时不破坏 session 可见性（PR #1427）。这是对多工作流状态管理的一次收紧，允许合规的工作流重叠共存，但禁止它们污染 session 归属。

Windows notify hook 的ps回退

为没有原生ps的 Windows 系统提供 notify hook 的ps回退（PR #1457），使通知钩子在 Windows 上也能追踪进程。

团队启动 / 关闭修复

• 停滞 worker 启动不再挂死团队 boot（PR #1444）：与 Highlights 中团队启动恢复对应。
• 跨 session 陈旧根团队 Stop 阻塞消除（PR #1451）：根团队 Stop 不再被其他 session 残留状态阻塞。
• Linux tmux 启动交接与关闭状态持久化（PR #1438）：补全 Linux 上 tmux 启动时的交接逻辑，并确保关闭状态可持久化。
• session.json所有权与回退语义收紧（PR #1447）：陈旧指针不再能"复活"错误的运行时状态。session 状态文件的归属校验与回退语义被强化，避免残留状态误导新 session。

多技能 / 工作流状态修复

• 混合工作流提示路由保留规划状态（PR #1471，issue #1353）：见 Highlights。
• 工作流交接正确性（PR #1442）：reconciliation 阶段拒绝畸形状态；陈旧状态不再阻塞真实交接。
• Flaky hook 与 HUD 状态作用域解决（PR #1446）：CI 对齐的 session 作用域 hook 契约被强制执行。

Windows 修复细节

• 分割 pane 关闭（PR #1470，issue #1353）：陈旧的 leader-pane ID 不再误导关闭信号。
• 原生 psmux worker 启动（PR #1469，issue #1361）：worker 从解析后的 Codex launcher 路径启动。
• MCP 孤儿清理（PR #1437，issue #1435）：Windows MCP 子进程不再在父进程退出后存活。
• 退役团队 MCP 配置修复（PR #1436）：omx doctor与启动路径在升级时对齐退役条目。

tmux / macOS / shell 修复

• 分离 tmux 启动 cwd（PR #1468，issue #1374）：pane 在请求的目录中启动。
• 受支持 shell 启动保持 worker cwd（PR #1460）：zsh、bash 启动时保留工作目录。
• Homebrew zsh 路径规范化（PR #1462，issue #1439）：macOS 上 pane 启动前规范化路径。
• tmux 启动 PID 解析加固（PR #1459）：attach 后清理 copy-mode。

HUD / session 锚定修复

• HUD 状态锚定到活动 OMX session（PR #1453）：跨 session 的 HUD 漂移被消除。
• 原生 session-id 漂移不再隐藏团队传输失败（PR #1458）：HUD 能够正确呈现团队传输失败。

deep-interview 修复

• 停止自动延续不再在提问阶段触发（PR #1473，issue #1472）：deep-interview 的 intent-first 提问阶段现在被视为 planning（供原生停滞检测使用），而不是被强制 continuation。

Explore harness 修复

omx explore现在在 cargo 是 rustup shim 且未配置默认 toolchain 时，输出清晰可操作的错误，而不是暴露原始的 rustup 错误。错误信息引导用户使用rustup default stable、设置OMX_EXPLORE_BIN，或运行omx doctor。实现位于 src/cli/explore.ts。

同时，该文件还包含针对 Windows 的探测逻辑：由于内置 explore harness 的 allowlist 运行时依赖 POSIX sh/bash 包装器，Windows 下不可用，此时建议设置OMX_EXPLORE_BIN指向兼容的自定义 harness、改用omx sparkshell进行 shell 原生只读查询，或运行omx doctor查看就绪详情。

Hooks / auth / notify 修复

• Ralph stop-hook 跨 session 泄漏消除（PR #1466，issue #1461）：见 Highlights。
• 自动 nudge 授权泄漏（PR #1434，issue #1416）：只读与 planning 流程不再收到 full-execution 的 nudge。
• Notify hooks 在粗粒度状态漂移下持续追踪活团队（PR #1428）。
• Launcher 支撑的 MCP 重启停滞有界化（PR #1408）：重启停滞被限制在可接受边界内。

文档变更

• 从 README 移除过时的prompts/调用指引（PR #1417），避免用户被陈旧用法误导。

升级与验证建议

1. 升级后先运行omx doctor校验安装形态，确认团队 MCP 配置与 explore harness 环境（尤其 Windows 或 rustup 环境）就绪。
2. 通过omx exec验证当前 Codex 运行时能真正完成模型调用。
3. 若要复跑 0.12.5 的官方验证证据，依次执行npm run build、npm run lint、npm test以及npm run smoke:packed-install。
4. 团队场景下，可检查.omx/current-task-baseline.json确认各 worker 分支的status、worktree_path与base_ref是否与预期一致，借助基线护栏避免分支偏移。

【免费下载链接】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