OmX 0.14.3 补丁版解读提问面板返回可靠性、项目级 CODEX_HOME 与 HUD/清理链路的硬化实践【免费下载链接】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 codeX的0.14.3是紧随0.14.2发布的dev加固列车补丁版聚焦于一条主线让开发者在 tmux 多窗口环境下运行时omx question提问面板、深度访谈deep-interview、HUD 状态栏、进程清理与 Windows 原生 worker 面板在边界条件下不再丢状态、错窗口或误杀进程。本文以 docs/release-notes-0.14.3.md 为核心骨架结合 CHANGELOG.md 的0.14.3条目、docs/qa/release-readiness-0.14.3.md 的发布就绪证据以及src/question、src/cli、src/hud、src/config等目录的源码实现逐项拆解本次补丁修复了什么、为什么修、在源码里如何落地。读完你将掌握 OmX 提问渲染器的完整运行策略、deep-interview 状态机对账机制、setup 刷新对多行 TOML 的安全修复方式以及 HUD 窗口定位和 BusyBox 兼容清理的底层实现。一、版本定位0.14.3是什么0.14.3是一个面向dev加固列车的补丁版本patch release基线为v0.14.2发布就绪文档记录于 docs/qa/release-readiness-0.14.3.md。其变更面横跨九条主线question/deep-interview返回面板return-pane可靠性explore 启动的项目级project-localCODEX_HOME上下文setup TOML多行根级字符串修复安全tmux HUD窗口定位ultrawork 协议对齐BusyBox 清理兼容过期 Stop/autopilot 状态处理规范化 runtime supervisor 事件Docker 宿主 tmux 提问渲染与原生 Windows psmux worker 面板引导硬化。关键兼容性结论原文档已明确无需用户迁移0.14.3不改变任何持久化数据格式或 CLI 表面omx question保持 fail-closed 语义当不存在可见/可返回的 tmux 面板时提问命令会主动失败而不是把提示渲染到操作者看不见的地方项目级.codex用户收益update/setup refresh 后explore 等启动路径能获得更一致的启动行为。二、核心修复一omx question返回面板可靠性2.1 问题背景在 OmX 中omx question会在 tmux 内新开一个面板渲染交互式提问 UI操作者回答后答案要注入回发起提问的 leader 面板。此前在以下场景会丢失返回目标工具发起的提示、提示重新播种prompt reseeding、detached/visible 渲染路径、以及渲染器元数据竞态。2.2 渲染器策略的源码级解析返回目标的解析集中在 src/question/renderer.ts核心函数是resolveQuestionRendererStrategy与resolveReturnTarget。渲染器策略QuestionRendererStrategy共七种按优先级判定源码见 renderer.ts策略判定条件说明test-noop环境变量OMX_QUESTION_TEST_RENDERERnoop测试专用不真正创建面板windows-psmux-shell-panewin32且TMUX含psmux或TMUX_PANE为合法 pane id原生 Windows psmux 桥接windows-consolewin32且存在显式OMX_QUESTION_RETURN_PANE/OMX_LEADER_PANE_ID通过独立控制台窗口渲染inside-tmuxTMUX非空或存在显式返回目标或能从持久化状态读取到返回目标在 tmux 内 split/new-windowinline-ttywin32且 stdin/stdout 均为 TTY就地 TTY 交互unsupported其余情况抛出 fail-closed 错误返回目标resolveReturnTarget的解析优先级renderer.ts显式环境变量OMX_QUESTION_RETURN_PANE或OMX_LEADER_PANE_ID必须是%N形式的 pane id当前进程的TMUX_PANE持久化返回目标从TRACKED_WORKFLOW_MODES各模式的 state 文件getStatePath中读取active true且含合法tmux_pane_id的记录readPersistedQuestionReturnTarget兜底实时探测当前 tmux panegetCurrentTmuxPaneId。这套优先级设计解决了工具发起的提问场景提问进程通常不在交互式 leader 面板内直接运行而是由 hook/工具触发此时TMUX_PANE不可靠必须回退到持久化 state 或显式 bridge 环境变量。2.3 答案注入与渲染器生命周期答案注入使用injectQuestionAnswerToPane/injectQuestionAnswersToPane统一走buildSendPaneArgvs与 reply-listener 面板发送路径共享的 tmux send-keys 语义并包含字面量文本投递、换行消毒、独立C-m提交常量QUESTION_TEXT_SETTLE_MS 120、QUESTION_SUBMIT_REPEAT_DELAY_MS 100注入文本带前缀[omx question answered]formatQuestionAnswerForInjection支持other自定义答案与multi多选两种 answer kind渲染器存活检测isLaunchedQuestionPaneAlive通过list-panes -t pane -F #{pane_dead}\t#{pane_id}判断 pane 是否立即死亡isQuestionRendererAlive统一分派到 pane/session/windows-console 三类检测渲染器关闭closeQuestionRenderer对 tmux-pane 执行kill-pane -t pane对 tmux-session 执行kill-session同会话互斥新提问启动前会调用supersedeLiveQuestionsForSession把同会话内其他status prompting且渲染器仍存活的提问标记为superseded并关闭其渲染器防止同一会话堆积多个失效提问面板。2.4 自适应用户界面高度omx question会根据渲染内容估算占用行数estimateQuestionRenderFootprint考虑宽字符displayWidth与换行折叠再计算自适应 pane 高度computeAdaptiveQuestionPaneHeight若内容超过当前窗口可分高度shouldOpenQuestionInNewWindow则改用new-window打开完整窗口否则split-window -v -l height。宽度探测失败时保守回退 80 列确保渲染器在任何 tmux 环境下都能启动。三、核心修复二deep-interview 对账与汇总门控3.1 已回答问题不再重复追问原文档 Highlights 明确Deep-interview now reconciles answered question records before re-prompting。实现位于 src/question/deep-interview.ts每次发起 deep-interview 提问都会创建一条义务记录obligationDeepInterviewQuestionEnforcementState字段含obligation_id、statuspending | satisfied | cleared、lifecycle_outcome: askuserQuestion、requested_at、question_id、satisfied_at、clear_reasonhandoff | abort | error重新追问前调用reconcileDeepInterviewQuestionEnforcementFromAnsweredRecords若存在source deep-interview、status answered且created_at requested_at的已答记录isAnsweredDeepInterviewRecordForObligation则自动将 obligation 标记为satisfied不再重复提问义务状态持久化在deep-interview-state.jsongetStateFilePath定位随 session 隔离与 autopilot 联动提问前先claimAutopilotDeepInterviewQuestionWaiting若已有未决 wait claim 则抛出active_execution_mode_blocked成功后通过环境变量AUTOPILOT_DEEP_INTERVIEW_QUESTION_OWNER_ENV传递 obligation id完成或出错后分别以satisfied/cleared解析 wait 状态。3.2 超大澄清流汇总门控CHANGELOG 记录Deep-interview summary gates — oversized interview flows now require compact summaries before continuing当澄清问答流过大时流程必须先产出紧凑摘要才能继续避免对话上下文失控。该行为同时反映在 deep-interview 的 enforcement 状态迁移中——pending时强制lifecycle_outcome: askuserQuestion、run_outcome: blocked_on_user、active: false。四、核心修复三项目级CODEX_HOME与 explore 启动上下文原文档指出Project-scoped setup is respected during explore launches by resolving project-localCODEX_HOMEfrom persisted setup scope。从 CHANGELOG.md 与测试证据看更新/刷新update/setup refresh后launch/session 辅助逻辑会读取持久化的项目 setup scopesetup-scope.json测试覆盖见 src/cli/tests/update.test.ts 与 setup-scope 相关套件当 scope 为项目级时explore 启动将CODEX_HOME解析到项目.codex目录使会话、历史、配置都落在项目本地src/cli/tests/index.test.ts 中有一组专门测试验证只有持久化的项目CODEX_HOME才会被标记为 project-local 清理目标显式设置的环境变量CODEX_HOME不会被误标记同时验证了 legacyproject-local持久化 scope 会迁移为project并正确解析CODEX_HOME且在 setup root 之外启动不会把流量重定向进项目CODEX_HOME。需要说明的边界从源码看src/cli/explore.tsomx explore的直接命令面已 hard-deprecatedEXPLORE_DEPRECATION_MESSAGE当前仅保留--help其余用法一律失败并提示迁移到普通 Codex 仓库检视工具或omx sparkshell -- command。因此本次explore 启动尊重项目级CODEX_HOME实际作用在残留的 explore harness 启动/会话辅助路径含omx-explore-harness原生二进制解析resolvePackagedExploreHarnessCommand而非已删除的交互命令本身。五、核心修复四setup 刷新对多行 TOML 的修复安全原文档Setup refresh handles multiline root TOML assignments without orphaning fragments。实现位于 src/config/generator.ts新增TomlSourceStringMode四态词法跟踪basic...、literal...、multiline-basic...、multiline-literal...analyzeTomlSource逐字符扫描每个源行跟踪当前是否处于多行字符串内并记录lineStartsOutsideMultiline、lineHasTomlComment与isUnambiguous标记其注释明确表达了设计意图TOML 的 parser 提供语义而该词法分析防止源修复把多行值中类似 table 的文本当作语法处理——即修复器不再把内的[section]样式文本误判为 TOML 表结构从而避免 setup 刷新时拆散orphan根级字符串片段或破坏developer_instructions风格的值配套的repairConfigIfNeededgenerator.ts采用外科手术式修复addDefaultLauncherMcpStartupTimeouts、stripLegacyOmxTeamRunTable、dedupeTuiTables仅在检测到目标不兼容时才写回文件未检测到变更则返回false不落盘。测试证据changed-path 套件中包含 src/config/tests/generator-idempotent.test.js幂等性验证确保修复重复执行不会产生新差异。六、核心修复五HUD 对账窗口定位原文档HUD reconciliation targets the emitting tmux window, avoiding cross-window resize drift。从 src/hud/reconcile.ts 的实现看HUD 对账现在以触发事件的窗口为准leader 面板只有在该窗口内存在且存活非 dead才计为live跨窗口的 leader 面板不会被误伤源码注释明确sessions whose leader may legitimately live in a different tmux window we cannot see from this windows pane list are never touched修复了每次 prompt submit 后窗口被堆叠的 HUD 条填满的退化布局变更 hook 可能对同一窗口内多个 OMX pane 一起触发#L467附近注释对账会去重窗口过短时跳过拆分isTmuxWindowTooCrampedForHudSplit→status: skipped_window_too_cramped并在拆分后重新扫描窗口而非留下重复 HUD尺寸探测使用targetPaneId显式目标避免测量到另一个窗口的面板尺寸导致漂移。七、核心修复六BusyBox 兼容的进程清理原文档Cleanup supports BusyBoxpsby falling back from thecommandfield toargsonly for that compatibility failure。实现位于 src/cli/cleanup.tslistOmxProcesses默认执行ps axww -o pid,ppid,commandprocps 风格若失败isBusyBoxPsCommandFieldError用正则/bad -o argument []command[]|unsupported arguments:.*\bargs\b/i判断是否属于BusyBoxpsAlpine 默认拒绝command字段名的兼容性问题仅当确实是该失败时才用args字段重试ps axww -o pid,ppid,args其他ps失败照常抛出不掩盖真实错误。这种仅针对该兼容性失败回退的设计避免了把其他进程枚举错误误判为环境兼容问题。八、其余硬化项8.1 过期 Stop/autopilot 状态处理CHANGELOGNative Stop no longer loops on stale autopilot planning state——Stop 处理前会先清理/对账过期的 planning 状态避免 stop 信号在陈旧状态上重复循环src/hooks/*与src/scripts/codex-native-pre-post.ts相关测试覆盖见 src/scripts/tests/codex-native-hook.test.ts。8.2 规范化 runtime supervisor 事件CHANGELOG Added 条目Canonical supervisor runtime events——runtime command-event 契约新增 supervisor 控制与下游分发/就绪决策使用的规范化事件类型。相关契约文档见 docs/contracts/runtime-command-event-snapshot-schema.md测试覆盖src/scripts/notify-hook/__tests__/operational-events.test.js与src/team/__tests__/events.test.js、runtime.test.js。8.3 Docker 宿主 tmux 提问桥接CHANGELOG AddedDocker-host tmux question bridge——在 Docker 宿主环境下omx question可通过桥接 docker-host tmux 检测让操作者看到提示面板与 detached/visible 路径同属提示必须对操作者可见原则的一部分。8.4 原生 Windows psmux worker 面板引导0.14.3为原生 Windows 下的 psmux worker 启动引入引导硬化提问渲染新增windows-psmux-shell-pane策略见 2.2 节通过new-window -P -F #{pane_id}创建 shell 面板再用buildSendPaneArgvs逐段发送set KEYVALUE ... node 命令%与双重转义并追加C-m提交与 0.14.2 的 cmux 兼容设计一致cmux 的 tmux-compat shim 不消费split-window -e因此环境变量通过 shell 中立的env KEYVALUE ...前缀传递兼容 fish 等非 POSIX shell并整体单引号打包为单一 shell 命令参数。九、验证证据与发布就绪发布就绪文档 docs/qa/release-readiness-0.14.3.md 记录了全部门禁Gate门禁命令结果全量 Node/构建/catalog 套件npm testPASS — 3910 tests, 0 failedcatalog check ok未使用类型门禁npm run check:no-unusedPASSRust workspace 测试cargo test --workspacePASSLint 门禁npm run lintPASSTypeScript 构建npm run buildPASS变更路径定向套件node --test dist/cli/__tests__/{cleanup,explore,index,question}.test.js dist/config/__tests__/generator-idempotent.test.js dist/hooks/__tests__/{clawhip-event-contract,deep-interview-contract,keyword-detector,skill-guidance-contract}.test.js dist/hooks/extensibility/__tests__/events.test.js dist/hud/__tests__/reconcile.test.js dist/question/__tests__/{deep-interview,renderer,state,ui}.test.js dist/scripts/__tests__/codex-native-hook.test.js dist/scripts/notify-hook/__tests__/operational-events.test.js dist/team/__tests__/{events,runtime,tmux-session}.test.jsPASS已知限制外部 push/npm/GitHub 发布依赖仓库证据之外的本地凭据与网络可用性。结论为0.14.3可安全切 release commit/tag合并release/0.14.3至dev与main并打v0.14.3标签。十、实操验证与排查建议10.1 本地复现验证在已更新的仓库执行以下命令验证各修复路径npm test # 全量 Node 套件0.14.3 基线为 3910 passed npm run check:no-unused # 未使用类型门禁 cargo test --workspace # Rust workspace 测试 npm run lint npm run build # lint 与 TypeScript 构建若需定向复验本次变更路径可运行变更路径套件见上文验证证据表格中的node --test ...命令清单。10.2 常见问题速查omx question报 cannot open a visible renderer属于预期的 fail-closed 行为。确保在已 attach 的 tmux 会话内运行或显式设置OMX_QUESTION_RETURN_PANEpane-id/OMX_LEADER_PANE_IDpane-id建立返回桥清理时ps报bad -o argument commandBusyBox 兼容路径会自动用args重试无需手动干预其他ps错误仍会正常上抛项目级.codex启动行为不一致确认 setup scope 持久化为项目级.omx/setup-scope.json更新后再次 setup refresh 让CODEX_HOME解析到项目.codexHUD 跨窗口漂移确认对账 hook 按发射窗口定位leader 位于其他窗口时不会被本窗口对账误动。十一、小结0.14.3是典型的小版本、大硬化补丁它没有新增 CLI 表面或配置格式却把 tmux 多窗口环境下的提问返回链路显式环境变量 →TMUX_PANE→ 持久化 state → 实时探测四级回退、deep-interview 义务状态机pending/satisfied/cleared answered-record 对账、setup TOML 词法级修复、HUD 窗口本地化对账、BusyBoxargs字段回退、规范化 supervisor 事件与 Windows psmux 引导全部收敛为可测试的确定性行为。理解这些修复背后的源码决策如仅对该兼容性失败回退外科手术式修复fail-closed 可见性也能帮助你预判后续版本如 0.14.x 之后的同类硬化的方向与取舍。【免费下载链接】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.3 补丁版解读：提问面板返回可靠性、项目级 CODEX_HOME 与 HUD/清理链路的硬化实践
OmX 0.14.3 补丁版解读提问面板返回可靠性、项目级 CODEX_HOME 与 HUD/清理链路的硬化实践【免费下载链接】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 codeX的0.14.3是紧随0.14.2发布的dev加固列车补丁版聚焦于一条主线让开发者在 tmux 多窗口环境下运行时omx question提问面板、深度访谈deep-interview、HUD 状态栏、进程清理与 Windows 原生 worker 面板在边界条件下不再丢状态、错窗口或误杀进程。本文以 docs/release-notes-0.14.3.md 为核心骨架结合 CHANGELOG.md 的0.14.3条目、docs/qa/release-readiness-0.14.3.md 的发布就绪证据以及src/question、src/cli、src/hud、src/config等目录的源码实现逐项拆解本次补丁修复了什么、为什么修、在源码里如何落地。读完你将掌握 OmX 提问渲染器的完整运行策略、deep-interview 状态机对账机制、setup 刷新对多行 TOML 的安全修复方式以及 HUD 窗口定位和 BusyBox 兼容清理的底层实现。一、版本定位0.14.3是什么0.14.3是一个面向dev加固列车的补丁版本patch release基线为v0.14.2发布就绪文档记录于 docs/qa/release-readiness-0.14.3.md。其变更面横跨九条主线question/deep-interview返回面板return-pane可靠性explore 启动的项目级project-localCODEX_HOME上下文setup TOML多行根级字符串修复安全tmux HUD窗口定位ultrawork 协议对齐BusyBox 清理兼容过期 Stop/autopilot 状态处理规范化 runtime supervisor 事件Docker 宿主 tmux 提问渲染与原生 Windows psmux worker 面板引导硬化。关键兼容性结论原文档已明确无需用户迁移0.14.3不改变任何持久化数据格式或 CLI 表面omx question保持 fail-closed 语义当不存在可见/可返回的 tmux 面板时提问命令会主动失败而不是把提示渲染到操作者看不见的地方项目级.codex用户收益update/setup refresh 后explore 等启动路径能获得更一致的启动行为。二、核心修复一omx question返回面板可靠性2.1 问题背景在 OmX 中omx question会在 tmux 内新开一个面板渲染交互式提问 UI操作者回答后答案要注入回发起提问的 leader 面板。此前在以下场景会丢失返回目标工具发起的提示、提示重新播种prompt reseeding、detached/visible 渲染路径、以及渲染器元数据竞态。2.2 渲染器策略的源码级解析返回目标的解析集中在 src/question/renderer.ts核心函数是resolveQuestionRendererStrategy与resolveReturnTarget。渲染器策略QuestionRendererStrategy共七种按优先级判定源码见 renderer.ts策略判定条件说明test-noop环境变量OMX_QUESTION_TEST_RENDERERnoop测试专用不真正创建面板windows-psmux-shell-panewin32且TMUX含psmux或TMUX_PANE为合法 pane id原生 Windows psmux 桥接windows-consolewin32且存在显式OMX_QUESTION_RETURN_PANE/OMX_LEADER_PANE_ID通过独立控制台窗口渲染inside-tmuxTMUX非空或存在显式返回目标或能从持久化状态读取到返回目标在 tmux 内 split/new-windowinline-ttywin32且 stdin/stdout 均为 TTY就地 TTY 交互unsupported其余情况抛出 fail-closed 错误返回目标resolveReturnTarget的解析优先级renderer.ts显式环境变量OMX_QUESTION_RETURN_PANE或OMX_LEADER_PANE_ID必须是%N形式的 pane id当前进程的TMUX_PANE持久化返回目标从TRACKED_WORKFLOW_MODES各模式的 state 文件getStatePath中读取active true且含合法tmux_pane_id的记录readPersistedQuestionReturnTarget兜底实时探测当前 tmux panegetCurrentTmuxPaneId。这套优先级设计解决了工具发起的提问场景提问进程通常不在交互式 leader 面板内直接运行而是由 hook/工具触发此时TMUX_PANE不可靠必须回退到持久化 state 或显式 bridge 环境变量。2.3 答案注入与渲染器生命周期答案注入使用injectQuestionAnswerToPane/injectQuestionAnswersToPane统一走buildSendPaneArgvs与 reply-listener 面板发送路径共享的 tmux send-keys 语义并包含字面量文本投递、换行消毒、独立C-m提交常量QUESTION_TEXT_SETTLE_MS 120、QUESTION_SUBMIT_REPEAT_DELAY_MS 100注入文本带前缀[omx question answered]formatQuestionAnswerForInjection支持other自定义答案与multi多选两种 answer kind渲染器存活检测isLaunchedQuestionPaneAlive通过list-panes -t pane -F #{pane_dead}\t#{pane_id}判断 pane 是否立即死亡isQuestionRendererAlive统一分派到 pane/session/windows-console 三类检测渲染器关闭closeQuestionRenderer对 tmux-pane 执行kill-pane -t pane对 tmux-session 执行kill-session同会话互斥新提问启动前会调用supersedeLiveQuestionsForSession把同会话内其他status prompting且渲染器仍存活的提问标记为superseded并关闭其渲染器防止同一会话堆积多个失效提问面板。2.4 自适应用户界面高度omx question会根据渲染内容估算占用行数estimateQuestionRenderFootprint考虑宽字符displayWidth与换行折叠再计算自适应 pane 高度computeAdaptiveQuestionPaneHeight若内容超过当前窗口可分高度shouldOpenQuestionInNewWindow则改用new-window打开完整窗口否则split-window -v -l height。宽度探测失败时保守回退 80 列确保渲染器在任何 tmux 环境下都能启动。三、核心修复二deep-interview 对账与汇总门控3.1 已回答问题不再重复追问原文档 Highlights 明确Deep-interview now reconciles answered question records before re-prompting。实现位于 src/question/deep-interview.ts每次发起 deep-interview 提问都会创建一条义务记录obligationDeepInterviewQuestionEnforcementState字段含obligation_id、statuspending | satisfied | cleared、lifecycle_outcome: askuserQuestion、requested_at、question_id、satisfied_at、clear_reasonhandoff | abort | error重新追问前调用reconcileDeepInterviewQuestionEnforcementFromAnsweredRecords若存在source deep-interview、status answered且created_at requested_at的已答记录isAnsweredDeepInterviewRecordForObligation则自动将 obligation 标记为satisfied不再重复提问义务状态持久化在deep-interview-state.jsongetStateFilePath定位随 session 隔离与 autopilot 联动提问前先claimAutopilotDeepInterviewQuestionWaiting若已有未决 wait claim 则抛出active_execution_mode_blocked成功后通过环境变量AUTOPILOT_DEEP_INTERVIEW_QUESTION_OWNER_ENV传递 obligation id完成或出错后分别以satisfied/cleared解析 wait 状态。3.2 超大澄清流汇总门控CHANGELOG 记录Deep-interview summary gates — oversized interview flows now require compact summaries before continuing当澄清问答流过大时流程必须先产出紧凑摘要才能继续避免对话上下文失控。该行为同时反映在 deep-interview 的 enforcement 状态迁移中——pending时强制lifecycle_outcome: askuserQuestion、run_outcome: blocked_on_user、active: false。四、核心修复三项目级CODEX_HOME与 explore 启动上下文原文档指出Project-scoped setup is respected during explore launches by resolving project-localCODEX_HOMEfrom persisted setup scope。从 CHANGELOG.md 与测试证据看更新/刷新update/setup refresh后launch/session 辅助逻辑会读取持久化的项目 setup scopesetup-scope.json测试覆盖见 src/cli/tests/update.test.ts 与 setup-scope 相关套件当 scope 为项目级时explore 启动将CODEX_HOME解析到项目.codex目录使会话、历史、配置都落在项目本地src/cli/tests/index.test.ts 中有一组专门测试验证只有持久化的项目CODEX_HOME才会被标记为 project-local 清理目标显式设置的环境变量CODEX_HOME不会被误标记同时验证了 legacyproject-local持久化 scope 会迁移为project并正确解析CODEX_HOME且在 setup root 之外启动不会把流量重定向进项目CODEX_HOME。需要说明的边界从源码看src/cli/explore.tsomx explore的直接命令面已 hard-deprecatedEXPLORE_DEPRECATION_MESSAGE当前仅保留--help其余用法一律失败并提示迁移到普通 Codex 仓库检视工具或omx sparkshell -- command。因此本次explore 启动尊重项目级CODEX_HOME实际作用在残留的 explore harness 启动/会话辅助路径含omx-explore-harness原生二进制解析resolvePackagedExploreHarnessCommand而非已删除的交互命令本身。五、核心修复四setup 刷新对多行 TOML 的修复安全原文档Setup refresh handles multiline root TOML assignments without orphaning fragments。实现位于 src/config/generator.ts新增TomlSourceStringMode四态词法跟踪basic...、literal...、multiline-basic...、multiline-literal...analyzeTomlSource逐字符扫描每个源行跟踪当前是否处于多行字符串内并记录lineStartsOutsideMultiline、lineHasTomlComment与isUnambiguous标记其注释明确表达了设计意图TOML 的 parser 提供语义而该词法分析防止源修复把多行值中类似 table 的文本当作语法处理——即修复器不再把内的[section]样式文本误判为 TOML 表结构从而避免 setup 刷新时拆散orphan根级字符串片段或破坏developer_instructions风格的值配套的repairConfigIfNeededgenerator.ts采用外科手术式修复addDefaultLauncherMcpStartupTimeouts、stripLegacyOmxTeamRunTable、dedupeTuiTables仅在检测到目标不兼容时才写回文件未检测到变更则返回false不落盘。测试证据changed-path 套件中包含 src/config/tests/generator-idempotent.test.js幂等性验证确保修复重复执行不会产生新差异。六、核心修复五HUD 对账窗口定位原文档HUD reconciliation targets the emitting tmux window, avoiding cross-window resize drift。从 src/hud/reconcile.ts 的实现看HUD 对账现在以触发事件的窗口为准leader 面板只有在该窗口内存在且存活非 dead才计为live跨窗口的 leader 面板不会被误伤源码注释明确sessions whose leader may legitimately live in a different tmux window we cannot see from this windows pane list are never touched修复了每次 prompt submit 后窗口被堆叠的 HUD 条填满的退化布局变更 hook 可能对同一窗口内多个 OMX pane 一起触发#L467附近注释对账会去重窗口过短时跳过拆分isTmuxWindowTooCrampedForHudSplit→status: skipped_window_too_cramped并在拆分后重新扫描窗口而非留下重复 HUD尺寸探测使用targetPaneId显式目标避免测量到另一个窗口的面板尺寸导致漂移。七、核心修复六BusyBox 兼容的进程清理原文档Cleanup supports BusyBoxpsby falling back from thecommandfield toargsonly for that compatibility failure。实现位于 src/cli/cleanup.tslistOmxProcesses默认执行ps axww -o pid,ppid,commandprocps 风格若失败isBusyBoxPsCommandFieldError用正则/bad -o argument []command[]|unsupported arguments:.*\bargs\b/i判断是否属于BusyBoxpsAlpine 默认拒绝command字段名的兼容性问题仅当确实是该失败时才用args字段重试ps axww -o pid,ppid,args其他ps失败照常抛出不掩盖真实错误。这种仅针对该兼容性失败回退的设计避免了把其他进程枚举错误误判为环境兼容问题。八、其余硬化项8.1 过期 Stop/autopilot 状态处理CHANGELOGNative Stop no longer loops on stale autopilot planning state——Stop 处理前会先清理/对账过期的 planning 状态避免 stop 信号在陈旧状态上重复循环src/hooks/*与src/scripts/codex-native-pre-post.ts相关测试覆盖见 src/scripts/tests/codex-native-hook.test.ts。8.2 规范化 runtime supervisor 事件CHANGELOG Added 条目Canonical supervisor runtime events——runtime command-event 契约新增 supervisor 控制与下游分发/就绪决策使用的规范化事件类型。相关契约文档见 docs/contracts/runtime-command-event-snapshot-schema.md测试覆盖src/scripts/notify-hook/__tests__/operational-events.test.js与src/team/__tests__/events.test.js、runtime.test.js。8.3 Docker 宿主 tmux 提问桥接CHANGELOG AddedDocker-host tmux question bridge——在 Docker 宿主环境下omx question可通过桥接 docker-host tmux 检测让操作者看到提示面板与 detached/visible 路径同属提示必须对操作者可见原则的一部分。8.4 原生 Windows psmux worker 面板引导0.14.3为原生 Windows 下的 psmux worker 启动引入引导硬化提问渲染新增windows-psmux-shell-pane策略见 2.2 节通过new-window -P -F #{pane_id}创建 shell 面板再用buildSendPaneArgvs逐段发送set KEYVALUE ... node 命令%与双重转义并追加C-m提交与 0.14.2 的 cmux 兼容设计一致cmux 的 tmux-compat shim 不消费split-window -e因此环境变量通过 shell 中立的env KEYVALUE ...前缀传递兼容 fish 等非 POSIX shell并整体单引号打包为单一 shell 命令参数。九、验证证据与发布就绪发布就绪文档 docs/qa/release-readiness-0.14.3.md 记录了全部门禁Gate门禁命令结果全量 Node/构建/catalog 套件npm testPASS — 3910 tests, 0 failedcatalog check ok未使用类型门禁npm run check:no-unusedPASSRust workspace 测试cargo test --workspacePASSLint 门禁npm run lintPASSTypeScript 构建npm run buildPASS变更路径定向套件node --test dist/cli/__tests__/{cleanup,explore,index,question}.test.js dist/config/__tests__/generator-idempotent.test.js dist/hooks/__tests__/{clawhip-event-contract,deep-interview-contract,keyword-detector,skill-guidance-contract}.test.js dist/hooks/extensibility/__tests__/events.test.js dist/hud/__tests__/reconcile.test.js dist/question/__tests__/{deep-interview,renderer,state,ui}.test.js dist/scripts/__tests__/codex-native-hook.test.js dist/scripts/notify-hook/__tests__/operational-events.test.js dist/team/__tests__/{events,runtime,tmux-session}.test.jsPASS已知限制外部 push/npm/GitHub 发布依赖仓库证据之外的本地凭据与网络可用性。结论为0.14.3可安全切 release commit/tag合并release/0.14.3至dev与main并打v0.14.3标签。十、实操验证与排查建议10.1 本地复现验证在已更新的仓库执行以下命令验证各修复路径npm test # 全量 Node 套件0.14.3 基线为 3910 passed npm run check:no-unused # 未使用类型门禁 cargo test --workspace # Rust workspace 测试 npm run lint npm run build # lint 与 TypeScript 构建若需定向复验本次变更路径可运行变更路径套件见上文验证证据表格中的node --test ...命令清单。10.2 常见问题速查omx question报 cannot open a visible renderer属于预期的 fail-closed 行为。确保在已 attach 的 tmux 会话内运行或显式设置OMX_QUESTION_RETURN_PANEpane-id/OMX_LEADER_PANE_IDpane-id建立返回桥清理时ps报bad -o argument commandBusyBox 兼容路径会自动用args重试无需手动干预其他ps错误仍会正常上抛项目级.codex启动行为不一致确认 setup scope 持久化为项目级.omx/setup-scope.json更新后再次 setup refresh 让CODEX_HOME解析到项目.codexHUD 跨窗口漂移确认对账 hook 按发射窗口定位leader 位于其他窗口时不会被本窗口对账误动。十一、小结0.14.3是典型的小版本、大硬化补丁它没有新增 CLI 表面或配置格式却把 tmux 多窗口环境下的提问返回链路显式环境变量 →TMUX_PANE→ 持久化 state → 实时探测四级回退、deep-interview 义务状态机pending/satisfied/cleared answered-record 对账、setup TOML 词法级修复、HUD 窗口本地化对账、BusyBoxargs字段回退、规范化 supervisor 事件与 Windows psmux 引导全部收敛为可测试的确定性行为。理解这些修复背后的源码决策如仅对该兼容性失败回退外科手术式修复fail-closed 可见性也能帮助你预判后续版本如 0.14.x 之后的同类硬化的方向与取舍。【免费下载链接】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），仅供参考