oh-my-codex 0.18.8 运行时可靠性加固解析HUD 会话所有权、Autopilot 重放防护与插件 Hook 一致性【免费下载链接】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.18.8是 oh-my-codex 在dev分支上紧随0.18.7发布的补丁版本聚焦post-release 运行时可靠性列车HUD 窗格所有权在原生会话漂移下的权威性、Autopilot 重放与上下文快照加固、插件 Hook/镜像缓存正确性、Team 启动与禁用安全以及发布/CI 证据链改进。本文以 docs/release-notes-0.18.8.md 为主体骨架结合仓库源码src/hud/、src/autopilot/、src/hooks/、src/team/与 docs/qa/release-readiness-0.18.8.md 的验证记录逐项拆解这 29 个合并 PR 背后的实现细节帮助你理解这些小补丁为何能显著提升长时间运行场景的稳定性。版本定位与兼容性前提0.18.8是一个纯粹的补丁版本patch release发布于0.18.7之后发布范围是v0.18.7..HEADtag 前为v0.18.7..HEADtag 后为v0.18.7..v0.18.8。它的目标非常明确不引入新功能只收紧既有行为的正确性边界。从兼容性声明看既有 HUD、Autopilot、Team、插件和状态文件保持兼容本版本只收紧所有权ownership、缓存cache与重放replay行为无有意的 CLI/包布局破坏随版本一并合入了 README 维护者/贡献者表格、Discord 邀请链接更新以及状态操作帮助state operation help发布范围内的 PR 清点有一个细节PR#2685是 PR#2682的维护者 CI 包装提交#2682本身不计入最终 compare-range 清单因为最终合并提交是#2685。发布范围没有单独关闭的 GitHub issue全部变更均由合并 PR 清单代表共 29 个 PR编号#2686至#2596。HUD以会话为权威的所有权加固HUDHeads-Up Display是 oh-my-codex 在 tmux 中渲染的实时状态面板本次发布中它获得了最大份额的修复。核心思路一句话HUD 窗格的所有权应当由 leader/source 窗格和原生会话 ID 决定而不是由各种回退fallback机制自行猜测。会话 ID 漂移下的去重与所有权保持在长时间运行的 tmux 环境中原生会话 IDnative session ID可能因客户端重连、会话重启而漂移。此前 HUD 去重逻辑跨会话 ID 去重时会失效导致同一会话出现重复窗格更糟的是漂移后 HUD 的所有权可能被错误地转移给其他会话。PR#2684Fix HUD dedupe across native session IDs修复跨原生会话 ID 的 HUD 去重PR#2652Fix session-authoritative HUD state修复以会话为权威的 HUD 状态PR#2686Show HUD late-gate status在 HUD 中展示 late-gate 状态不改变工作流状态。对应源码中src/hud/tmux.ts 定义了 HUD 所有权的环境变量契约export const OMX_TMUX_HUD_LEADER_PANE_ENV OMX_TMUX_HUD_LEADER_PANE; const OMX_TMUX_HUD_OWNER_ENV OMX_TMUX_HUD_OWNER;HudPaneOwner结构同时承载sessionId、sessionIds支持多个会话 ID正是应对漂移后旧 ID 仍残留的情况与leaderPaneId由HudRuntimeEnvInput/HudRuntimeEnvOutput在启动 HUD 子进程时注入环境变量。从源码结构可以推断所有 HUD 窗格都通过环境变量认领自己的 leader pane 和会话 ID去重与归属判定都以这套环境变量为准而不是运行时临时探测。prompt revive 后的重复窗格竞争用户通过 prompt 复活reviveHUD 时遗留的 focused HUD 窗格可能仍然存活新窗格又已创建形成重复窗格竞态PR#2648Fix HUD duplicate pane race after prompt revive修复 prompt revive 后的重复窗格竞态PR#2664Deduplicate legacy focused HUD panes on prompt revive在 prompt revive 时去重遗留的 focused HUD 窗格。这两项修复配合src/hud/reconcile.ts的调和reconcile流程每次渲染周期对照应当存在的窗格集合与实际存在的窗格集合把遗留窗格识别出来并清理避免复活后出现双 HUD。fallback authority 的 respawn 风暴防护HUD 权威authority机制存在一个危险场景当主权威进程异常退出时fallback 会尝试重新拉起respawn但如果多个 fallback 同时判定无人负责就会互相竞争、反复拉起形成 respawn 风暴。PR#2660Prevent HUD fallback authority respawn storms正是为此而来。src/hud/authority.ts 中的权威状态结构给出了防风暴的具体机制interface HudAuthorityState { owner: hud; pid: number; cwd: string; heartbeat_at: string; last_spawn_at?: string; last_skip_at?: string; next_allowed_at?: string; cooldown_ms: number; jitter_ms: number; skip_count: number; last_status: spawned | skipped | failed | locked; last_reason: string; last_error?: string; }关键字段的语义cooldown_msnext_allowed_at一次 spawn 之后必须冷却冷却期内新 tick 只能跳过skipped从机制上杜绝连续拉起jitter_ms在冷却基础上叠加随机抖动避免多进程 tick 在相同时间点撞车后同时决策skip_count记录连续跳过次数用于观察权威是否健康last_status/last_reason每次 tick 的结果与原因都会被写入状态文件便于事后审计到底是 spawned、skipped、failed 还是 locked状态写入采用临时文件 rename的原子替换writeAuthorityState读取时通过validateAuthorityState严格校验owner 必须是hud、pid 必须是正整数、时间戳必须是合法 ISO 格式等损坏的状态文件不会污染后续决策。此外还有tryCreateAuthorityLock的目录锁机制通过mkdir的原子性抢锁抢到锁的进程才执行 spawn 决策失败方读到locked状态直接退出这是防 respawn 风暴的第二道闸门。避免 doctor 窗格物化已删除的 cwd当 HUD 的当前工作目录cwd被删除后如果 doctor 窗格仍尝试在该目录下启动进程就会在已删除路径上物化出一个无法工作的窗格。PR#2655Prevent HUD doctor panes from materializing deleted cwd在 authority 层拦截了这种情况src/hud/authority.ts 给出了判定逻辑function isDeletedCwdMarkerPath(path: string): boolean { const currentPath path.trim(); return /(?:^|\s)\(deleted\)\s*$/.test(currentPath) !existsSync(currentPath); }即路径文本以(deleted)结尾且磁盘上确实不存在该路径时判定为已删除 cwd后续不再为它拉起 doctor 窗格。转义 tmux 分隔符的解析tmux 的 pane 分隔符在部分平台/版本下会以八进制转义形式\037输出此前解析逻辑未处理转义形式导致 pane 边界识别错误。PR#2642Fix HUD pane detection with escaped tmux separators修复了这一点src/hud/tmux.ts 中同时定义了两种表示export const TMUX_PANE_FIELD_SEPARATOR \x1f; export const TMUX_PANE_FIELD_SEPARATOR_OCTAL_ESCAPE \\037;同文件中的parseExactTmuxAuthorityLines/parseExactTmuxAuthorityScalar体现了 HUD 对 tmux 输出的传输严格策略权威性解析只接受非空 body 恰好一个 LF 或 CRLF的完整帧body 内不能有多余换行或\r保证任何被当作权威依据的 tmux 输出都是完整可信的而宽松解析tolerant parsing只用于展示元数据且调用方必须先用严格解析校验帧结构。resize 钩子按 leader pane 收窄HUD 需要在 tmux 窗格尺寸变化时触发重绘但此前 resize 钩子可能被会话内其他窗格的尺寸变化误触发。PR#2656Scope HUD resize hooks by leader pane将 resize 钩子按 leader pane 收窄只有 leader pane 的尺寸变化才驱动本 HUD 的 resize 重调和。配合HUD_RESIZE_RECONCILE_DELAY_SECONDS等常量src/hud/constants.ts的延迟合并避免高频 resize 事件导致渲染抖动。会话未附加时的渲染抑制与本次发布相邻但机制相通的一项能力源码注释中记为 close #3577在 src/hud/session-attached.ts 的isHudWatchSessionAttached中通过display-message -p -t pane #{session_attached}查询会话是否有客户端附加。只有查询结果是可信的0时才抑制渲染跳过状态读取、git 子进程、tmux 调和与 stdout 写入任何未知情况非 tmux 终端、tmux 不可用、查询失败都按已附加处理保证 HUD 永不因误判而静默消失。这套未知即保守策略与上述 fallback 防风暴、传输严格解析一脉相承HUD 的可靠性哲学是宁可多渲染不可错误决策。HUD 状态渲染上下文src/hud/state.ts 展示了 HUD 渲染上下文的来源读取.omx/state/下的状态文件包括current-autopilot.json、各 mode 的mode-state.json会话级文件、技能激活状态、子代理跟踪状态等构建HudRenderContext。0.18.8 中 HUD 相关的修复本质上是让这套读状态 → 渲染 → 调和窗格链路在会话漂移、prompt revive、cwd 删除等异常场景下保持一致。Autopilot 与规划重放路径加固Autopilot 是 oh-my-codex 的自主运行模式它会监督deep-interview、ralplan、ultragoal、rework、team、ralph、code-review、ultraqa等子阶段见 src/autopilot/fsm.ts 的AUTOPILOT_CHILD_PHASES。0.18.8 重点加固了它的重放路径。防止已完成的终端回合重新激活 Autopilot最危险的回归场景某个终端回合terminal turn已经完成但事件重放replay时状态机误判为需要继续 Autopilot导致已完成的对话被重新激活、重复执行。PR#2675Prevent Autopilot terminal turn replay reactivation从根上堵住这条路径。src/autopilot/fsm.ts 定义了完整的运行时阶段集合其中waiting-for-user、complete、failed是终态/交互态const AUTOPILOT_RUNTIME_PHASES [ ...AUTOPILOT_CHILD_PHASES, waiting-for-user, complete, failed, ] as const;而deriveAutopilotChildPhasesrc/autopilot/fsm.ts只在mode autopilot active true时才派生子阶段isAutopilotSupervisingsrc/autopilot/fsm.ts进一步要求有实际监督的子阶段。0.18.8 的修复确保一旦回合进入complete/failed终态任何 replay 事件都不会再让deriveAutopilotChildPhase返回非空值从而isAutopilotSupervising恒为 falseAutopilot 不会被重新激活。normalizePhaseText中completed → complete的归一化处理src/autopilot/fsm.ts也保证了不同写法completed/complete在判定时被统一对待。上下文快照的种子化与加固Autopilot 续跑continuation依赖上下文快照context snapshot携带原始任务信息。PR#2670Seed and harden Autopilot context snapshots做了两件事一是为新建的 Autopilot 会话种子化快照确保首轮就有可恢复的上下文二是加固快照的校验与恢复逻辑。src/hooks/keyword-detector.ts 展示了续跑时的快照处理先通过ensureAutopilotContextSnapshot确保存在可用快照再将其路径与元数据kind、original_task_status、可能的recovery信息写入续跑事件若找不到安全快照则进入context_snapshot_recovery降级路径恢复原因记为missing-or-unsafe-legacy-context-snapshot续跑时没有可安全使用的遗留 Autopilot 上下文快照路径。加固还包括超大快照拒绝src/hooks/__tests__/keyword-detector.test.ts中的rejects oversized Autopilot context snapshot candidates during reuse用例验证了超过 1 MiB 的遗留快照不会被复用见该测试中x.repeat((1024 * 1024) 1)的构造防止恶意或异常膨胀的快照污染续跑上下文。任务种子task-seed来源的澄清PR#2671Clarify Autopilot task-seed provenance澄清了任务种子的来源语义。src/hooks/keyword-detector.ts 中const taskSeed activationText.trim() || $autopilot;即任务种子优先取激活文本activation prompt为空时回退为$autopilot占位。续跑事件中会明确记录activation prompt / task seed让这个 Autopilot 会话最初因什么而启动在状态文件中可追溯避免续跑时对任务意图的猜测。原生会话漂移下禁止规划阶段写入PR#2650Prevent planning-phase writes under native session drift当原生会话发生漂移时规划阶段planning即 ralplan 相关流程不得执行写入。这是对 HUD 所有权修复的姊妹措施——会话漂移期间状态文件的所有权归属本身存在歧义此时写入规划产物可能落到错误会话的状态目录造成污染。0.18.8 将漂移期间只读、不写作为规划阶段的硬约束。code-review 子代理的 clean-context 澄清PR#2651Clarify clean-context for code-review subagents与#2643Harden UltraQA temporary harness guidance分别澄清了 code-review 子代理的干净上下文语义、加固了 UltraQA 临时测试台harness的使用指引属于子代理上下文隔离的文档化与约束收紧。插件 Hook 与镜像同步严格化oh-my-codex 通过插件系统扩展 Codex 原生 Hook。0.18.8 对插件侧的修复集中在缓存新鲜度与语义对齐两个方向。修复过期的插件 Hook 缓存刷新PR#2677Fix stale plugin hook cache refresh此前插件 Hook 缓存刷新存在缺陷更新插件后旧 Hook 配置仍被命中。修复后刷新流程会重新读取插件的 Hook 元数据并覆盖旧缓存保证插件更新 → Hook 生效不再需要手动清缓存。镜像同步时校验插件 Hook 元数据PR#2672Verify plugin hook metadata during mirror sync插件的镜像同步mirror sync会把插件目录同步到本地运行区0.18.8 起同步过程会校验插件 Hook 元数据——元数据缺失或不一致时同步失败并给出明确错误而不是静默同步出不可用的 Hook。这与发布流程中的npm run sync:plugin/npm run verify:plugin-bundle门禁见 package.json 与 docs/qa/release-readiness-0.18.8.md相呼应插件束plugin bundle的正确性是发布前必须验证的一等公民。超大 Stop 语义与 JSON 启动器回退PR#2667Mirror oversized Stop semantics in plugin hook插件 Hook 在收到超大输入时Stop 语义必须与主程序一致拒绝而非截断或误放行PR#2661Fix plugin Stop hook launcher JSON fallback修复 Stop Hook 的启动器在 JSON 场景下的回退行为——当首选启动方式失败时应回退到 JSON 启动器而不是直接失败。这两项保证插件 Hook 与原生 Hook 在边界条件超大负载、launcher 不可用下行为对齐避免插件路径放行、原生路径拒绝的语义分叉。更新刷新时保留插件 setup 模式PR#2649Preserve plugin setup mode during update refresh执行插件更新刷新update refresh时若插件正处于 setup 模式首次配置引导阶段刷新流程不得打断该模式。此前刷新可能把 setup 状态冲掉导致用户重新配置0.18.8 起刷新会识别并保留 setup 模式。Team 与原生代理行为明确化Team 模式可禁用PR#2654Make Team mode disableableTeam 模式此前缺少干净的禁用路径0.18.8 起可以明确禁用。从源码看Team 显示模式由环境变量驱动src/team/state.ts 读取const raw readEnvValue(env, [OMX_TEAM_DISPLAY_MODE, OMX_TEAM_MODE]);即OMX_TEAM_DISPLAY_MODE优先、OMX_TEAM_MODE为别名兼容。禁用能力让不需要多代理协作的场景或需要在出问题时整体关闭 Team 的场景有明确的逃生通道而不必手动清理状态文件。tmux worktree 下的 Team worker 启动兼容PR#2640Fix team worker startup compatibility for tmux worktrees在 git worktree 场景下Team worker 的启动路径此前可能因 cwd/root 解析差异失败。修复后 worker 启动对 worktree 布局兼容src/team/state-root.tssrc/team/state-root.ts中的状态根解析逻辑展示了相关背景worker 的 state root 会综合 identity、manifest、config 三方元数据交叉校验任何一方不一致都会以*_state_root_mismatch拒绝保证 worktree 下 worker 不会把状态写到错误的根目录。原生执行器通道保持 leaf-onlyPR#2666Keep native executor lanes leaf-only原生执行器native executor通道只允许作为叶子leaf节点使用——即执行器只能执行具体任务不能再往下派生子执行器。这约束了原生代理的执行拓扑避免执行器递归展开导致进程树失控。默认原生子代理路由指引修正PR#2636Fix default native subagent routing guidance修正了默认原生子代理native subagent路由指引的表述/行为使新用户在不显式配置路由时子代理默认走向正确的通道而非沿用过时的默认值。状态操作帮助PR#2646Support state operation help为omx state系列操作补充帮助信息降低状态目录/状态文件的手工操作门槛。发布与 CI 证据改进0.18.8 同时优化了发布流程本身的证据链PR#2657ci: use gajae self-hosted linux runnerCI 迁移到 gajae 自托管 Linux runner减少对共享 runner 的依赖与排队波动PR#2665Optimize CI lanes for GJC evidence artifacts针对 GJCGitHub 对比范围证据产物的 CI lane 优化避免无关的广泛 CI 扰动avoidable broad CI churn。完整的发布前本地门禁清单在 docs/qa/release-readiness-0.18.8.md 中有逐条记录核心命令包括门禁命令目的版本同步探测node dist/scripts/check-version-sync.js --tag v0.18.8校验各文件版本号与 tag 一致构建/静态检查npm run build、npm run lint、npm run check:no-unused编译与质量基线原生代理验证npm run verify:native-agents原生代理清单正确插件同步验证npm run sync:plugin、npm run verify:plugin-bundle插件束与 Hook 元数据正确目录文档校验node dist/scripts/generate-catalog-docs.js --check目录文档无漂移完整测试套件npm test/npm run test:ci:compiled5745 个测试全部通过见验证记录团队 e2eWORKER_COUNT5 bash src/scripts/demo-team-e2e.shTeam demo 端到端打包预检npm pack --dry-run包内容预检验证记录中的一个细节值得注意npm test必须在USE_OMX_EXPLORE_CMD未设置时运行否则被废弃的兼容路由会污染测试结果记录中专门保留了被污染的尝试日志作为反证。这正是本版本证据链严谨性的缩影——不只记录通过还记录为什么某个通过是可信的。tag 推送之后GitHub release workflow 仍是跨平台原生资源与 npm 发布的权威门禁authoritative gate。小结一次以可靠性为唯一目标的补丁列车0.18.8 的 29 个 PR 没有新增用户可见的大功能但每一处修复都在消除一类长时间运行才会暴露的稳定性问题HUD会话 ID 漂移、prompt revive、fallback 竞态、cwd 删除、转义分隔符——让 HUD 窗格的所有权判定完全以 leader pane 与原生会话 ID 为权威src/hud/tmux.ts配合原子化、严格校验的权威状态机src/hud/authority.ts与未知即保守的附加判定src/hud/session-attached.tsAutopilot已完成的回合绝不被重放重新激活src/autopilot/fsm.ts续跑上下文快照被种子化、加固并拒绝超大快照src/hooks/keyword-detector.ts任务种子来源可追溯插件缓存刷新、镜像元数据校验、超大 Stop 语义与 JSON 回退、setup 模式保留让插件 Hook 与原生 Hook 的行为边界完全对齐Team可禁用、worktree 兼容、执行器 leaf-only、子代理路由修正发布自托管 runner、CI lane 优化与全量门禁证据链让每一次发布都有可复核的通过记录docs/qa/release-readiness-0.18.8.md。如果你正在长时间运行 oh-my-codex 的 HUD/Autopilot/Team 工作流0.18.8 是值得升级的补丁版本——它的价值不在新功能而在在你没注意到的地方把边界条件全部堵死。【免费下载链接】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），仅供参考