OmX 0.12.1 发布解析团队状态 JSON 可解析性、Worker PID 元数据与 launch-safe 孤儿进程清理【免费下载链接】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.12.1 是 oh-my-codexOmX针对v0.12.0之后累积问题的一条补丁线patch train聚焦于团队运行时team runtime的机器可读输出、交互式 worker 的 PID 元数据、MCP 孤儿进程清理的安全性以及 notify-fallback watcher 的日志治理。读完全文你将理解这 6 项修复各自的故障场景与源码实现位置并能用omx cleanup --dry-run等命令在本地复现验证。0.12.1 修复总览0.12.1的官方定义见 发布说明它由 6 项修复/变更构成目标是让团队状态输出可被脚本稳定消费、worker 生命周期元数据准确、清理操作不误杀活进程修复项解决的问题源码位置leader mailbox 剪枝不再重放已投递消息的 bridge 调用omx team status --json输出保持可解析src/team/runtime.ts、src/team/state/mailbox.ts交互式 worker 元数据记录由 resolved pane id 解析出的 PIDconfig/identity 状态中 PID 缺失或不一致src/team/runtime.ts孤儿 OMX MCP 清理保留存活的 launcher/session 进程树自动清理误杀仍在服务 Codex 会话的 MCP 进程src/cli/cleanup.tsfallback watcher once 模式日志滚动而非静默增长单轮调试日志无限撑大.omx/logssrc/scripts/notify-fallback-watcher.tstmux 外 leader 启动默认走 direct 模式非 tmux 环境下默认 detached tmux 行为不符合预期见 发布说明Node、Cargo、changelog、release body 与 release-readiness 文档元数据对齐到0.12.1版本号跨工具链漂移release-readiness 文档下面逐项展开。leader mailbox 剪枝保证omx team status --json可解析团队运行时在每个 monitor 轮次结束后会对 leader 邮箱做一次性剪枝清理来自system的临时状态消息TTL 60 秒。该逻辑位于 runtime.ts// Prune ephemeral status messages from leader mailbox (TTL: 60s) try { const leaderMailbox await listMailboxMessages(sanitized, leader-fixed, cwd); const now Date.now(); for (const msg of leaderMailbox) { if (msg.from_worker system msg.created_at) { const age now - new Date(msg.created_at).getTime(); if (age 60_000) { await markMessageDelivered(sanitized, leader-fixed, msg.message_id, cwd); } } } } catch (err) { process.stderr.write([team/runtime] operation failed: ${err}\n); }修复点在于投递标记的幂等性。0.12.1 之前的行为是剪枝过程中可能对已经投递过的消息重放 bridge 调用重复MarkMailboxDelivered等导致额外输出混入omx team status --json的结果流使 JSON 解析失败。修复后markMessageDelivered在 mailbox.ts 中有明确的前置短路const existingMessage existingMailbox.messages.find((message) message.message_id messageId); if (!existingMessage) return false; if (existingMessage.delivered_at) return true; // 已投递则直接返回不触发 bridge/写入副作用也就是说只有当delivered_at尚未落盘时才会走 bridgeMarkMailboxDelivered命令或 legacy JSON 写路径并同步追加 delivery logdelivered事件含transport: bridge | legacy-json。配合 runtime.ts 中基于notified_at与previousNotifications快照的双重去重注释明确引用了 issue #116 的“防止每轮 monitor poll 重复通知”已投递/已通知消息不会再产生重放副作用——这是--json输出保持纯 JSON、可被jq之类工具直接消费的前提。交互式 worker 元数据从 resolved pane id 解析 PID 并持久化交互式团队interactive team在启动时由 tmux session 创建流程返回 leader pane、HUD pane 以及每个 worker pane 的 id 与 pid。0.12.1 修复让这些值真正落入 config/identity 状态。关键写入路径在 runtime.tsconfig.leader_pane_id createdSession.leaderPaneId; config.hud_pane_id createdSession.hudPaneId; config.leader_pane_pid /* 仅当 leaderPanePid 是安全正整数时写入 */ ...; config.hud_pane_pid /* 同上针对 hudPanePid */ ...; // 优先使用按索引对齐的 workerPaneIdsByIndex if (paneIdsByIndex) { for (let i 0; i paneIdsByIndex.length; i) { ... config.workers[i].pane_id paneId; if (typeof panePid number Number.isSafeInteger(panePid) panePid 0) config.workers[i].pid panePid; } }实现上有两处值得注意的工程约束PID 只接受Number.isSafeInteger且大于 0 的值非法值直接留空而不是写入脏数据worker pane id 通过pane_ids_by_index与 worker 配置下标严格对齐回退到workerPaneIds路径避免“第 N 个 pane 对应第 N 个 worker”的错位。这些 PID 不是摆设——runtime.ts 的启动清理流程会读取 exact pane proof当proof.pid ! cleanupPane.pid时抛出startup_cleanup_pane_identity_changed即以 pane 内实际进程 PID 作为身份校验依据防止 kill 到“被复用 pane id 上的新进程”。PID 元数据持久化正是这条校验链的上游数据源。launch-safe 孤儿清理保留存活 launcher/session 进程树omx cleanup会杀掉孤儿 OMX MCP server 进程并清理陈旧/tmp目录帮助文本见 cleanup.ts。0.12.1 引入“launch-safe”选择策略核心是 findLaunchSafeCleanupCandidatesreturn findCleanupCandidates(processes, currentPid).filter((candidate) { if (candidate.ppid 1) return true; // ppid1 的真正孤儿仍然清理 // Launch-safe cleanup runs automatically before starting Codex/OMX work. // Preserve every MCP process still attached to a live Codex or OMX launch // ancestor, including older same-parent duplicate siblings. return ( !hasAncestorMatching(processByPid, candidate.pid, isCodexSessionProcess) !hasAncestorMatching(processByPid, candidate.pid, isOmxLaunchProcess) ); });其判定规则可以归纳为三条识别 MCP 进程通过OMX_MCP_ENTRYPOINT_PATTERN匹配dist/mcp/{state|memory|code-intel|trace|wiki}-server入口或通过mcp-serve参数解析出第一方 MCP 目标见 cleanup.ts向上遍历祖先链hasAncestorMatchingcleanup.ts带环检测地沿 ppid 链查找是否存在 Codex 会话进程codex/openai/codex或 OMX 启动进程omx/dist/cli/omx.js祖先存活进程树整体豁免只要 MCP 进程仍挂在活着的 Codex 会话或 OMX launcher 下即使它是“同父重复兄弟”duplicate-sibling也不在自动清理中杀掉破坏性的重复兄弟回收仍保留给手动omx cleanup路径。配套的--dry-run模式会逐条打印PID x (PPID y, reason) commandreason 取值ppid1/outside-current-session/duplicate-sibling可在实际执行前人工复核候选清单。SIGTERM 后 5 秒宽限SIGTERM_GRACE_MS 5_000超时才升级 SIGKILL见 cleanup.ts。相关测试位于 src/cli/tests/cleanup.test.ts。notify-fallback watcheronce 模式日志滚动notify-fallback watcher 支持常驻persistent与--once单轮模式notify-fallback-watcher.ts。0.12.1 之前once 模式的调试轮跑完后~/.omx/logs/notify-fallback-date.jsonl会静默增长而不滚动。修复后的写入路径在每条事件落盘前先做尺寸检查notify-fallback-watcher.tsasync function rotateLogIfNeeded(nextEntryBytes: number): Promisevoid { if (maxLogBytes 0) return; const currentStat await stat(logPath).catch(() null); if (!currentStat || currentStat.size nextEntryBytes maxLogBytes) return; await unlink(logRotatePath).catch(() {}); await rename(logPath, logRotatePath).catch(() {}); // 滚动到 .1 }可调参数notify-fallback-watcher.ts--log-max-bytes/ 环境变量OMX_NOTIFY_FALLBACK_LOG_MAX_BYTES滚动阈值默认 10 MB设 0 表示禁用滚动--poll-ms轮询间隔默认 250 ms下限 50 ms--idle-max-poll-ms/OMX_NOTIFY_FALLBACK_IDLE_MAX_POLL_MS空闲时自适应退避上限默认 1000 ms见 notify-fallback-watcher.ts 的指数退避状态机--max-lifetime-ms/OMX_NOTIFY_FALLBACK_MAX_LIFETIME_MS常驻模式生命周期上限默认 6 小时once 模式下直接置 0不限制--authority-only只执行权威authority职责用于分离控制面。日志目录为runtimeRoot/.omx/logs/其中runtimeRoot优先取OMX_ROOT其次OMX_STATE_ROOT最后回退 cwd。leader 启动默认 direct 模式与元数据对齐除上述四项外0.12.1 还包含两个行为/发布层面的变更tmux 外默认 direct 启动leader 启动在 tmux 之外时默认使用 direct 模式除非显式请求 detached tmux。这避免了在普通终端里误入 tmux 派生路径的默认行为“direct-launch follow-through”即指 direct 模式下启动流程完整走通发布物料对齐package.jsonNode、Cargo.toml/Cargo.lockRust 工具链如 crates/omx-sparkshell/Cargo.toml 等 crate、CHANGELOG、release body 与 release-readiness 文档 全部同步到0.12.1避免版本漂移。验证证据与残余风险按 发布说明 记载0.12.1 的本地验证矩阵为npm run build npx biome lint src/cli/index.ts src/cli/cleanup.ts src/cli/__tests__/index.test.ts \ src/cli/__tests__/cleanup.test.ts src/scripts/notify-fallback-watcher.ts \ src/hooks/__tests__/notify-fallback-watcher.test.ts src/team/runtime.ts \ src/team/state/mailbox.ts src/team/__tests__/runtime.test.ts src/team/__tests__/state.test.ts package.json node --test dist/cli/__tests__/cleanup.test.js dist/cli/__tests__/index.test.js dist/cli/__tests__/version-sync-contract.test.js node --test dist/hooks/__tests__/notify-fallback-watcher.test.js node --test dist/team/__tests__/state.test.js dist/team/__tests__/runtime.test.js npm run smoke:packed-install其中version-sync-contract.test.js正是用来约束上面“元数据对齐”那条的自动化闸门测试文件本身在 src/cli/tests/ 下构建产物输出到dist/。发布说明同时明确了残余风险边界该验证是本地验证路径不是完整 CI 矩阵重跑发布后监控应持续观察三个面team status JSON 输出的可解析性、交互式 worker 生命周期遥测pane id/PID 一致性、notify-fallback 的行为日志滚动与 once 模式。参考文件发布说明 docs/release-notes-0.12.1.mdrelease-readiness-0.12.1.mdsrc/team/runtime.tsmonitor 剪枝、worker pane/PID 持久化、投递去重src/team/state/mailbox.tsmailbox 发送/投递/notified 状态机src/cli/cleanup.ts孤儿清理、launch-safe 候选选择、--dry-runsrc/scripts/notify-fallback-watcher.tsfallback watcher 参数、日志滚动【免费下载链接】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），仅供参考