oh-my-codex 0.18.13 发布就绪全解析项目级会话发现、Setup/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-codex导读本文基于 docs/qa/release-readiness-0.18.13.md 展开完整剖析 oh-my-codexOmX0.18.13补丁版本从候选冻结、范围评审、本地验证到发布收尾的整套工程实践。你将从本文掌握omx resume/omx session search的项目级 Codex home 发现机制与--project、--codex-home逃生舱用法Setup 对自定义 native-agent TOML 的保留策略Ralplan/Autopilot 共识新鲜度门控原理以及一个补丁版本为什么选0.18.13而非0.19.0的判定标准——并学会用check-version-sync.js、verify-native-agents、npm pack --dry-run等命令复现该版本的完整验证流水线。版本背景与发布范围0.18.12 之后的加固列车从 0.18.12 到 0.18.13 的拓扑背景0.18.13是紧随0.18.12之后的兼容性保持补丁compatibility-preserving hardening train。理解它之前需要先明白一个拓扑细节v0.18.12标签指向的是 main 晋升提交29d03f49而dev分支与origin/main共享 merge-base06baf8f4。因此发布就绪文档特别提醒必须使用origin/main...HEAD --cherry-pick视角配合发布范围评审避免把与0.18.12cherry 等价的预备提交重复计入0.18.13的新功能。这是本文件开头 “Topology caveat” 的核心含义也是后续所有双计数风险管控的前提。候选分支在 intake 时冻结于提交24294fc2Improve project resume/search discovery (#2846)并叠加本地发布元数据更新最终v0.18.13从提交daf7c7c21f602584294f9a04ef5155b5ccfb0e96正式发布发布后就绪文件以“文档-only 更新”方式追加证据而不是移动不可变的发布标签。发布范围清单0.18.13打包的内容全部围绕“不破坏既有 CLI/包契约”前提展开项目级运行时 Codex home 纳入omx resume与omx session search并提供--project/--codex-home作为更窄或更显式的发现控制Setup 保留用户自定义的 native-agent TOML并更完整地覆盖 overwrite/scope 行为Hook JSON 状态兼容性与 native hook 执行路径加固cleanup 时保留项目级 Codex transcriptsRalplan 与 Autopilot 共识新鲜度、tracker 支撑的 native reviews、目标感知的写入检测收紧Sidecar Team 状态根与 Team 运行时行为对齐CI 工作流迁移到 GitHub 托管 runner在合适处dev-merge 的 issue-close 跟进评论改为 best-effortGeobench 可见性文档/档案、富档案与 romanization schema 修复开发依赖刷新biomejs/biome升至2.5.0、types/node升至25.9.3。对应的合并 PR 清单可在 docs/release-notes-0.18.13.md 中查阅核心条目包括 #2846、#2845、#2843、#2836、#2829、#2824、#2820、#2821、#2817、#2816 等外加 4 个直接提交51868d56、a49c32dd、5e918a52、e75261d0用于 geobench 可见性规格与 schema 修复。Issue 盘点为什么没有阻塞发布范围评审时打开的 PR 有 #2840、#2839、#2838 与 draft #2828打开的问题issue为零这些 PR 均为 fix/docs/warning/safety 范畴未改变0.18.13的补丁决策。版本号决策为什么是 0.18.13 而不是 0.19.0版本决策是发布就绪文档中最具可复用价值的一节。选择0.18.13、否决0.19.0的判定依据是发布范围评审未发现被移除的活跃命令无 package bin/engine 破坏无不相容的公共 schema无破坏性公共 API 变更。当前范围属于 fixes、CI/docs、依赖升级、additive 的 setup/session 发现、geobench 文档/规格以及兼容性保持的 runtime/hook/setup 加固——这些全部满足补丁版本的升版标准。独立评审证据来自 Ultragoal G001 检查点executor QA/red-team 子代理1-ReleaseScopeQa与架构评审子代理2-ReleaseScopeArchitectFast均批准0.18.13而非0.19.0。这套“先做破坏性扫描、再让 QA 与架构双线独立评审、最后拍板语义化版本”的流程正是 RELEASE_PROTOCOL.md 所倡导的发布纪律的实例化。核心功能一项目级 resume/session-search 发现#2846从运行时目录到发现逻辑0.18.13最大的用户可见变化是增量式发现行为项目作用域的运行时 Codex home 被纳入omx resume和omx session search的搜索范围。底层实现位于 src/cli/project-runtime-codex-homes.tsdiscoverProjectRuntimeCodexHomes(cwd)返回ProjectRuntimeCodexHome[]每个条目携带export interface ProjectRuntimeCodexHome { path: string; sessionCountHint: number; source: project | madmax-run; publicLabel?: string; }发现逻辑分两条路径最后合并并按source优先、路径降序排序本地项目运行时 home扫描omxRoot(cwd)/runtime/codex-home下所有以omx-前缀开头的目录仅当存在sessions子目录时才计入sessionCountHint用会话年份目录数估算关联 Madmax 运行时 home从registry.jsonl与各run-*目录的.omxbox-run.json元数据中解析source_cwd/run_dir通过realpath规范化路径与当前cwd比对过滤出关联 run 目录根目录默认~/.omx-runs可用OMX_RUNS_DIR环境变量覆盖再在.omx/runtime/codex-home下发现omx-*home。从源码结构可以推断source: project与source: madmax-run的区分是为了让后续展示层可以标注madmax:name这样的来源标签帮助用户区分普通项目会话与 Madmax 运行派生会话。--project 与 --codex-home 逃生舱命令行的实际参数定义在 src/cli/session-search.ts 的 help 文本中omx session search与omx session friction均支持--project scope Filter by project context: current | all | cwd-fragment --codex-home path Search only the supplied Codex home (escape hatch)其中--project可取current、all或任意cwd片段--codex-home是“只看指定 home”的显式逃生舱。解析层同时支持空格分隔--codex-home path与等号形式--codex-homepath两种写法。搜索子命令还提供--limit默认 10、--session、--since、--context默认 80、--case-sensitive、--json等选项完整用法可通过node dist/cli/omx.js session search --help查看——这也正是发布验证中 dogfood 过的命令之一。# 只在当前项目作用域内搜索 omx session search worker inbox path --project current # 跨全部作用域搜索且只看最近 7 天 omx session search all_workers_idle --since 7d --limit 5 # 显式指定某个 Codex home逃生舱 omx session search resolve --codex-home --codex-home /path/to/codex-home # 结构化输出便于脚本消费 omx session friction --project current --json核心功能二Setup 保留自定义 native-agent TOML#2820保留与覆盖语义#2820Preserve customized native agent TOMLs让 setup 在重新生成 native-agent 配置时保留用户已做的定制。在 src/cli/setup.ts 中可以看到完整的决策类型体系type PluginDeveloperInstructionsDecisionAction add | update | preserve; // 以及针对已有内容的分类状态 state: missing | current | historical | custom;从源码结构可以推断setup 会先对现有内容做状态分类缺失 / 与生成版一致 / 历史残留 / 用户自定义只有custom状态才触发“保留”决策文档还记录了对preserve-or-add、refresh等分支的处理。此外 setup 中大量出现的 “Native hook transaction … refusing to overwrite concurrent content” 与 “preserved … for manual recovery” 日志说明涉及 native hook 的写入全部走事务化流程——写入前校验 read-back若发现并发修改则拒绝覆盖回滚时若内容与事务版本不符则保留现场供人工恢复。这与#2820的“setup 更安全”目标是同一套保证。配套测试覆盖了 overwrite/scope 行为例如 src/cli/tests/setup-prompts-overwrite.test.ts 与 src/cli/tests/setup-scope.test.ts、src/cli/tests/setup-hooks-shared-ownership.test.ts验证 setup 在共享所有权与覆盖场景下的行为边界。关联加固点#2843 Fix hooks JSON state compatibility加固 hook 持久化 JSON 状态的读写兼容防止旧状态文件在升级后被误判#2836 Preserve project Codex transcripts on cleanup清理流程跳过项目级 Codex transcripts避免误删用户会话证据#2831 Suppress child-agent lifecycle notifications before canonical session reconcile在规范会话对账之前抑制子代理生命周期通知减少重复/噪音通知。核心功能三Ralplan / Autopilot 共识新鲜度#2816、#2817、#2821、#28290.18.13对 Ralplan规划/评审管线与 Autopilot 的手工衔接点做了一组收紧#2816 Harden ralplan consensus freshness gates与#2817 Fix Autopilot ralplan consensus freshness共识门控必须基于“新鲜”的共识证据避免沿用过期 gate 结果放行执行交接#2821 Accept tracker-backed ralplan native reviews允许接受由 tracker 记录的 native 评审结果扩大有效评审来源#2829 Make deep-interview/RALPLAN Bash write detector target-awareBash 写入检测从“笼统检测”改为“目标感知”减少误报。代码侧可以在 src/ralplan/ 中看到ralplan_consensus_gate: { complete: boolean }这个状态字段贯穿运行时契约与测试例如 src/ralplan/tests/runtime.test.ts 中断言 Autopilot 交接时ralplan_consensus_gate.complete truesrc/ralplan/tests/advisory.test.ts 与 src/ralplan/tests/documented-leader-preflight.test.ts 则验证未完成/过期 gate 必须保持complete: false从而阻断执行授权。这些测试共同保证了“共识未达成不放行”的不变式。配套加固与依赖更新#2824 Align sidecar Team state root with Team runtime让 sidecarsrc/sidecar/的 Team 状态根路径与 Team 运行时一致消除状态分裂#2845 Move CI workflows to GitHub-hosted runnersCI 迁移到 GitHub 托管 runner提升运行稳定性与可复现性#2826 Make dev-merge issue-close PR follow-up comments best-effortdev 合入后自动关闭 issue 的评论改为 best-effort不再因评论失败阻塞合并流程依赖刷新biomejs/biome2.4.16 → 2.5.0#2833、types/node25.9.2 → 25.9.3#2832Geobench 修复新增可见性规格/档案并修复富档案与 romanization schema直接提交51868d56、a49c32dd、5e918a52、e75261d0使 geobench/oh-my-codex.yaml 这类基准配置可重复执行。版本与锁文件审计多仓同步的一致性检查0.18.13的版本号需要在多个位置同步发布就绪文档明确列出了清单文件同步内容package.json/package-lock.json根包版本 →0.18.13根Cargo.toml/ 根Cargo.lock工作区包版本 →0.18.13omx-api、omx-explore-harness、omx-mux、omx-runtime、omx-runtime-core、omx-sparkshellplugins/oh-my-codex/.codex-plugin/plugin.json插件版本 →0.18.13一致性由专用脚本强制校验其退出码即判定依据node dist/scripts/check-version-sync.js --tag v0.18.13 # PASSpackage0.18.13 workspace0.18.13 tagv0.18.13该脚本对应源码 src/scripts/check-version-sync.ts并配套测试 src/scripts/tests/check-version-sync.test.ts防止未来版本在多仓元数据上漂移。此外src/catalog/generated/public-catalog.json与templates/catalog-manifest.json也属于发布包的版本/元数据同步范围。本地验证流水线从构建到打包的可复现清单发布就绪文档记录了完整的本地验证证据在原仓库中对应artifacts/release-0.18.13/logs/下的一系列日志。核心命令如下# 1) 构建 npm run build # 2) 版本同步校验 node dist/scripts/check-version-sync.js --tag v0.18.13 # 3) native-agent 验证22 个可安装 native agent 37 个 setup prompt 资产 npm run verify:native-agents # 4) 插件包验证29 个规范技能目录与插件元数据 npm run verify:plugin-bundle # 5) 目录文档一致性 node dist/scripts/generate-catalog-docs.js --check # 6) 面向变更面的聚焦测试release/session/setup/hook/workflow # —— 期间修复了一次孤立的 session-search 环境泄漏 # 7) Dogfood 已构建 CLI/包表面 node dist/cli/omx.js --version node dist/cli/omx.js session search --help # 8) 打包预演 npm pack --dry-run # oh-my-codex-0.18.13.tgz包体积 3,978,807 bytes # 解包体积 24,892,739 bytes共 3065 个文件 # 9) 空白差异检查 git diff --checknpm pack --dry-run会给出机器可读的 JSON 输出对应npm-pack-dry-run-json.log便于自动化解析包构成。文档特别记录了两处值得注意的工程细节时序敏感测试首次test-ci-compiled.log捕获到一个时序敏感的 process-tree 失败单独重跑process-tree-rerun.log通过后再整体 clean reruntest-ci-compiled-rerun.log全绿——这是对 flaky 测试的标准处理先隔离复现再整仓回归环境问题 vs 候选问题dogfood 时omx doctor暴露了一个既存的用户 home hooks 迁移问题被判定为环境状态而非发布候选缺陷不阻塞发布。npm run smoke:packed-install对应 src/scripts/smoke-packed-install.ts验证打包安装链路完整编译级 CI 门由npm run test:ci:compiled对应 src/scripts/run-compiled-ci.ts驱动依次执行 native-agent 验证、插件包验证、完整编译 node 套件与目录文档检查。全部通过后本地的“发布就绪”才成立。CI 与发布证据dev → main → tag 三段式证明发布就绪文档将远程证据按生命周期分为三段每段都有独立 CI run 编号发布预备 dev CIrun27674248675提交b619f5a0…——greendev/main 晋升 CIrun27674657459提交daf7c7c2…——green标签触发发布工作流run27674982310v0.18.13于daf7c7c2…——PASS。随后的最终证明是双渠道的GitHub release 证明gh release view v0.18.13显示为非 draft、非 prerelease携带57个资产其中包含native-release-manifest.json其生成脚本见 src/scripts/generate-native-release-manifest.tsnpm 证明npm view oh-my-codex version返回0.18.13说明发布工作流已带 provenance 发布。最终就绪结论与交接清单当前就绪结论0.18.13已正式发布release tag 指向daf7c7c21f602584294f9a04ef5155b5ccfb0e96GitHub release 资产已发布npm 报告oh-my-codex0.18.13。已知缺口/待办门禁对于已发布的v0.18.13标签为零——本就绪文件特意在标签发布后以 docs-only 方式补录证据而不是回移不可变标签。已发布版本构成了完整的交接证据包发布配套CHANGELOG.md、RELEASE_BODY.md、docs/release-notes-0.18.13.md 与本文所依据的就绪文件版本/包元数据package.json、package-lock.json、Cargo.toml、Cargo.lock、plugins/oh-my-codex/.codex-plugin/plugin.json、src/catalog/generated/public-catalog.json、templates/catalog-manifest.json本地验证日志build.log、version-sync.log、verify-native-agents.log、verify-plugin-bundle.log、catalog-docs-check.log、no-unused.log、focused-release-tests.log、test-ci-compiled-rerun.log、npm-pack-dry-run.log、npm-pack-dry-run-json.log、git-diff-check-final.log、cli-dogfood.log、package-dogfood.log、smoke-packed-install.log远程发布证明dev CI run27674248675、main CI run27674657459、发布工作流 run27674982310、GitHub releasev0.18.13、npm registry 版本0.18.13。结语这套流程对后续版本的复用价值回顾整个0.18.13生命周期最有价值的部分并不是补丁本身而是它沉淀出的可复用发布方法论合并拓扑审计避免 cherry 双计数→ 破坏性扫描决定补丁/次版本 → 双线子代理独立评审 → 全仓版本一致性脚本校验 → 本地“构建-验证-打包”清单 → dev/main/tag 三段 CI 证明 → 发布后文档补录。仓库中 docs/qa/ 目录下从0.8.1到0.21.2的系列就绪文件如 docs/qa/release-readiness-0.18.12.md、docs/qa/release-readiness-0.21.2.md正是这一方法论不断演进的完整档案——如果你负责维护或发布任何 Agent/CLI 项目0.18.13的这篇记录可以作为一份开箱即用的发布检查单模板。【免费下载链接】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），仅供参考