OmX 0.20.3 版本深度解析按 Agent 推理强度上限、tmux 面板精确权威与 Ralplan 评审完整性加固【免费下载链接】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-codexOmXOh My codeX0.20.3 是一个面向可靠性、工作流安全与细粒度模型控制的 patch 版本冻结范围为v0.20.2..f967cfed64ec57614af136f75d7cb81509808f7e共合并 13 个产品 PR其中仅一项为向后兼容的新增特性其余均为稳定性与流程安全修复。本文以官方 release notes 为骨架结合仓库源码逐项拆解团队模型契约的按 Agent 推理强度上限、Team 精确 live-pane 权威、Ralplan 评审完整性、邮箱唤醒合并与跨平台fsync容错等核心变更并给出可复现的版本盘点命令与验证记录入口。版本概览patch 发布的范围与定位0.20.3的发布日期为 2026-07-19属于补丁发布patch release没有有意的破坏性 CLI 或包布局变更。唯一的新特性 #3143按 Agent 上限的推理强度是加法式、向后兼容的。完整范围包含 99 个提交构成如下13 个合并的产品 PR#3135、#3143、#3153、#3186、#3187、#3191、#3192、#3196、#3201、#3211、#3215、#3217、#32184 个 v0.20.2 发布后证据修正1c007fff、122b0cba、fb13a6db、0a7baa81仅作为发布配套资产release-collateral inventory不是 0.20.3 的产品头条1 个发布开发准备提交4b557d13负责开启 0.20.3 开发并同步版本元数据其余提交是 PR #3153、#3196、#3215、#3217、#3218 的 squash 组成提交。对应的发布就绪记录在 docs/qa/release-readiness-0.20.3.md其中记录了发布身份、冻结提交清单、必需门禁gates的本地证据与发布序列publish sequence。新特性团队模型契约的按 Agent 推理强度上限#3143特性含义#3143 让推理强度reasoning effort可以通过团队模型契约按 Agent 上限封顶从而在一个团队内部对不同的 Agent 角色施加更细粒度的模型行为控制。例如探索类 Agent 使用低推理强度以节省成本而评审类 Agent 使用高推理强度以保障质量。源码级实现证据推理强度的合法取值定义在 src/config/models.tsexport const PER_AGENT_REASONING_EFFORTS [low, medium, high, xhigh, max] as const; export type PerAgentReasoningEffort (typeof PER_AGENT_REASONING_EFFORTS)[number];与根级root推理强度不同根级只允许low/medium/high/xhighROOT_REASONING_EFFORTSmax与ultra被标记为根级不支持的取值ROOT_UNSUPPORTED_REASONING_EFFORTS而按 Agent 维度则允许max这正是按 Agent 上限的语义所在。团队侧的契约在 src/team/model-contract.ts 中实现TeamReasoningEffort类型别名直接复用PerAgentReasoningEffortresolveAgentReasoningEffort(agentType, codexHomeOverride)会依次读取 Agent 的推理覆盖getAgentReasoningOverride与 Agent 定义中的reasoningEffort用于解析某类 Agent 的角色默认推理强度resolveTeamWorkerLaunchArgs负责把环境变量OMX_TEAM_WORKER_LAUNCH_ARGS、Leader 继承参数与角色默认值合并、归一化最终生成 worker 的实际启动参数关键配置键为model_reasoning_effort通过-c model_reasoning_efforthigh形式的 Codex 配置项传递parseTeamWorkerLaunchArgs中的isReasoningOverride/extractReasoningEffort专门识别该键环境变量OMX_TEAM_WORKER_LAUNCH_ARGS的解析器tokenizeWorkerLaunchArgs刻意不执行 shell 语法求值只实现有限的双引号/单引号与转义语法避免把任意 shell 注入引入 worker 启动参数。此外模型选择遵循明确的优先级链selectTeamWorkerModel环境变量显式模型 继承的 Leader 模型 角色回退模型当honorExactRoleModel开启且存在角色回退模型时角色精确模型优先于继承模型。启动参数的来源可诊断化ResolvedTeamWorkerLaunchDiagnostics中的modelSource区分env/inherited/fallback/nonereasoningSource区分explicit/role-default/none方便排查实际用了什么模型、什么推理强度、从哪来。配置示例在~/.codex/.omx-config.json或codexHomeOverride指向的配置目录中按 Agent 配置推理强度{ agentReasoning: { explore: low, code-reviewer: high, architect: xhigh } }运行时可借助诊断字段确认实际生效值例如通过团队运行时暴露的启动参数诊断actualModel、actualReasoning、modelSource、reasoningSource核对每个 worker 的最终推理强度。Team 精确 live-pane 权威#3153 / issue #3121特性含义#3153 让 Team 在施加显式生命周期效果lifecycle effects之前先验证精确的 live tmux 面板pane并在启动、扩容scaling、回滚rollback、恢复recovery与拆除teardown全过程中保持面板归属pane ownership。其配套保证包括成员变更与扩容事务持久化且失败原子durable and failure-atomic拆除/恢复权威可重放replayable通知派发绑定到所属 worker 面板的 PID。源码级实现证据精确面板证明exact pane proof实现在 src/team/exact-pane.tsexport type ExactPaneProof | { status: live; paneId: string; pid: number } | { status: gone; paneId: string; reason: absent | dead } | { status: unavailable; paneId: string; reason: invalid_pane_id | query_failed | malformed_snapshot | pane_pid_changed | pane_proof_lost_during_process_teardown | process_identity_unavailable; detail?: string };核心取证命令是tmux list-panes -a -F #{pane_id}\t#{pane_dead}\t#{pane_pid}即读取一次全局 tmux 面板快照解析每个面板的 ID、dead 标志与首个进程 PID面板 ID 必须匹配精确模式^%[0-9]$否则判定invalid_pane_id快照字段数、ID 合法性、dead 标志取值、PID 正整数性任一不满足即判定malformed_snapshot目标面板缺失判定gone/absentdead 标志非 0 判定gone/dead仅当面板存活且 PID 可解析时判定live。值得注意的是批量取证函数readExactPaneProofsSync在拓扑变更批次之前用同一次全局快照证明所有目标面板避免后一个目标使前一个授权失效one later target cannot invalidate an earlier authorization。这与失败原子、可重放的事务语义互为表里——先取证、后变更、按批次统一授权。团队运行时的对应测试位于 src/team/tests/tmux-source-authority-realtmux.test.ts 与 src/team/tests/runtime.test.ts。Ralplan 评审完整性严格评审顺序、Leader 证明与 PreToolUse 断言#3186 / #3196 / #3187 / #3218特性含义本组 PR 一起收紧了规划工作流Ralplan中的歧义权威ambiguous-authority与 live 执行回退live-exec regression路径Ralplan 要求严格的直接评审顺序strict direct review order评审链路不可跳跃当 Leader 证明未被文档化时流程失败关闭fails closed在PreToolUse中断言已对账的 Leaderattests the reconciled leader通过结构化解析协作结果parsing collaboration results structurally修复 App 侧的 Leader 证明回归。源码级实现证据失败关闭的 PreToolUsesrc/ralplan/documented-leader-preflight.ts 实现了文档化 Leader 证明的前置检查export const UNSUPPORTED_DOCUMENTED_LEADER_PROOF unsupported_documented_leader_proof as const; export const UNSUPPORTED_DOCUMENTED_LEADER_PRE_TOOL_USE Object.freeze({ hookSpecificOutput: Object.freeze({ hookEventName: PreToolUse, permissionDecision: deny, permissionDecisionReason: unsupported_documented_leader_proof: Codex hooks do not expose a documented, non-user-mintable root identity required for adapted Ralplan., }), });parseCodex01445AdaptedRoleIntentCommand精确匹配omx ralplan role-intent write --role role --parent-thread thread-id --json形式的命令--parent-thread使用$CODEX_THREAD_ID占位符只有命中该形态的 Bash 命令才会触发角色意图的PreToolUse评估。若角色已安装则拒绝为unsupported_documented_leader_proof若角色未知则拒绝为Ralplan role-intent denied: unknown_role——两种情况都 fail-closed。ADR 3212 的现状语义发布说明中的Current status / supersession (ADR 3212)信息块与本仓库 docs/adr/3194-codex-01445-documented-leader-proof.md、docs/adr/3212-same-user-native-child-auth-boundary.md 相关联。核心语义为本地 Leader 断言与适配的角色意图adapted role intent不再授权类型化路由/追踪器证据仅作生命周期/诊断用途在role_routing_unavailable状态下适配 Ralplan 的权威尝试会以unsupported_documented_leader_proof失败关闭缺少官方主机回执时documented_host_consensus_receipt_unavailable意味着共识不可用。Leader 契约中的退化指导块src/leader/contract.ts明确写入原生角色路由不可用时不要伪造agent_type、不要用适配角色意图/任务名载体/标记/提示标签作为权威当请求适配 Ralplan 权威时应运行omx ralplan preflight --json并在出现unsupported_documented_leader_proof时停止。协作结果的结构化解析通过结构化解析协作结果修复 App Leader 证明回归对应 src/leader/contract.ts 中的原生协作工具名规范化逻辑Codex CLI 可能把点号命名空间拍平如collaboration.spawn_agent到达时变成collaborationspawn_agentcanonicalizeNativeCollaborationToolName会把已知的拍平名称恢复为规范点号形式使 spawn/result 识别、能力检测都基于同一规范名未知的拍平名称原样透传并保持失败关闭。与之配套的 Ralplan 咨询advisory流程实现在 src/ralplan/advisory.ts关闭结案closeout以 fence 状态机pending_closeout → recovery_required / closed / abandoned与带 SHA-256 链的事件文件推进任何一步后置条件不满足都会拒绝终态证据摘要不一致时转入recovery_required。Team 邮箱与会话恢复唤醒合并与精确指针锁恢复#3217 / #3215特性含义#3217邮箱唤醒mailbox wakeups被合并coalesced并且每次唤醒都被确认every wake acknowledged避免同一时钟 tick 内并发路径排队多个唤醒导致重复唤醒#3215增加精确会话指针锁恢复exact session pointer lock recovery修复 issue #3203。源码级实现证据邮箱消息模型在 src/team/state/mailbox.tsTeamMailboxMessage携带message_id、from_worker、to_worker、body、created_at以及可选的notified_at、delivered_at。sendDirectMessage在持锁状态下做去重对同一发送者、同一接收者、相同正文、未投递且属于当前团队的候选消息直接复用不重复落盘随后通过markMessageNotified与markMessageDelivered更新通知/投递时间戳。投递与创建事件同时写入团队交付日志appendTeamDeliveryLogForCwd便于事后审计。唤醒合并wake coalescing的行为有专门测试覆盖src/team/tests/api-interop.test.tskeeps one mailbox wake pending until every queued message is acknowledged并发入队多个唤醒请求时后续请求被去重deduped: true并复用同一个request_id只有当队列中的每条消息都被确认投递后该唤醒才转为delivered测试还验证了preserves direct and broadcast mailbox messages while coalescing their outstanding wakesrc/team/tests/mcp-comm.test.ts即直发与广播消息在唤醒合并期间均被保留。原生 hook 与配置安全写入身份加固与幂等配置生成#3135 / #3201#3135原生子进程写入身份native child write identity在原生 hook、code-intel 与 wiki MCP 三个面上被统一加固对应 issue #3127#3201配置生成器对重复的项目信任表做幂等对账reconciles duplicate project trust tables idempotently对应 issue #3199。相关实现可在 src/scripts/codex-native-hook.ts 与 src/config/generator.ts 中继续追踪幂等对账意味着多次运行配置生成不会累积重复的信任表条目。插件与平台健壮性超大载荷结构化响应与 fsync EPERM 容错#3211 / #3191#3211插件原生 hook 对超大工具 hook 载荷oversized tool-hook payloads返回结构化响应而不是让上游得到不可解析的失败#3191在 Windows 上对常规文件fsync的EPERM予以容忍覆盖 hooks、卸载uninstall与原生 hook 三个路径。EPERM容错在仓库中的落点可参考 src/utils/file-durability.ts 及其测试 src/utils/tests/file-durability.test.ts以及 src/cli/uninstall.ts 等使用方对某些平台如 Windows 文件系统语义不允许对常规文件执行fsync的场景将其视为可忽略而非致命错误。其他修复隔离标准启动的文档化#3192#3192 在 CLI 与 README 两处补充了隔离标准启动isolated standard launches的说明。用户可参考 README.md 与 src/cli/index.ts 中的 CLI 帮助文本了解具体用法。发布盘点合并 PR 清单与可复现命令13 个合并产品 PR 为 #3135、#3143、#3153、#3186、#3187、#3191、#3192、#3196、#3201、#3211、#3215、#3217、#3218关联 issue #3121、#3127、#3181、#3194、#3195、#3199、#3203、#3204 不是额外 PR。范围中的其余提交是 PR #3153、#3196、#3215、#3217、#3218 的 squash 组成。在克隆仓库后可用以下命令复现完整提交清单git log --reverse --format%H%x09%s v0.20.2..f967cfed64ec57614af136f75d7cb81509808f7e完整的提交级分类见artifacts/release-0.20.3/inventory.md发布配套资产不在本仓库 docs 目录内以发布时为准。验证与发布就绪记录发布就绪记录 docs/qa/release-readiness-0.20.3.md 记录了如下本地门禁证据采集于 2026-07-19门禁证据配套/范围审查冻结 99 提交范围、13 个合并 PR、分类、亮点、贡献者与 compare 链接在CHANGELOG.md、release notes、RELEASE_BODY.md与记录间一致发布范围审查候选即dev尖端f967cfedrelease-prep 仅增加 4 个发布配套文件与冻结范围清单资产无产品运行时代码/依赖/lockfile/工作流改动package.json与Cargo.toml版本元数据为0.20.3本地静态门禁npm ci、npm run build、npm run lint753 文件、npm run verify:plugin-bundle29 个规范 skill 目录、npm run verify:native-agents22 个原生 Agent、37 个 setup 提示资产全部通过本地 Node 测试npm run test:nodeautopilot 套件 25/25首轮发现的 ralplan-gate 诊断措辞回归已由 #3218 上游修复无本地测试改动带入发布已记录的已知缺口均为环境/平台门控套件uninstall.test.tsmacOS 路径/语法模拟用例、codex-native-hook.test.ts与smoke-packed-install.test.tslive-CLI/版本边界、team/__tests__/runtime.test.ts与scaling.test.tstmux 时序敏感超出本地墙钟预算——这些在 v0.20.2 基线同样失败并非 0.20.3 回归且以 Linux CI 边界为准。发布序列遵循 RELEASE_PROTOCOL.md 第 5 节推送候选配套提交到dev→ 经 CI 提升到main→ 创建并推送注解v0.20.3标签触发发布工作流原生构建、资产发布/验证、packed-install smoke、npm 发布→ 验证非草稿 GitHub release 与npm view oh-my-codex version 0.20.3→dev快进到已发布main提交 → 将dev元数据提升到下一个开发基版本0.20.4。兼容性与升级建议0.20.3 是无有意破坏性变更的补丁发布CLI 与包布局保持不变唯一特性 #3143 为加法式、向后兼容。对已运行 0.20.2 的用户升级到 0.20.3 无需迁移 CLI 用法新特性只需在团队模型契约中按 Agent 配置model_reasoning_effort上限即可生效。对使用 Ralplan 的团队请留意 ADR 3212 的语义收紧本地 Leader 断言不再授权需要确保规划工作流运行在具备已安装类型化agent_type路由或经评审的替代工作流的表面上否则在role_routing_unavailable状态下会以unsupported_documented_leader_proof失败关闭——这正是该版本把歧义权威从流程中移除的预期结果。【免费下载链接】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），仅供参考