oh-my-codex 0.18.3 发布解析HUD 生命周期清理、Deep-Interview 权限收紧与插件边界保护【免费下载链接】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-codexoh-my-codex 0.18.3 是继 0.18.2 之后的一个 patch 版本聚焦于dev分支上的发布后可靠性与运维体验补丁列车post-release reliability and operator-experience train。它集中修复了 HUD/tmux 生命周期清理、提升 Team diff 的可读性、支持 auth 槽位热切换、保持 explore 提示语法可见、支持 deep-interview 运行时配置覆盖与更严格的下游执行权限、保护插件自有 hook并新增了 Scholastic ontology 评审 agent。读完本文你将掌握 0.18.3 各项改动的设计动机、底层实现路径、可复用的配置方法以及版本发布前的完整验证流程与已知残余风险。版本定位与发布范围0.18.3是一个 patch 版本来源为dev分支上对0.18.2的跟进修复。从发布就绪文档docs/qa/release-readiness-0.18.3.md可知上一个 tagv0.18.2commit29e87a24a0ed354283604bfc1ba995d1245813c4候选分支dev在7f0a3fa1发布元数据 rebase 到最新origin/devdelta 之上发布的 tagv0.18.3。0.18.3 打包的改动面即本文的核心主线包括HUD 生命周期/reconcile 修复按 leader 合并启动期 pane、保留 session id/owner 环境变量、回收 dead-leader HUD pane、在 UserPromptSubmit 复活时复用既有 HUDTeam diff 在换行多行 hunk 上保留 diff gutterdeep-interview 运行时配置覆盖以及更严格的plan_then_execute下游执行权限约束auth 槽位热切换hot-swapwrapper 支持explore 运行时指引中保持 prompt 语法可见setup/update 路径上保留插件自有的 Codex hook不覆盖用户/插件表面新增 Scholastic ontology 评审 agentagent catalog 与 native config 表面skills/agents 膨胀审计bloat-audit与连通性路线图文档。HUD 生命周期清理更少陈旧、更少重复的 HUD pane这是 0.18.3 最大的修复主题。HUD 是 oh-my-codex 在 tmux 窗口中渲染的实时状态看板由一个hud --watchpane 承载。核心改动来自 src/hud/reconcile.ts 中reconcileHudForPromptSubmit及其辅助函数。同一 leader 的 HUD pane 合并coalesce启动路径与每次 prompt submit 都可能触发 HUD reconcile。当同一个 leaderCodex REPL pane在窗口内拥有多个 HUD pane 时planOwnedHudPaneDedupe会挑选一个 keeper pane将其余同 owner 的 pane 标记为重复并杀掉最终状态以replaced_duplicates返回。这样即使多个创建者并发观察到无 HUD并各自分裂出一个 HUD第二个创建者也会通过 create 后的二次扫描postCreatededupe把竞争产生的重复 pane 收敛掉而不是让用户窗口堆满重复看板。会话所有权保留session ownershipHUD watch pane 通过环境变量声明归属OMX_TMUX_HUD_OWNER值1标记该 pane 是显式由 omx 创建的 HUDOMX_TMUX_HUD_LEADER_PANE记录其所属 leader pane。这些字段在 src/hud/tmux.ts 中被解析为HudPaneOwner含sessionId、leaderPaneId等。0.18.3 修复了 HUD 启动/恢复过程中 session id 与 owner 环境变量的漂移避免跨 worktree 累积与陈旧 session-id/env 残留。回收 dead-leader HUD panereapreapOrphanedSessionHudPanes针对一个典型退化场景当 leader pane 被销毁例如teamsetup/teardown 周期拆掉了 leader REPL pane其 owner 标记的 HUD pane 仍指向已死亡的 leader id既无法被findHudWatchPaneIds要求记录的 leader 等于当前 pane匹配也无法被findLegacyFocusedHudWatchPaneIds只收养缺少 owner 元数据的 HUD匹配。于是每次 prompt submit 时 reconcile 都看到没有 HUD重新创建一个最终窗口退化成只剩一堆堆叠的 HUD 条带、没有任何 leader/worker pane。修复的关键约束是回收范围严格限定在当前 session属于其他 session 的 HUD pane其 leader 可能合法地存在于本窗口看不到的其他 tmux 窗口中绝不会被触碰。reapStaleCurrentLeaderHudPanes则处理另一种情况——Codex 自更新会在同一 tmux pane 内以新的 OMX session id 重启/恢复 leader而旧 HUD watcher 仍然存活此时只回收绑定到该确切 leader pane 的陈旧 HUD相邻 pane 的 HUD 仍按leaderPaneId隔离。reconcile 的并发安全由于同一窗口内所有 OMX pane 的布局变更 hook 可能同时触发reconcile 通过.omx/state/hud-reconcile.lock目录锁将 tmux 布局变更串行化HUD_RECONCILE_LOCK_STALE_MS 10_000锁过期阈值HUD_RECONCILE_LOCK_RETRY_MS 50重试间隔HUD_RECONCILE_LOCK_WAIT_MS 2_000最长等待时间。锁实现会读取owner.json含 token、pid、acquired_at对过期锁先 rename 到.stale.*路径做二次校验token 与 mtime 双重比对再原子接管持有者的 pid 已死才会被判定为陈旧否则视为并发的邻接 leader 正在持有而短暂等待。拿不到锁时返回skipped_concurrent并尽力重挂 resize hook避免邻接 leader 的一次性 hook 被误判为并发而丢弃。UserPromptSubmit 复活时复用既有 HUD发布说明明确提到0.18.3 在 UserPromptSubmit revive 路径上复用现有 HUD而不是重新分裂。结合 reconcile 逻辑当检测到单个 HUD pane 且几何拓扑无需重建needsHudTopologyRecreate为 false时仅做高度对齐needsHudHeightResize与 resize hook 重挂状态为unchanged或resized只有 HUD 缺失或拓扑错误宽度不贴合 leader、未紧贴 leader 下方或窗口底部时才重建。此外窗口高度过矮isTmuxWindowTooCrampedForHudSplit时 prompt submit 也会跳过分裂防止复活出启动路径本就拒绝添加的 2 行高挤压 HUD对应 issue #2754。Team diff 可读性换行 hunk 保留 gutter0.18.3 修复了 Team 输出中 diff hunk 的渲染问题被换行的多行 diff hunk 之前会丢失左侧的 diff gutter导致长补丁在 tmux pane 中难以对照阅读。本次改动让 wrapped 的多行 diff 仍保留 gutter 前缀长补丁在窄 pane 中依然保持可读。对应测试见 src/team/tests/tmux-session.test.ts 中的用例 redraws the leader pane after team layout changes so wrapped diff hunks repaint with gutters约第 5316 行该用例用 mock tmux fixture 模拟 leader/worker/HUD 多 pane 布局变化验证 leader pane 在 Team 布局变更后会被重绘从而让换行的 diff hunks 带着 gutter 重新上屏。Deep-Interview运行时配置覆盖与 plan_then_execute 权限门0.18.3 对 deep-interview 做了两件事支持运行时配置覆盖以及把plan_then_execute下游执行权限作为绑定门binding gate强制。运行时配置覆盖deep-interview 的运行时配置解析集中在 src/config/deep-interview.ts三个预设 profilequick/standard/deep默认standard每个 profile 有独立的阈值threshold与最大轮数maxRounds默认值profilethreshold 默认maxRounds 默认quick0.305standard0.2012deep0.1520配置以 TOML 表[omx.deepInterview]形式出现支持键defaultProfile、quickThreshold、standardThreshold、deepThreshold、quickMaxRounds、standardMaxRounds、deepMaxRounds、enableChallengeModes。enableChallengeModes默认truethreshold 必须落在(0, 1]区间maxRounds 必须是正整数非法值会被忽略并回退到默认值。配置文件按优先级级联查找getDeepInterviewConfigCandidatePathscwd/.omx/config.tomlproject-omxcwd/omx.tomlproject-rootgit worktree 根目录的.omx/config.toml与omx.toml若 cwd 不是 worktree 根~/.omx/config.tomluserresolveDeepInterviewRuntimeConfig按此顺序取第一个包含[omx.deepInterview]表的文件构建DeepInterviewRuntimeConfigprofile、threshold、maxRounds、enableChallengeModes、sourcePath。测试 src/config/tests/deep-interview.test.ts 覆盖了优先级级联例如 home 级standardThreshold 0.40、项目根omx.toml为0.30、项目.omx/config.toml为0.10时最终取最高优先级 0.10。这里同时体现 0.18.3 的关键语义高层级文件即使存在但未包含 deepInterview 表也不会级联到低优先级文件测试 does not cascade to lower-precedence configs when an existing higher-precedence file omits deepInterview。profile 也可以从调用文本中解析parseDeepInterviewProfileFromText识别$deep-interview/deep-interview调用之后的--quick/--standard/--deepflagflag 优先于defaultProfile。最终运行时会把这些配置写入状态字段deep_interview_config、profile、threshold、max_rounds、enable_challenge_modes、config_source供后续流程读取。plan_then_execute 下游权限门src/question/deep-interview.ts 中DeepInterviewStateRecord明确携带downstream_authority?: plan_then_execute | execute_now。0.18.3PR #2476/#2478将其作为 binding gate 强制执行deep-interview 提问完成后下游执行权限只能是plan_then_execute先规划后执行不能跳过规划直接execute_now。同时该文件实现了完整的提问义务obligation生命周期状态机createDeepInterviewQuestionObligation创建 pending 义务obligation_id、source: omx-question、lifecycle_outcome: askuserQuestion、requested_atsatisfyDeepInterviewQuestionObligation在收到已回答记录后置为 satisfiedclearDeepInterviewQuestionObligation在 handoff / abort / error 三种原因下清空reconcileDeepInterviewQuestionEnforcementFromAnsweredRecords从 question 记录目录反查已答记录并自动满足义务与 autopilot 的等待声明AUTOPILOT_DEEP_INTERVIEW_QUESTION_OWNER_ENV协同防止 autopilot 在执行模式阻塞时重复发起提问。runDeepInterviewQuestion是入口创建义务、声明 autopilot 等待、写 enforcement 状态、调用runOmxQuestion提问、成功则满足义务并 resolve 等待失败则清空义务并标记cleared。Auth 槽位热切换hot-swapwrapper0.18.3 纳入了 auth slot hot-swap wrapperPR #2484/#2493核心实现见 src/auth/hotswap.ts 的runAuthHotswap。其流程要点通过stripHotswapArg从 argv 中剥离--hotswap并剥离 leader 启动策略参数--direct/--tmux读取 auth 配置与已配置槽位omx auth add slot注册槽位omx auth use slot切换无槽位时直接提示错误并返回 1生成一次性的 hot-swap session idomx-timestamp-random调用lifecycle.preLaunch建立启动绑定把当前槽位的 auth.json 写入liveAuthPathuseSlot循环尝试槽位成功exit 0直接返回识别token_invalidated/refresh_token_invalidated等鉴权失效错误isAuthInvalidationError与 quota 错误isQuotaError见 src/auth/quota-detector.ts遇 quota 则标记该槽位markSlotQuota并旋转到下一槽位rotation 模式为manual时提示用户手动处理并返回遇 token 失效同样旋转并提示之后用omx auth add slot --device-auth刷新quota 场景还会用buildResumeArgsWithPreservedFlags构造codex resume sessionId参数保留原全局选项如-m/--model、-p/--profile、-c/--config、--sandbox等在旋转槽位后恢复最近的 rollout session避免配额切换后丢失上下文结束后执行postLaunch与运行时 codex home 清理任何异常信息经 src/auth/redact.ts 的redactAuthSecrets脱敏后输出。相关测试见 src/auth/tests/hotswap.test.ts。Explore 运行时指引保持 prompt 语法可见0.18.3PR #2494/#2495确保omx explore的运行时指引中始终展示 prompt 调用语法omx explore --prompt prompt与omx explore --prompt-file file这样运维者在实际使用 explore 时不至于丢失调用形态。值得注意的是当前仓库中omx explore已经进入 hard-deprecated 状态src/cli/explore.ts 的EXPLORE_DEPRECATION_MESSAGE明确说明该命令表面已被移除建议改用常规的 Codex 仓库检视工具/subagent 做只读检索或使用omx sparkshell -- command获取 shell 原生只读证据与--tmux-pane摘要。此外内置 explore harness 在 Windows 上不可用allowlist 运行时依赖 POSIX sh/bash wrapper可通过OMX_EXPLORE_BIN指定兼容的自定义 harness或直接运行omx doctor查看就绪状态。0.18.3 的贡献是保证在这个过渡期里explore 相关的运行时指引不会隐藏 prompt 语法本身。插件自有 hook 的保留0.18.3PR #2477让 setup 与 native hook 路径尊重插件所有权边界Codex 配置/安装过程中保留插件自有的 hook不再覆盖用户或插件表面同时对无效/缺失覆盖给出告警。相关的所有权保护语义在技能目录场景中也有同族测试佐证src/cli/tests/setup-skills-overwrite.test.ts 覆盖了普通刷新时退役 catalog 已移除的 OMX 技能、同时保留用户自建技能a user-authored skill is never OMX-owned即使技能目录收据与徽章被伪造也保留用户文件已退役的技能字节可回溯setup 备份根中prometheus-strict/SKILL.md可恢复setup 与--force刷新期间保留无关的用户自建技能目录。新增 Scholastic ontology 评审 agent0.18.3 引入了一等公民的 Scholastic ontology 评审 agentPR #2483进入 agent catalog 与 native config 表面。该 agent 面向本体论密集ontology-heavy的评审场景对评审对象做概念归一化、类别错误category mistake检测、模态声明modal claims分离等本体层面的审查。在后续文档docs/ultragoal.md 第 200 行中可以看到其评审输出形态的实例scholasticReview: { recommendation: APPROVE, ontologyStatus: SOUND, evidence: terms normalized; no category mistake; modal claims separated }即评审以结构化 JSON 呈现recommendation结论、ontologyStatus本体状态、evidence证据链。ultragoal 工作流中已通过 Scholastic 评审的 advisory 证据可带入质量门非 clean 的 Scholastic 结论应作为阻断性证据而非完成声明。当前版本迭代中该 agent 后续被 deregistered见 CHANGELOG.md 第 45 行附近 #3506/#3502/#3508 的说明但在 0.18.3 发布时刻它属于新增能力。Skills/Agents 膨胀审计文档0.18.3 携带了 skills/agents 膨胀审计bloat-audit与连通性路线图PR #2474完整落盘于 docs/audit/skills-agents-bloat-audit/ 目录inventory.md全量清单skill agent含状态、LOC、最后提交、引用计数与 skill↔agent 叙事耦合矩阵bloat-audit.md逐条分类为 KEEP-AS-IS / CONSOLIDATE / STREAMLINE / DEPRECATE / AMBIGUOUS每条附证据、动作与风险connectivity-roadmap.md孤儿orphan分析、连通性修复建议quick wins / medium / strategic与建议的 PR-by-PR 落地序列。顶层结论源自审计时点技能侧 50 个 catalog 条目、46 个磁盘条目其中 18 个 KEEP-AS-IS、7 个 STREAMLINE、4 个 CONSOLIDATE、16 个 DEPRECATE、5 个 AMBIGUOUSagent 侧 36 个33 个在AGENT_DEFINITIONS其中 23 个 KEEP-AS-IS、10 个 CONSOLIDATE、2 个 DEPRECATE、1 个 AMBIGUOUS。审计明确是意见 证据而非单边强制任何删除都需 owner 逐个 PR 审查且审计本身未改动任何生产表面。发布验证流程与已知残余风险UltraQA 与本地门禁0.18.3 的验证记录在 docs/qa/release-readiness-0.18.3.md使用的 UltraQA 规划产物包括.omx/context/release-0-18-3-after-ultraqa-20260525T040404Z.md、.omx/plans/prd-0.18.3-release.md、.omx/plans/test-spec-0.18.3-release.md、.omx/plans/release-0.18.3-ralplan-consensus.md与.omx/qa/ultraqa-release-0.18.3.md。完成的本地门禁npm run lintPASS检查 665 个文件无自动修复npm run check:no-unusedPASSnpm run testPASS5335 passed、0 failed、1 skippedcatalog 检查通过对抗性发布 harness对畸形状态、prompt 注入文本、反复中断/取消措辞、有界挂起的子进程、误导性成功输出、无 tag 副作用守卫均 PASS项目原生 targeted 变更区测试经dist/scripts/run-test-files.js重跑两次每次 1149 个测试、0 失败npm pack --dry-runmetadata bump 前后各一次最终产出oh-my-codex-0.18.3.tgz清单包大小 3.6 MB、解包 21.8 MB、2910 个文件bump 后最终npm run build/lint/check:no-unused/verify:native-agents/sync:plugin/verify:plugin-bundle/generate-catalog-docs.js --check/git diff --check全部 PASS。已接受的残余风险cargo test在crates/omx-explore/src/main.rs的run_command_with_timeout_kills_process_group_children断言失败期望子进程 TERM trap 文件包含term但断言窗口内为空。发布负责人明确指示本版本忽略该失败记录在就绪文档中并建议在下一次涉及 explore/process-tree 行为变更的版本前修复或隔离该断言crates/omx-explore。发布纪律UltraQA 期间git tag --points-at HEAD与git tag --list v0.18.3均无本地 tag未执行任何npm publish剩余外部动作提交 release prep、合并到发布分支、维护者批准后创建/推送v0.18.3tag、验证 GitHub release 工作流产物与 npm 发布、发布后回填证据。合并 PR 清单与总结0.18.3 的合并 PR 清单#2474、#2476、#2477、#2478、#2481、#2482、#2483、#2484、#2485、#2486、#2487、#2488、#2489、#2491、#2492、#2493、#2494、#2495。对应关系可从 docs/qa/release-readiness-0.18.3.md 的 Merged PR inventory 中逐一查阅如 #2481 合并启动 HUD pane、#2489 回收 dead-leader HUD、#2485/#2486 保留 HUD session id 与 owner env、#2487/#2491 Team diff gutter、#2476/#2478 deep-interview 权限、#2482 deepInterview 运行时配置覆盖、#2494/#2495 explore 语法可见性等。总体而言0.18.3 是一个典型的可靠性补丁版本它不引入新的大功能面而是把 HUD 生命周期、Team 输出渲染、deep-interview 权限、auth 旋转、插件所有权边界这些运维高频痛点在源码层面逐一钉死并用一套可复现的 UltraQA 流程与对抗性 harness 保证回归安全。对运维者和插件开发者而言本版本最值得关注的是三件事HUD reconcile 的并发锁与 dead-leader 回收语义、[omx.deepInterview]配置的级联优先级与plan_then_execute权限门、以及插件 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考