OmX 0.14.2 补丁发布解析omx question 可靠渲染、MCP 重复进程自清理与 deep-interview 状态加固【免费下载链接】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本文以 OmXOh My codeX0.14.2 补丁版发布说明为骨架逐项剖析这次快速跟进fast-follow版本在问题渲染、MCP 生命周期、deep-interview 状态机、多语言输入路由与工具链基线上的可靠性修复。读者将理解omx question在 tmux 内外的 fail-closed 策略与共享提交语义、重复 MCP 兄弟进程的闲置自退出机制、会话级清空墓碑tombstone如何压制陈旧根状态并掌握每个修复背后的源码级实现与可验证证据。版本定位0.14.1 之后的快速跟进补丁0.14.2是0.14.1之后的补丁版本patch release其发布说明docs/release-notes-0.14.2.md将本次迭代定性为聚焦快速跟进操作员可靠性fast-follow operator reliability的发布。补丁覆盖了六个彼此独立但都影响日常操作体验的问题域omx question渲染安全在未附加attached的 tmux 窗格外运行omx question时不再静默创建不可见的分离式 tmux 会话而是直接向操作员返回清晰的错误MCP 重复进程治理同一父进程下的旧 stdio 重复服务器duplicate siblings可在安全的流量空闲窗口后自行退出遏制陈旧 MCP 服务器堆积deep-interview 状态加固会话级模式清空在必要时留下非活动会话墓碑避免遗留根回退状态立即重新激活模式失败的提问启动会清除挂起的 deep-interview 义务多语言输入路由韩文 2-set 键盘下ulw简写的 IME 漂移输入ㅕㅣㅈ能正确归一化后触发 ultrawork 简写提交语义统一omx question答案注入复用与 reply-listener 一致的 tmux 窗格发送路径工具链基线刷新TypeScript 升级至6.0.3Biome 锁文件元数据刷新至2.4.12。配套的发布就绪评估记录在 docs/qa/release-readiness-0.14.2.md其中给出了完整的范围审查、代码审查证据与验证结果。omx question渲染策略与 fail-closed 修复渲染策略矩阵omx question的渲染器启动逻辑集中在 src/question/renderer.ts核心入口resolveQuestionRendererStrategysrc/question/renderer.ts#L81-L105根据环境信号选择渲染策略共支持七种策略触发条件test-noop环境变量OMX_QUESTION_TEST_RENDERERnoop测试专用windows-psmux-shell-paneWindows TMUX含psmux或存在TMUX_PANEwindows-consoleWindows 且存在显式提问返回窗格目标inside-tmux存在TMUX环境变量、显式窗格目标或持久化返回目标inline-ttyWindows 下 stdin/stdout 均为 TTYdetached-tmux历史上用于分离式 tmux 会话渲染unsupported以上均不满足fail-closed不再静默创建分离渲染器在 0.14.2 之前当进程位于 tmux 之外且没有任何可见渲染器信号时omx question可能退化为创建分离式detachedtmux 会话——用户在 Codex App 或非 tmux 终端里提问渲染器却悄悄开在看不见的地方。0.14.2 改为 fail-closed当策略判定为unsupported时launchQuestionRenderer直接抛出带有明确指引的错误src/question/renderer.ts#L829-L833omx question cannot open a visible renderer because this process is outside an attached tmux pane and has no explicit tmux return bridge. Codex App/outside-tmux sessions need an attached tmux OMX CLI session orOMX_QUESTION_RETURN_PANEbridge. Run omx question from inside tmux.同时inside-tmux分支也新增了附加性检查如果TMUX存在但当前 tmux 会话没有附加客户端#{session_attached}为 0同样抛错并提示从附加的 tmux 窗格运行src/question/renderer.ts#L867-L871。回归测试证明该路径不会再创建 detached tmux 会话见 src/question/tests/renderer.test.ts。渲染器的探测、销毁与存活保障围绕渲染器还有一套完整的生命周期辅助resolveAvailablePaneHeight/Width通过tmux display-message -p #{pane_height}探测窗格尺寸探测失败回退 80 列 / 40 行estimateQuestionRenderFootprint依据问题记录计算渲染足迹配合computeAdaptiveQuestionPaneHeight与shouldOpenQuestionInNewWindow决定用split-window -v -l分窗还是new-window开新窗口isLaunchedQuestionPaneAlive用#{pane_dead}校验窗格存活closeQuestionRenderer负责kill-pane/kill-session回收。渲染器进程实际执行omx question --ui --state-path recordPathsrc/question/renderer.ts#L332-L346问题记录以 JSON 形式落盘于状态目录下的questions/子目录记录格式要求kind omx.question/v1且携带question_id。共享 tmux 提交语义buildSendPaneArgvs 统一答案注入三处注入收敛为一条路径0.14.2 修复了omx question答案提交与通知 reply-listener 窗格注入之间的漂移injectQuestionAnswerToPane与injectQuestionAnswersToPanesrc/question/renderer.ts#L694-L733现在与 reply-listener 共用src/notifications/tmux-detector.ts中导出的buildSendPaneArgvs。在此之前提问渲染器与回复监听器各自维护一套 send-keys 参数构造逻辑文本提交细节容易分叉。提交语义的三条硬性规则buildSendPaneArgvssrc/notifications/tmux-detector.ts#L89-L113将注入语义收敛为三条可测试的硬性规则换行净化文本中的\r?\n一律替换为空格防止换行在字面发送时被当作提交按键字面发送防注入使用send-keys -t pane -l -- text-lliteral确保文本中的 tmux 键名不会被解释为按键--防止以-开头的文本被解析为 tmux 标志——注释明确引用 issue #107 与 #156 的注入教训隔离的 C-m 提交C-m回车始终单独成一次send-keys调用且发送两次Codex CLI 使用 raw input mode需要两次回车可靠提交绝不与文本载荷捆绑杜绝通过文本内嵌C-m触发提交的注入面。sendToPanesrc/notifications/tmux-detector.ts#L147-L173在逐条执行这些 argv 时还引入时间节奏首次发送后等待TMUX_TEXT_SETTLE_MS120ms后续提交之间等待TMUX_SUBMIT_REPEAT_DELAY_MS100ms。提问渲染器侧同样维持QUESTION_TEXT_SETTLE_MS与QUESTION_SUBMIT_REPEAT_DELAY_MS常量保证文本送达与提交之间的节奏一致。双层净化在buildSendPaneArgvs的换行处理之上还有一层sanitizeReplyInputsrc/notifications/reply-listener.ts#L337它剥离控制字符、合并多余空白、对反引号与$()、${}做转义防止文本被解释为 shell 展开。测试用例src/notifications/tests/reply-listener.test.ts覆盖了 NUL/ESC/换行/$(whoami)/${HOME}等注入向量。注入到窗格的文本统一带[omx question answered]前缀见formatQuestionAnswerForInjection使下游能识别答案来源。MCP 重复兄弟进程安全空闲后的自清理问题背景第一方 MCP 服务器state、memory、code_intel、trace、wiki、hermes以 stdio 方式按需自动启动。当同一父进程为同一入口点反复拉起新实例时旧实例可能堆积——尤其是 Codex App 这类长期存活父进程跨会话复用场景。0.14.2 在 src/mcp/bootstrap.ts 中把重复兄弟清理从仅限未处理流量的早期退出扩展为可在安全的后流量空闲窗口自退出。判定与退出逻辑analyzeDuplicateSiblingStatesrc/mcp/bootstrap.ts#L222-L290通过ps axww -o pid,ppid,commandWindows 下走 PowerShellGet-CimInstance Win32_Process读取进程表按ppid同父 入口点标记extractMcpEntrypointMarker匹配*-server.js或mcp-serve target分组将当前进程归类为ambiguous/unique/newest/older_duplicate——PID 较大的更新兄弟存活旧兄弟被标记为重复。随后的退出判定由三个守卫组成流量前宽限shouldSelfExitForDuplicateSibling在无流量时要求重复状态持续超过duplicateSiblingPreTrafficGraceMs默认 2000ms才退出流量后空闲一旦收到过 stdin 字节意味着客户端已初始化该传输要求自重复观察与最近流量二者中较晚时刻起空闲满duplicateSiblingPostTrafficIdleMs默认 60000ms才退出——这是 0.14.2 新增的关键路径硬上限shouldSelfExitForPreTrafficSiblingHardCap/shouldSelfExitForPostTrafficSiblingHardCap在同入口点兄弟数超过OMX_MCP_MAX_SIBLINGS_PER_ENTRYPOINT默认 4时仅淘汰最旧的、且流量后场景已被取代满整个空闲窗口的实例。可调时序与观测整个生命周期时序均可通过环境变量覆盖src/mcp/bootstrap.ts#L19-L32环境变量默认值含义OMX_MCP_PARENT_WATCHDOG_INTERVAL_MS1000父进程存活探测间隔OMX_MCP_DUPLICATE_SIBLING_WATCHDOG_INTERVAL_MS5000重复兄弟看门狗扫描间隔OMX_MCP_DUPLICATE_SIBLING_PRE_TRAFFIC_GRACE_MS2000流量前重复宽限期OMX_MCP_DUPLICATE_SIBLING_POST_TRAFFIC_IDLE_MS60000流量后空闲退出窗口OMX_MCP_DUPLICATE_SIBLING_INITIAL_DELAY_MS未设置自动抖动初始延迟固定值OMX_MCP_DUPLICATE_SIBLING_INITIAL_DELAY_MAX_MS1000初始延迟抖动上限按入口点哈希OMX_MCP_MAX_SIBLINGS_PER_ENTRYPOINT4每入口点保留的兄弟数上限OMX_MCP_ENTRYPOINT_MARKER—显式入口点标记OMX_MCP_TRANSPORT_DEBUG关闭开启后输出生命周期调试日志初始延迟通过stableStringHash(server:entrypoint) % (maxMs 1)做确定性抖动避免多服务器同时启动时扫描撞车duplicateObservedAtMs与lastTrafficAtMs两个时间戳驱动全部闲置判定。生命周期事件bootstrap_start、duplicate_sibling_observed、shutdown等会写入lifecycle-telemetry退出原因包括superseded_duplicate_after_idle、superseded_duplicate_before_traffic、superseded_hard_cap_pre_traffic、superseded_hard_cap_post_traffic等便于事后归因。回归测试src/mcp/tests/bootstrap.test.ts、src/mcp/tests/server-lifecycle.test.ts验证了旧重复在流量后空闲退出、最新兄弟存活的行为。deep-interview 状态机加固墓碑与义务清理会话级清空墓碑deep-interview 状态按会话作用域session-scoped管理但历史版本存在根级回退状态root fallback state。0.14.2 修复了一个棘手的复活问题当会话级模式被清空、但根目录还残留旧状态文件时遗留的根回退状态可能让已清空的模式立即重新激活。修复方式是会话级清空在发现存在遗留根回退文件时写入一个非活动的current_phase: cleared墓碑压制根状态回退实现涉及 src/state/operations.ts 与 src/mcp/state-server.ts。测试src/state/tests/operations.test.ts、src/mcp/tests/state-server.test.ts、src/cli/tests/session-scoped-runtime.test.ts验证了 CLI、MCP、status/read 三个界面下已清空的会话作用域保持非活动deep-interview: inactive (phase: cleared)。失败提问清理挂起义务deep-interview 在提问时会向 Autopilot 状态写入挂起义务pending obligation包含obligation_id、question_id、状态等字段。若提问启动失败此前义务可能残留导致后续会话被陈旧的门禁卡住。0.14.2 确保一旦提问渲染器启动失败立即清除挂起义务。对应测试src/question/tests/deep-interview.test.ts#L140-L193覆盖了提问失败后清理挂起义务与渲染器启动失败后清理挂起义务两个场景另有测试验证提问返回后满足义务与从已答复记录调和义务的完整生命周期。后台提问终端的指引闭环0.14.2 同时补齐了指引层面的缺口skills/deep-interview/SKILL.md、templates/AGENTS.md 与 src/scripts/codex-native-hook.ts 中现在明确要求 Agent 等待后台omx question终端执行完毕、读取 JSON 答案后再继续访谈关键字路由也避免仅凭cleanup / state-management等措辞触发 deep-interview 激活回归用例见 src/hooks/tests/keyword-detector.test.ts如cleanup stale deep-interview state after session clear不触发。这一改动同时服务于显式终端停止模型访谈是阻塞性门禁必须有明确的完成信号。多语言输入路由韩文 IME 漂移与 ulw 简写0.14.2 的发布说明记载韩文 2-set 键盘下用户输入ㅕㅣㅈulw的 IME 漂移形态时关键字检测会在激活前将其归一化为既有的ulwultrawork 简写。当时的实现位于 src/hooks/keyword-detector.ts 的normalizeWorkflowKeyboardTypos。需要说明的是从当前仓库源码看该归一化函数已变为 no-opsrc/hooks/keyword-detector.ts#L1294-L1304注释解释其原因——ulw唯一的目标是 ultrawork 技能而 ultrawork 如今是已下线的 sunset 技能不再有触发入口继续把漂移输入映射到一个已移除的技能没有意义函数缝seam被保留以便未来新增活跃简写时可以有意识地接入而非复活对已移除技能的映射。对应的回归测试src/hooks/tests/keyword-detector.test.ts也验证了ㅕㅣㅈ로 이 작업 처리해줘与$ㅕㅣㅈ로 이 작업 처리해줘在当前不再路由到任何技能。这一演进恰好体现了 OmX 关键字路由的一个设计原则归一化映射的生命周期必须跟随目标技能的生命周期避免把用户输入导向已不存在的入口。工具链基线刷新0.14.2 同步刷新了开发工具链基线TypeScript6.0.3package.json与package-lock.json对齐Biome2.4.12锁文件元数据刷新tsconfig.json为 TS 6 构建路径显式固定 Node 环境类型ambient types。配套的发布元数据Cargo.toml、Cargo.lock、CHANGELOG.md、RELEASE_BODY.md、本发布说明同步对齐到0.14.2。验证证据与剩余风险发布门禁0.14.2 的发布验证证据记录在 docs/qa/release-readiness-0.14.2.md检查项结果npm run lint✅npm test✅cargo test -p omx-explore-harness -p omx-sparkshell✅npm pack --dry-run✅$code-reviewv0.14.1..dev范围code-reviewerCOMMENT、architectWATCH无阻塞性发现已知的非阻塞风险发布说明与就绪报告共同列出了四项 architect 关注的后续清理项均不阻塞发布已清空会话墓碑辅助逻辑在 CLI 与 MCP 两条状态路径中重复operations.ts与state-server.ts各有一份分离式提问渲染器代码作为遗留分支保留但正常策略解析不再选择它resolveQuestionRendererStrategy已不会返回detached-tmuxMCP 重复清理仍依赖保守的进程/时序启发式同父、进程年龄、流量空闲窗口而非更确定的协调协议deep-interview 指引文案在多个发布面技能、模板、原生钩子重复维护。此外本次就绪评估是本地发布通道local release-readiness pass并非完整 CI 矩阵重跑发布后最有价值的观测面仍是真实 tmux / 复用会话下的omx question、提示词提交、工作流/状态清空、MCP 重复兄弟清理以及多语言输入触发工作流的实机行为。小结0.14.2 是一次典型的补丁含金量示范六个独立的可靠性修复各自都有明确的源码落点与回归测试兜底——omx question的 fail-closed 策略src/question/renderer.ts、共享提交语义buildSendPaneArgvssrc/notifications/tmux-detector.ts、MCP 重复兄弟闲置自退出src/mcp/bootstrap.ts、deep-interview 墓碑与义务清理src/state/operations.ts、关键字归一化的生命周期纪律src/hooks/keyword-detector.ts外加工具链基线刷新。对于 OmX 使用者0.14.2 意味着提问界面不再凭空消失、陈旧 MCP 进程不会无限堆积、已清空的 deep-interview 不会被根状态悄悄复活、失败提问不会留下卡住后续会话的义务残留——每一项都是把操作员可靠性落到实处的具体工程改进。【免费下载链接】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），仅供参考 OmX 0.14.2 补丁发布解析：omx question 可靠渲染、MCP 重复进程自清理与 deep-interview 状态加固
OmX 0.14.2 补丁发布解析omx question 可靠渲染、MCP 重复进程自清理与 deep-interview 状态加固【免费下载链接】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本文以 OmXOh My codeX0.14.2 补丁版发布说明为骨架逐项剖析这次快速跟进fast-follow版本在问题渲染、MCP 生命周期、deep-interview 状态机、多语言输入路由与工具链基线上的可靠性修复。读者将理解omx question在 tmux 内外的 fail-closed 策略与共享提交语义、重复 MCP 兄弟进程的闲置自退出机制、会话级清空墓碑tombstone如何压制陈旧根状态并掌握每个修复背后的源码级实现与可验证证据。版本定位0.14.1 之后的快速跟进补丁0.14.2是0.14.1之后的补丁版本patch release其发布说明docs/release-notes-0.14.2.md将本次迭代定性为聚焦快速跟进操作员可靠性fast-follow operator reliability的发布。补丁覆盖了六个彼此独立但都影响日常操作体验的问题域omx question渲染安全在未附加attached的 tmux 窗格外运行omx question时不再静默创建不可见的分离式 tmux 会话而是直接向操作员返回清晰的错误MCP 重复进程治理同一父进程下的旧 stdio 重复服务器duplicate siblings可在安全的流量空闲窗口后自行退出遏制陈旧 MCP 服务器堆积deep-interview 状态加固会话级模式清空在必要时留下非活动会话墓碑避免遗留根回退状态立即重新激活模式失败的提问启动会清除挂起的 deep-interview 义务多语言输入路由韩文 2-set 键盘下ulw简写的 IME 漂移输入ㅕㅣㅈ能正确归一化后触发 ultrawork 简写提交语义统一omx question答案注入复用与 reply-listener 一致的 tmux 窗格发送路径工具链基线刷新TypeScript 升级至6.0.3Biome 锁文件元数据刷新至2.4.12。配套的发布就绪评估记录在 docs/qa/release-readiness-0.14.2.md其中给出了完整的范围审查、代码审查证据与验证结果。omx question渲染策略与 fail-closed 修复渲染策略矩阵omx question的渲染器启动逻辑集中在 src/question/renderer.ts核心入口resolveQuestionRendererStrategysrc/question/renderer.ts#L81-L105根据环境信号选择渲染策略共支持七种策略触发条件test-noop环境变量OMX_QUESTION_TEST_RENDERERnoop测试专用windows-psmux-shell-paneWindows TMUX含psmux或存在TMUX_PANEwindows-consoleWindows 且存在显式提问返回窗格目标inside-tmux存在TMUX环境变量、显式窗格目标或持久化返回目标inline-ttyWindows 下 stdin/stdout 均为 TTYdetached-tmux历史上用于分离式 tmux 会话渲染unsupported以上均不满足fail-closed不再静默创建分离渲染器在 0.14.2 之前当进程位于 tmux 之外且没有任何可见渲染器信号时omx question可能退化为创建分离式detachedtmux 会话——用户在 Codex App 或非 tmux 终端里提问渲染器却悄悄开在看不见的地方。0.14.2 改为 fail-closed当策略判定为unsupported时launchQuestionRenderer直接抛出带有明确指引的错误src/question/renderer.ts#L829-L833omx question cannot open a visible renderer because this process is outside an attached tmux pane and has no explicit tmux return bridge. Codex App/outside-tmux sessions need an attached tmux OMX CLI session orOMX_QUESTION_RETURN_PANEbridge. Run omx question from inside tmux.同时inside-tmux分支也新增了附加性检查如果TMUX存在但当前 tmux 会话没有附加客户端#{session_attached}为 0同样抛错并提示从附加的 tmux 窗格运行src/question/renderer.ts#L867-L871。回归测试证明该路径不会再创建 detached tmux 会话见 src/question/tests/renderer.test.ts。渲染器的探测、销毁与存活保障围绕渲染器还有一套完整的生命周期辅助resolveAvailablePaneHeight/Width通过tmux display-message -p #{pane_height}探测窗格尺寸探测失败回退 80 列 / 40 行estimateQuestionRenderFootprint依据问题记录计算渲染足迹配合computeAdaptiveQuestionPaneHeight与shouldOpenQuestionInNewWindow决定用split-window -v -l分窗还是new-window开新窗口isLaunchedQuestionPaneAlive用#{pane_dead}校验窗格存活closeQuestionRenderer负责kill-pane/kill-session回收。渲染器进程实际执行omx question --ui --state-path recordPathsrc/question/renderer.ts#L332-L346问题记录以 JSON 形式落盘于状态目录下的questions/子目录记录格式要求kind omx.question/v1且携带question_id。共享 tmux 提交语义buildSendPaneArgvs 统一答案注入三处注入收敛为一条路径0.14.2 修复了omx question答案提交与通知 reply-listener 窗格注入之间的漂移injectQuestionAnswerToPane与injectQuestionAnswersToPanesrc/question/renderer.ts#L694-L733现在与 reply-listener 共用src/notifications/tmux-detector.ts中导出的buildSendPaneArgvs。在此之前提问渲染器与回复监听器各自维护一套 send-keys 参数构造逻辑文本提交细节容易分叉。提交语义的三条硬性规则buildSendPaneArgvssrc/notifications/tmux-detector.ts#L89-L113将注入语义收敛为三条可测试的硬性规则换行净化文本中的\r?\n一律替换为空格防止换行在字面发送时被当作提交按键字面发送防注入使用send-keys -t pane -l -- text-lliteral确保文本中的 tmux 键名不会被解释为按键--防止以-开头的文本被解析为 tmux 标志——注释明确引用 issue #107 与 #156 的注入教训隔离的 C-m 提交C-m回车始终单独成一次send-keys调用且发送两次Codex CLI 使用 raw input mode需要两次回车可靠提交绝不与文本载荷捆绑杜绝通过文本内嵌C-m触发提交的注入面。sendToPanesrc/notifications/tmux-detector.ts#L147-L173在逐条执行这些 argv 时还引入时间节奏首次发送后等待TMUX_TEXT_SETTLE_MS120ms后续提交之间等待TMUX_SUBMIT_REPEAT_DELAY_MS100ms。提问渲染器侧同样维持QUESTION_TEXT_SETTLE_MS与QUESTION_SUBMIT_REPEAT_DELAY_MS常量保证文本送达与提交之间的节奏一致。双层净化在buildSendPaneArgvs的换行处理之上还有一层sanitizeReplyInputsrc/notifications/reply-listener.ts#L337它剥离控制字符、合并多余空白、对反引号与$()、${}做转义防止文本被解释为 shell 展开。测试用例src/notifications/tests/reply-listener.test.ts覆盖了 NUL/ESC/换行/$(whoami)/${HOME}等注入向量。注入到窗格的文本统一带[omx question answered]前缀见formatQuestionAnswerForInjection使下游能识别答案来源。MCP 重复兄弟进程安全空闲后的自清理问题背景第一方 MCP 服务器state、memory、code_intel、trace、wiki、hermes以 stdio 方式按需自动启动。当同一父进程为同一入口点反复拉起新实例时旧实例可能堆积——尤其是 Codex App 这类长期存活父进程跨会话复用场景。0.14.2 在 src/mcp/bootstrap.ts 中把重复兄弟清理从仅限未处理流量的早期退出扩展为可在安全的后流量空闲窗口自退出。判定与退出逻辑analyzeDuplicateSiblingStatesrc/mcp/bootstrap.ts#L222-L290通过ps axww -o pid,ppid,commandWindows 下走 PowerShellGet-CimInstance Win32_Process读取进程表按ppid同父 入口点标记extractMcpEntrypointMarker匹配*-server.js或mcp-serve target分组将当前进程归类为ambiguous/unique/newest/older_duplicate——PID 较大的更新兄弟存活旧兄弟被标记为重复。随后的退出判定由三个守卫组成流量前宽限shouldSelfExitForDuplicateSibling在无流量时要求重复状态持续超过duplicateSiblingPreTrafficGraceMs默认 2000ms才退出流量后空闲一旦收到过 stdin 字节意味着客户端已初始化该传输要求自重复观察与最近流量二者中较晚时刻起空闲满duplicateSiblingPostTrafficIdleMs默认 60000ms才退出——这是 0.14.2 新增的关键路径硬上限shouldSelfExitForPreTrafficSiblingHardCap/shouldSelfExitForPostTrafficSiblingHardCap在同入口点兄弟数超过OMX_MCP_MAX_SIBLINGS_PER_ENTRYPOINT默认 4时仅淘汰最旧的、且流量后场景已被取代满整个空闲窗口的实例。可调时序与观测整个生命周期时序均可通过环境变量覆盖src/mcp/bootstrap.ts#L19-L32环境变量默认值含义OMX_MCP_PARENT_WATCHDOG_INTERVAL_MS1000父进程存活探测间隔OMX_MCP_DUPLICATE_SIBLING_WATCHDOG_INTERVAL_MS5000重复兄弟看门狗扫描间隔OMX_MCP_DUPLICATE_SIBLING_PRE_TRAFFIC_GRACE_MS2000流量前重复宽限期OMX_MCP_DUPLICATE_SIBLING_POST_TRAFFIC_IDLE_MS60000流量后空闲退出窗口OMX_MCP_DUPLICATE_SIBLING_INITIAL_DELAY_MS未设置自动抖动初始延迟固定值OMX_MCP_DUPLICATE_SIBLING_INITIAL_DELAY_MAX_MS1000初始延迟抖动上限按入口点哈希OMX_MCP_MAX_SIBLINGS_PER_ENTRYPOINT4每入口点保留的兄弟数上限OMX_MCP_ENTRYPOINT_MARKER—显式入口点标记OMX_MCP_TRANSPORT_DEBUG关闭开启后输出生命周期调试日志初始延迟通过stableStringHash(server:entrypoint) % (maxMs 1)做确定性抖动避免多服务器同时启动时扫描撞车duplicateObservedAtMs与lastTrafficAtMs两个时间戳驱动全部闲置判定。生命周期事件bootstrap_start、duplicate_sibling_observed、shutdown等会写入lifecycle-telemetry退出原因包括superseded_duplicate_after_idle、superseded_duplicate_before_traffic、superseded_hard_cap_pre_traffic、superseded_hard_cap_post_traffic等便于事后归因。回归测试src/mcp/tests/bootstrap.test.ts、src/mcp/tests/server-lifecycle.test.ts验证了旧重复在流量后空闲退出、最新兄弟存活的行为。deep-interview 状态机加固墓碑与义务清理会话级清空墓碑deep-interview 状态按会话作用域session-scoped管理但历史版本存在根级回退状态root fallback state。0.14.2 修复了一个棘手的复活问题当会话级模式被清空、但根目录还残留旧状态文件时遗留的根回退状态可能让已清空的模式立即重新激活。修复方式是会话级清空在发现存在遗留根回退文件时写入一个非活动的current_phase: cleared墓碑压制根状态回退实现涉及 src/state/operations.ts 与 src/mcp/state-server.ts。测试src/state/tests/operations.test.ts、src/mcp/tests/state-server.test.ts、src/cli/tests/session-scoped-runtime.test.ts验证了 CLI、MCP、status/read 三个界面下已清空的会话作用域保持非活动deep-interview: inactive (phase: cleared)。失败提问清理挂起义务deep-interview 在提问时会向 Autopilot 状态写入挂起义务pending obligation包含obligation_id、question_id、状态等字段。若提问启动失败此前义务可能残留导致后续会话被陈旧的门禁卡住。0.14.2 确保一旦提问渲染器启动失败立即清除挂起义务。对应测试src/question/tests/deep-interview.test.ts#L140-L193覆盖了提问失败后清理挂起义务与渲染器启动失败后清理挂起义务两个场景另有测试验证提问返回后满足义务与从已答复记录调和义务的完整生命周期。后台提问终端的指引闭环0.14.2 同时补齐了指引层面的缺口skills/deep-interview/SKILL.md、templates/AGENTS.md 与 src/scripts/codex-native-hook.ts 中现在明确要求 Agent 等待后台omx question终端执行完毕、读取 JSON 答案后再继续访谈关键字路由也避免仅凭cleanup / state-management等措辞触发 deep-interview 激活回归用例见 src/hooks/tests/keyword-detector.test.ts如cleanup stale deep-interview state after session clear不触发。这一改动同时服务于显式终端停止模型访谈是阻塞性门禁必须有明确的完成信号。多语言输入路由韩文 IME 漂移与 ulw 简写0.14.2 的发布说明记载韩文 2-set 键盘下用户输入ㅕㅣㅈulw的 IME 漂移形态时关键字检测会在激活前将其归一化为既有的ulwultrawork 简写。当时的实现位于 src/hooks/keyword-detector.ts 的normalizeWorkflowKeyboardTypos。需要说明的是从当前仓库源码看该归一化函数已变为 no-opsrc/hooks/keyword-detector.ts#L1294-L1304注释解释其原因——ulw唯一的目标是 ultrawork 技能而 ultrawork 如今是已下线的 sunset 技能不再有触发入口继续把漂移输入映射到一个已移除的技能没有意义函数缝seam被保留以便未来新增活跃简写时可以有意识地接入而非复活对已移除技能的映射。对应的回归测试src/hooks/tests/keyword-detector.test.ts也验证了ㅕㅣㅈ로 이 작업 처리해줘与$ㅕㅣㅈ로 이 작업 처리해줘在当前不再路由到任何技能。这一演进恰好体现了 OmX 关键字路由的一个设计原则归一化映射的生命周期必须跟随目标技能的生命周期避免把用户输入导向已不存在的入口。工具链基线刷新0.14.2 同步刷新了开发工具链基线TypeScript6.0.3package.json与package-lock.json对齐Biome2.4.12锁文件元数据刷新tsconfig.json为 TS 6 构建路径显式固定 Node 环境类型ambient types。配套的发布元数据Cargo.toml、Cargo.lock、CHANGELOG.md、RELEASE_BODY.md、本发布说明同步对齐到0.14.2。验证证据与剩余风险发布门禁0.14.2 的发布验证证据记录在 docs/qa/release-readiness-0.14.2.md检查项结果npm run lint✅npm test✅cargo test -p omx-explore-harness -p omx-sparkshell✅npm pack --dry-run✅$code-reviewv0.14.1..dev范围code-reviewerCOMMENT、architectWATCH无阻塞性发现已知的非阻塞风险发布说明与就绪报告共同列出了四项 architect 关注的后续清理项均不阻塞发布已清空会话墓碑辅助逻辑在 CLI 与 MCP 两条状态路径中重复operations.ts与state-server.ts各有一份分离式提问渲染器代码作为遗留分支保留但正常策略解析不再选择它resolveQuestionRendererStrategy已不会返回detached-tmuxMCP 重复清理仍依赖保守的进程/时序启发式同父、进程年龄、流量空闲窗口而非更确定的协调协议deep-interview 指引文案在多个发布面技能、模板、原生钩子重复维护。此外本次就绪评估是本地发布通道local release-readiness pass并非完整 CI 矩阵重跑发布后最有价值的观测面仍是真实 tmux / 复用会话下的omx question、提示词提交、工作流/状态清空、MCP 重复兄弟清理以及多语言输入触发工作流的实机行为。小结0.14.2 是一次典型的补丁含金量示范六个独立的可靠性修复各自都有明确的源码落点与回归测试兜底——omx question的 fail-closed 策略src/question/renderer.ts、共享提交语义buildSendPaneArgvssrc/notifications/tmux-detector.ts、MCP 重复兄弟闲置自退出src/mcp/bootstrap.ts、deep-interview 墓碑与义务清理src/state/operations.ts、关键字归一化的生命周期纪律src/hooks/keyword-detector.ts外加工具链基线刷新。对于 OmX 使用者0.14.2 意味着提问界面不再凭空消失、陈旧 MCP 进程不会无限堆积、已清空的 deep-interview 不会被根状态悄悄复活、失败提问不会留下卡住后续会话的义务残留——每一项都是把操作员可靠性落到实处的具体工程改进。【免费下载链接】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），仅供参考