oh-my-codex 0.18.9 发布就绪审计更新通道、resume 历史修复与全量门禁验证实践【免费下载链接】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导读本文基于 oh-my-codex 仓库中的 release-readiness-0.18.9.md 发布就绪文档系统还原 0.18.9 这一更新/运行时可靠性特性列车的发布全过程包括稳定版/开发版双更新通道、Windowsnpm.cmd回退、项目级 resume 历史与OMX_ROOT记忆查找修复、omx question在 cmux/tmux 下的环境投递、深度访谈短窗格可见性、HUD 窗格作用域收敛等 15 个合并 PR以及从版本同步探针、构建、Lint、5787 项测试到 npm 发布含 Sigstore/Fulcio 故障回退的完整门禁证据链。读者读完后将掌握OmX 的发布就绪流程长什么样、每次小版本背后修复了哪些真实问题、以及冻结候选 → 本地验证 → CI 推广 → 发布 → 收尾同步这一可复用的发布方法论。0.18.9 的发布范围一次更新与运行时可靠性列车0.18.9 不是功能大版本而是打包了0.18.8之后一组围绕更新机制、运行时可靠性、交互可见性与 CI 加固的补丁集合。按就绪文档的 Release scope 划分本次范围包含六条主线稳定/开发双更新通道omx update支持stable与dev两种 channel支持 dev 源包工件安装并为 Windows 提供npm.cmd回退项目级 resume 历史修复修复隔离启动时项目本地 resume 历史丢失#2713并修复 boxedOMX_ROOT下的SessionStart项目记忆查找#2708问答与深度访谈体验omx question在 cmux 下通过 export 前缀投递环境变量tmux-eshim 变通#2709、短 tmux 窗格中保持深度访谈问题可见#2702、repo 文档支撑的访谈交接#2690Autopilot 与团队行为Autopilot ralplan 写入守卫改为阶段感知#2691、review 子代理尊重 model/effort 设置#2697、Ultragoal HUD 在目标完成前保持活跃#2699HUD 与 CI 加固重复 HUD 对账收敛到发出事件的窗格#2703、fork/自托管 CI 加固#2704、#2693发布卫生0.18.8 发布后证据清理与就绪审计修正。此外冻结的 dev 范围内还有 6 个无 PR 的内部提交6a897a81、757b84a8、a7482450、dd7f369f、320fe769、403e2549全部围绕发布同步证据规范化与Fulcio 中断期间的 npm 发布回退记录。事实依据release-readiness-0.18.9.md 的 Release scope 与 Merged PR inventory、Internal/no-PR commits in frozen dev range 小节。候选版本冻结与范围审计发布就绪文档在 Range 小节精确记录了候选版本的来源与校验方式这是整个流程的起点上一标签v0.18.8候选分支dev分支 / 来自dev的 release-prep worktree目标标签v0.18.9冻结的 dev 候选115b697d153d9a9842fbd3459fefd2fb09df6d94提交说明为 Preserve project resume history during isolated launches (#2713)即本次发布内容中最后一个需要封存的提交对比区间v0.18.8..origin/dev。冻结后的复验命令非常明确这也是可复现冻结的关键# 确认 origin/dev 与本地 HEAD 都指向冻结提交 git rev-parse origin/dev git rev-parse HEAD # 确认 v0.18.8 是 origin/dev 的祖先保证范围干净 git merge-base --is-ancestor v0.18.8 origin/dev其中git merge-base --is-ancestor v0.18.8 origin/dev通过意味着v0.18.8..dev区间内不存在反向合入或分叉候选范围是线性的、可审计的。另外在发布准备提交之前dev 头部的 GitHub Actions CIrun26856266656对115b697d已完成且成功这保证了冻结候选在进入本地门禁前就有一份远程 CI 证据。关于 issue 清单本地发布准备期间未发现v0.18.8..HEAD区间内有单独关闭的 GitHub issue整个发布范围完全由上述合并 PR 清单表示。版本与锁文件审计一处同步处处同步0.18.9 的版本号一致性检查覆盖了 npm 与 Rust 两侧根package.json与package-lock.json升到0.18.9根Cargo.toml与根Cargo.lock升到0.18.9plugins/oh-my-codex/.codex-plugin/plugin.json同步到0.18.9crates/omx-sparkshell/Cargo.lock保持独立的0.1.0历史锁文件cargo generate-lockfile --manifest-path crates/omx-sparkshell/Cargo.toml执行后不变——它不受 workspace 发布版本约束workspace 发布版本由根Cargo.toml/ 根Cargo.lock决定。这条审计的意义在于OmX 是 npm 包 Rust 子 cratesparkshell 等的混合仓库如果只改package.json而漏掉plugin.json或根Cargo.toml发布后的产物会出现版本不一致。仓库为此专门提供了 check-version-sync.js 探针见下节门禁清单来机械地保证这一点。本地验证门禁从版本同步探针到全量测试就绪文档 Local validation evidence 给出了完整的门禁清单。所有命令在/Users/bellman/Documents/Workspace/oh-my-codex下执行且会继承会话/运行时变量的门禁在复跑时主动清空了USE_OMX_EXPLORE_CMD、OMX_ROOT、OMX_STATE_ROOT、OMX_TEAM_STATE_ROOT、OMX_SESSION_ID、CODEX_SESSION_ID等变量——这是为了防止本地残留的会话状态污染发布判定。版本同步与静态门禁node dist/scripts/check-version-sync.js --tag v0.18.9 # 版本同步探针PASS npm run build # 构建PASS npm run lint # LintPASS npm run check:no-unused # 未使用代码检查PASS npm run verify:native-agents # native agents 清单校验PASS npm run sync:plugin npm run sync:plugin:check # 插件镜像同步与校验PASS npm run verify:plugin-bundle # 插件 bundle 校验PASS node dist/scripts/generate-catalog-docs.js --check # 目录文档生成检查PASS git diff --check # 空白/冲突标记检查PASS其中check-version-sync.js正是对上一节版本与锁文件审计的自动化执行sync:plugin/sync-plugin-mirror对应的脚本位于 sync-plugin-mirror.ts保证plugins/oh-my-codex与主包内容同步。全量测试矩阵npm test # 5787 pass / 0 fail / 1 intentional skip npm run test:ci:compiled # 编译产物 CI 测试同样 5787/0/1 npm run test:compat:node # Node 兼容性测试 npm run test:sparkshell # sparkshellRust测试 npm run test:explore # explore 测试 npm run test:recent-bug-regressions:compiled # 近期 bug 回归 npm run test:team:worker-runtime-identity:compiled # 团队 worker 运行时身份 npm run test:plugin-boundaries:compiled # 插件边界 npm run test:ralph-persistence:compiled # ralph 持久化 npm run test:explicit-terminal-contract:compiled # 显式终端契约全量npm test与编译后 CI 测试均为5787 通过 / 0 失败 / 1 个有意的跳过且test:question在行内 TTY 加固后单独复跑通过。仓库根目录 package.json 中的test:ci:compiled、test:recent-bug-regressions:compiled等脚本即对应这些门禁读者可对照查看每个脚本实际启动的测试文件。运行时冒烟与发布探针omx doctor # PASS仅 1 条本地用户配置告警 codex login status # PASStoken 脱敏 omx exec --skip-git-repo-check -C . Reply with exactly OMX-EXEC-OK # exec 冒烟PASS npm run test:reply-listener:live # 按契约 SKIP未设 OMX_REPLY_LISTENER_LIVE1 npm pack --dry-run # 生成 oh-my-codex-0.18.9.tgz3.9 MB / 解包 24.0 MB / 3029 文件 npm run smoke:packed-install # 打包安装冒烟PASSnpm pack --dry-run的产物尺寸oh-my-codex-0.18.9.tgz3.9 MB解包 24.0 MB3029 个文件直接写入就绪文档作为打包内容与体积的客观证据。团队演示的失败关闭Fail-Closed实践一个值得单独说明的细节WORKER_COUNT5 bash src/scripts/demo-team-e2e.sh现场演示在活动的 Autopilot tmux leader 内被标记为ENV-BLOCKED/CLEANED——提交前运行正确地因leader_workspace_dirty_for_worktrees失败关闭fail closed提交后/隔离尝试虽进入 worker 启动但被强制清理且无根目录改动。这是发布流程中环境不满足就宁可放弃演示证据也不伪造成功的典型做法替代证据是编译后的团队运行时/身份门禁test:team:worker-runtime-identity:compiled与全套件中的团队 API 覆盖。静态审查子代理与 UltraQA 对抗性检查静态发布审查子代理第一轮因过期的就绪复选框与盲按键轮询被 BLOCKED修复后最终轮 APPROVE/CLEAR子代理019e8cb9-cff6-74e1-bc4c-1de10f7ef2b2UltraQA 发布流程对抗性检查PASS/CLEAN报告写入.omx/release-0.18.9/ultraqa-report.md动态探针在.omx/release-0.18.9/logs/ultraqa-*.log。这个子代理先审、UltraQA 再打的两级模式把发布质量从人工经验判断提升为可追踪的自动化门禁。CI 与发布证据从 dev 推广到 tag 触发工作流CI 证据链发布准备devCIGitHub Actions run26875635807对ffd02c65完成/成功主分支main推广 CIrun26876121950对ffd02c65完成/成功tag 触发的发布工作流run26876924380通过了从版本同步到打包全局安装冒烟的全部门禁但npm publish --provenance两次失败于CA_CREATE_SIGNING_CERTIFICATE_ERROR/ Fulcioread ECONNRESET。npm 发布失败与回退Fulcio 中断npm publish --provenance依赖 Sigstore Fulcio 服务签发签名证书。本次发布中 Fulcio 连续两次重置签名证书请求导致带 provenance 的发布失败。仓库的处理是临时回退工作流run26878002529检出v0.18.9标签后以npm publish --access public --provenancefalse发布完全相同的标签工件不重新打标签、不改变代码内容。这也是为什么就绪文档把npm provenance列为 0.18.9 唯一例外。发布后证据核验# GitHub release 状态draftfalse, prereleasefalse, 57 个资产含 native-release-manifest.json # npm 视角 npm view oh-my-codex version dist-tags --json # 0.18.9 / latest: 0.18.9发布后的 REST release 证明显示v0.18.9为非草稿、非预发布含 57 个资产含native-release-manifest.json发布资产清单的生成与校验逻辑可参考 generate-native-release-manifest.ts 与 verify-native-release-assets.ts。npm 侧latestdist-tag 确认为0.18.9。回退工作流移除与证据更新后main与dev同步到同一发布后文档证据 tip发货源码标签仍为v0.18.9d409013946bf61a0747d75cd93206ea5673b0fc9。最终同步后的分支 CI 在.omx/release-0.18.9/logs/final-ci-runs.tsv记录后关闭 Autopilot goal。本次发布的修复点源码级解读就绪文档列出了 15 个 PR其中与用户直接相关的修复在源码中都能找到对应实现。以下选取 4 个最能体现可靠性主题的修复做源码级展开。1. 更新通道stable / dev 双通道与 Windows 回退omx update的通道模型定义在 src/cli/update.tsexport type UpdateChannel stable | dev; // L65 export interface UpdateChannelConfig { channel: UpdateChannel; installSource: string; } export function resolveUpdateChannelConfig(channel: UpdateChannel stable): UpdateChannelConfig { if (channel dev) { return { channel: dev, installSource: DEV_INSTALL_SOURCE }; // github:Yeachan-Heo/oh-my-codex#dev } return { channel: stable, installSource: STABLE_INSTALL_SOURCE }; // oh-my-codexlatest }稳定通道安装源为oh-my-codexlatestnpm registry开发通道为github:Yeachan-Heo/oh-my-codex#devGitHub 仓库 dev 分支并带 300 秒的 dev 更新超时DEV_UPDATE_TIMEOUT_MS。更新检查状态写入项目.omx/state/update-check.json检查间隔为 12 小时CHECK_INTERVAL_MS版本比较使用严格的 semver 解析isNewerVersion。更新执行结果状态机覆盖updated / scheduled / up-to-date / declined / failed / skipped / unavailableUpdateExecutionResult.status自动更新模式由OMX_AUTO_UPDATE环境变量控制空值/未设置为prompt0为disableddefer为延迟执行resolveAutoUpdateMode。PR [#2706] 的 Windowsnpm.cmd回退则让 Windows 上通过 npm 安装的用户在更新时能正确解析npm.cmd而不是裸npm。2. 项目级 resume 历史与 boxed OMX_ROOTPR [#2713] 修复隔离启动时项目本地 resume 历史丢失。会话历史的落盘逻辑位于 src/hooks/session.ts历史文件为session-history.jsonlHISTORY_FILE由historyDirectory(context)/historyPath(context)计算路径追加写入historyEntry含session_id、native_session_id、active_session_id、preserved_active_session_id等字段并保证先归档、再删除属主指针避免历史未写入就丢失指针。PR [#2708] 修复 boxedOMX_ROOT下的SessionStart项目记忆查找。OmX 支持用OMX_ROOT把状态根装箱到指定目录例如OMX_ROOT$HOME/.omx/instances/second-conversation omx这种多会话隔离用法此前SessionStart钩子在该模式下查找项目记忆时会因 cwd 默认值与 boxed 根不一致而失效修复后记忆查找以 boxedOMX_ROOT为准。session-search.ts 中的--project current | all | cwd-fragment过滤则提供用户侧的项目维度会话检索入口。3. omx questioncmux 环境投递与短窗格可见性PR [#2709] 解决omx question在 cmux轻量 tmux 兼容层下无法把环境变量投递给渲染器的问题采用export 前缀变通 tmux-eshim不依赖tmux -e直接注入环境而是在发送的 pane argv 前拼export KEYVALUE; ...。question/renderer.ts 的策略判定逻辑resolveQuestionRendererStrategy优先使用inside-tmux当TMUX存在支持OMX_QUESTION_RETURN_PANE/OMX_LEADER_PANE_ID显式桥接提示tmux 不存在且TMUX缺失时失败关闭fail closedWindows 无 tmux 桥接但终端交互时回退inline-tty。对应测试见 question/tests/renderer.test.ts。PR [#2702] 让深度访谈问题在短 tmux 窗格中保持可见此前窗格高度不足时渲染器可能把问题滚出可视区本次通过调整渲染/裁剪逻辑保证问题文本常驻。这与 deep-interview.ts 的问答循环共同构成了omx question的完整交互链路。4. HUD 对账窗格收敛与 Ultragoal 完成可见性PR [#2703] 修复重复 tmux HUD 对账作用域发散每次对账只应作用于发出事件的窗格而不是把同 session 所有窗格都当成 HUD 重建对象。HUD 对账入口在 hud/index.ts 的hudCommand([--reconcile-tmux], ...)实际委托reconcileHudForPromptSubmit窗格归属通过OMX_TMUX_HUD_OWNER环境变量标记即便OMX_SESSION_ID/OMX_ROOT未设置也始终发射该标记见 hud/tests/hud-tmux-injection.test.ts。对应实现位于 hud/reconcile.ts并提供窗格自适应高度调整与历史清理能力resizeTmuxPaneFn/clearTmuxPaneHistoryFn。PR [#2699] 让 Ultragoal HUD 在目标完成前保持活跃避免目标未完成时 HUD 提前退出。PR [#2691] 让 Autopilot 的 ralplan 写入守卫阶段感知——不同 ralplan 阶段如证据收集 vs 提交判定允许的写入不同守卫不再一刀切。PR [#2697] 让 review 子代理真正尊重配置的 model 与 effort 设置避免子代理悄悄降级模型。就绪结论已发货唯一例外是 npm provenance就绪文档的最终判定是Release 0.18.9 is shipped。GitHub release 与 57 个 native 资产完整draftfalse、prereleasefalsenpmlatest为0.18.9main与dev已同步到发布后文档证据 tip唯一例外是 npm provenanceSigstore Fulcio 两次重置签名证书请求导致带 provenance 的发布失败随后通过临时 GitHub Actions 回退以--provenancefalse发布了同一v0.18.9标签工件最终分支 tip CI 作为该证据提交的收尾门禁在.omx/release-0.18.9/logs/final-ci-runs.tsv中记录。方法论沉淀从这份就绪文档可复用的发布清单结合 RELEASE_PROTOCOL.md 与本次文档0.18.9 的实践可以提炼为一条可复用的发布清单冻结并锁定候选记录冻结提交 SHA用git rev-parsegit merge-base --is-ancestor复验线性范围范围审计汇总区间内合并 PR 与内部提交声明 issue 清单可为空版本同步审计package.json/package-lock.json/ 根Cargo.toml/Cargo.lock/plugin.json全部对齐独立 lockfile如 sparkshell明确标注为不受 workspace 版本约束全量本地门禁版本同步探针 → build → lint → no-unused → native-agents 校验 → 插件同步/校验 → 目录文档 check → 全套测试矩阵含编译产物 CI、兼容性、sparkshell、explore、回归、团队、插件边界、持久化、终端契约→ doctor / exec 冒烟 →npm pack --dry-run→ 打包安装冒烟隔离环境复跑清空OMX_ROOT、OMX_STATE_ROOT、OMX_SESSION_ID等会话变量后再跑可继承变量的门禁防止环境污染判定对抗性复查静态发布审查子代理必要时修复后复审 UltraQA 对抗性检查CI 推广与发布dev CI → main 推广 CI → tag 触发发布工作流发布失败时不重打标签用回退工作流发布同一标签工件并如实记录例外发布后核验与收尾REST release 视图非草稿/非预发布/资产数npm viewdist-tags main/dev同步 最终分支 CI 记录后关闭 goal。这套流程的关键特征在于证据全覆盖与失败关闭每一个门禁都有对应日志路径.omx/release-0.18.9/logs/*环境不满足时宁可 BLOCK/ENV-BLOCKED 也不伪造成功发布例外provenance被如实写入就绪结论——这正是发布工程中可审计、可追溯、不掩盖异常的最佳实践。相关阅读发布协议、0.18.8 就绪审计若需对比上一版本的差异范围可对照 0.18.8 release-notes 与 0.18.9 release-notes。【免费下载链接】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），仅供参考