【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载在 opencodex 的 multi-agent 场景中当 native 父代理如 gpt-5.6-sol通过 V2 协议向 routed 子代理如 xai/grok-4.5下发任务时NEW_TASK 消息会以「可读信封 空Payload: 纯 Fernetencrypted_content」的形态到达代理层导致子代理完全收不到任务正文。本文基于仓库内 RCA 记录 007_rca_v_v2_encrypted_newtask.md 展开结合 encrypted-payload.ts、parser-content.ts、parser.ts 等源码与 multi-agent-compat.test.ts 测试完整梳理三种载荷形态的处理差异、解密能力边界、upstream 追踪状态并给出「责任UPSTREAM、无功能性本地补丁」的最终判定及本地 UX 缓解优先级。读完你可以掌握V2 子代理任务在代理层被静默吞掉的底层机制、为什么任何本地实现都无法解密而只能判定为上游缺陷、以及排查与规避该问题的正确姿势。一、症状跨 Provider V2 spawn 的「诞生即失明」复现链路是 opencodex 最典型的跨提供商编排场景父代理native 链路如 gpt-5.6-sol子代理routed 链路如 xai/grok-4.5经 opencodex 路由转发。当父代理通过 V2 协议 spawn 子代理时携带任务正文的NEW_TASKagent_message 到达 opencodex 时呈现为可读的路由信封routing envelopeMessage Type: NEW_TASK、Task name、Sender等头部空的Payload:行纯 Fernet 密文encrypted_content槽位。此时 sanitizer 的rewritten: 0—— 即没有任何明文槽位被重写恢复任务正文对子代理完全不可见。复现证据状态代码级已证明端到端未验证需要严格区分两个事实层级端到端本地复现本 RCA 未附带可复现的命令行与 fixture 捕获症状描述以上游 issue #92 的 maintainer 评论现 dev 基线状态更新为依据标为unverified纯 Fernet 路径的代码行为由单元测试 multi-agent-compat.test.ts 证明——纯 Fernet 槽位被byte-identical 保留对应sanitizeEncryptedContentInPlace返回 0parser 侧因 inputContentParts 对encrypted_content类型没有处理分支而静默跳过。因此 031 门禁证据由「代码证明 upstream issue 处于 open 状态」两者共同支撑而非本地 e2e 截图。二、三种载荷形态与当前处理只有纯 Fernet 不可恢复RCA 将加密槽位中的载荷划分为三种形态处理结果截然不同。原文档给出的对照表结合源码函数名与测试用例补充形态处理逻辑结果纯明文落在 encrypted 槽位ciphertext 启发式不通过→ 还原为input_text整条明文 agent_message 归一化为 user 消息可恢复对应sanitizeEncryptedContentInPlace的 plaintext 还原路径明文前言 Fernet 混合命中FERNET_TOKEN_RUN→ 明文进input_text、Fernet 段原样保留仅传递明文前言Fernet 段继续作为encrypted_content保留纯 FernetlooksLikeBackendCiphertext通过→ byte-identical 保留不可恢复底层实现sanitize 如何区分三类载荷核心逻辑集中在 encrypted-payload.ts 的 sanitizeEncryptedContentInPlace遍历请求input数组遇到encrypted_content槽位时先做密钥无关的 Fernet 结构验证isStructurallyValidFernetToken长度 ≥ 100、base64url 字符集、padding 合法、解码后首字节为版本字节0x80、AES-CBC 密文长度 ≥ 16 且为 16 的整数倍若验证通过looksLikeBackendCiphertext返回 true→ 视为真实后端密文绝不触碰byte-identical 保留这正是rewritten: 0的来源若验证不通过明文或畸形内容→ 调用 encryptedSlotParts 把前后明文拆成input_textFernet run 仍保留为encrypted_contentrewritten计数 1若一条agent_message被重写后不再含任何encrypted_content槽位则降级为message/user角色避免把子代理私有消息留在面向普通模型的 wire 上。这一设计刻意不给任何长 base64 样式的模型输出授予密文权限例如 SHA-256 摘要恰好是 64 个[A-Za-z0-9]字符若用宽松字符类判断就会把子代理故意打印的摘要误当密文替换掉。因此判断基准是「Fernet wire 结构」而非「看起来像密文」。路由前的执行时机在 request-prepare.ts请求在路由前即对 raw body 执行sanitizeEncryptedContentInPlace(..., { preserveUnknownOpaqueSlots: true })由于最终目的地尚未确定编码样式未知的槽位先保持不透明留待最终路由处理时再决定剥离或严格分类。若rewritten 0会打印一条结构化警告[opencodex] rewrote N plaintext encrypted_content part(s) to input_text (spawn-message compatibility)测试侧multi-agent-compat.test.ts 为这三种形态分别固化了断言明文驻留 encrypted 槽 → 重写为input_text真实 Fernet blob 不受影响混合槽如[CXC-LEAF-GUARD]控制前言 内嵌 Fernet 任务→ 拆分为input_textencrypted_content两部分纯 Fernet 槽 →sanitizeEncryptedContentInPlace返回 0内容 byte-identical 保留这是本 RCA 中「不可恢复」结论的代码级证据。另有 spawn 消息投递测试sanitize-then-parse delivers the spawn task payload as a user message on routed paths验证「明文槽被 sanitize 重写后解析器能把任务正文作为 user 消息交给子代理」——即本地能修复的只有前两种形态。三、子代理实际收到什么parser 的静默跳过即便路由成功子代理侧收到的任务也会在解析层丢失。两个关键位置1.function_call_output中的密文 → 统一替换为占位标记outputToToolResultContent 在处理工具输出时遇到encrypted_content类型对应 codex-rs 的FunctionCallOutputContentItem::EncryptedContent直接输出文本标记[encrypted content omitted]见 parser-content.ts——对 routed 模型而言密文是不透明的。2.agent_messageV2 NEW_TASK中的密文 → 静默丢弃inputContentParts 只识别七种块类型input_text、text、input_image、input_video、input_audio、input_file没有encrypted_content分支。于是 parser.ts 在处理agent_message时inputContentParts(agentMessage.content)对纯密文返回空结果最终降级为占位文本(sub-agent message received)parser.ts——子代理收到一条「空消息」任务正文消失得无影无踪。值得注意这个跳过是静默的不抛错、不报错这正是本 RCA 建议本地增加「显式兼容性错误」的原因——防止子代理在缺少任务正文的情况下产生幻觉式输出。四、为什么任何本地实现都无法解密密钥不在代理层解密边界分析是本 RCA 最硬核的部分结论是密钥不存在于 opencodex 侧Fernet wire 结构版本字节1 时间戳8 IV16 AES-CBC 密文16×n HMAC32。isStructurallyValidFernetToken只能做密钥无关的结构验证无法验证真实性HMAC 需要密钥设计源头upstream openai/codex#262102026-06-05 merge明确划分了边界——Responses 后端负责加密 V2 message 工具参数Codex 只传递并保留密文InterAgentCommunication.content有意保持空字符串源码中String::new()已确认存在解密能力只存在于 OpenAI Responses 后端/会话安全上下文中本地 CLI 与 opencodex 代理均无。因此文档明确日志记录、正则表达式提取、「compat decrypt」标志位任何一条路径都不可能恢复任务正文——密文的唯一明文副本在请求到达代理之前就已消失。五、Upstream 状态追踪2026-07-22 源码开放核实RCA 以源码开放核实的口径梳理了相关 upstream issueIssue状态与本问题关系openai/codex#335512026-07-16 open未分配无修复完全匹配外部 provider 无法解密 V2agent_message.encrypted_content建议 provider-aware 明文传输。这是追踪对象#26210已 merge设计起源引入 V2 加密任务传递机制的原始设计#28058open确认 V2 通信以空 content 存储#26753not planned 关闭OpenAI 方明确 V2 仍在开发中、暂不建议使用workaround 是退回 V1#32453无关更正issue #92 评论中链接的 #32453 实际是模型切换后的 429 compaction 问题不是追踪对象另外2026-07-22 前后0.144.4的发布说明中没有provider-aware 相关修复no user-facing changes意味着短期内该问题不会由上游版本线自然修复。六、责任判定UPSTREAM以及为什么不是 mixed最终判定为UPSTREAM理由链如下唯一的明文副本在到达代理前就消失了——无论本地怎么实现都拿不到原始任务正文现有本地缓解明文/混合形态恢复是正确的应当保留对应sanitizeEncryptedContentInPlace的前两条路径及其测试本地责任仅限 UX 范畴可以把「静默任务丢失」改为「显式兼容性错误」但这属于体验改善而非功能修复不足以构成 mixed 责任判定。一句话概括判定逻辑UPSTREAM不等于「本地无事可做」而是「本地无法从根上修复只能做边界内的防御与提示」。七、本地缓解优先级与取舍031 输入RCA 给出了清晰的缓解优先级排序并逐条论证了否决项可执行项V1 指导已实现—— 唯一能完整保留任务传递的路径。仓库侧证据README.md 的 Sub-agents on any model 描述v1/v2 surface control 与 fallback chains、ocx v2CLI 的多代理表面控制命令README.md以及 collaboration.ts 中collabSurface对 v1/v2 表面的判定逻辑spawn_agent是否带 namespace、send_input/resume_agent/close_agent属 v1、send_message/followup_task/interrupt_agent/list_agents属 v2。fail-fast可执行的诊断缓解—— 检测到「routed 模型 纯 Fernet agent_message 空Payload:」组合时返回含 V1 建议的显式兼容性错误。这不是任务恢复而是防止幻觉让子代理明确知道没有拿到任务而不是假装收到一条空消息继续编造。警告/遥测——v2_cross_provider_encrypted_task_unreadable结构化日志。较弱但对诊断分布有帮助。明确否决项父侧明文重传不可行——send_message/followup_task走的是同一套加密机制重传仍是密文compat decrypt 标志不可行——代理看到密文时明文早已消失too late自动 V2→V1 降级当前不可行——协议模式植根于客户端状态工具集与 spawn 形态由 Codex 客户端决定代理无法单方面降级。源码中的局部防御可佐证 fail-fast 思路从源码结构看代理层已在组合combo与请求准备阶段落了一部分防御core-combo.ts 中当检测到不可读加密 agent taskhasUnreadableEncryptedAgentTask时combo 目标筛选器会要求目标必须是canonical OpenAI forward providercanDecryptUnreadableAgentTask才有资格承接该请求——即只有原生 OpenAI 链路才允许接收密文任务第三方 provider 会被排除在候选之外避免把不可读任务发给注定无法理解它的模型。八、处置结论031 输入最终处置文档应明确标注为no-functional-patch / upstream-tracking 结论责任归属upstreamopenai/codex#33551注意不是#32453功能性本地 diff无追踪策略upstream 若引入「明文保持」或「provider-aware 传递」再重新测试本路径可选动作单独、窄范围的 fail-fast UX 补丁返回含 V1 建议的兼容性错误但不得表述为「任务传递修复」绝对禁止添加解密器、Fernet→文本重写、全局移除 ciphertext——这些都会破坏 native replay密文在原生会话回放中承担真实性证明职责见 encrypted-payload.ts 对 replay history 的论述。附关键代码路径速查继续深入排查时可优先阅读以下文件密文分类与 sanitize 核心src/server/responses/encrypted-payload.ts请求路由前 sanitize 时机src/server/responses/request-prepare.tscombo 目标对密文任务的资格筛选src/server/responses/core-combo.ts解析层静默跳过与占位标记src/responses/parser-content.ts、src/responses/parser.tsv1/v2 协作表面判定与指导注入src/server/responses/collaboration.ts三种载荷形态的固化测试tests/codex-integration/multi-agent-compat.test.ts赞分享【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载相关推荐OpenCodex 文档修复实践npm --allow-scriptsbun 安装恢复命令与 v2 跨模型子代理 NEW_TASK 加密限制Issue 146 / 92OpenCodex 文档修复实践npm allow scriptsbun 安装恢复命令与 v2 跨模型子代理 NEW_TASK 加密限制Issue 146Kedro 安全模型深度解析代码与数据的信任边界、扩展点责任与漏洞判定Kedro 安全模型深度解析代码与数据的信任边界、扩展点责任与漏洞判定 导读 本文以 Kedro 官方安全模型文档 security_model.md ht数据工程工作流自动化三步快速获取国家中小学智慧教育平台电子课本PDF的实用工具三步快速获取国家中小学智慧教育平台电子课本PDF的实用工具 tchMaterial parser 是一个专门为教育工作者设计的 电子课本解析工具 它能将国家中网页爬虫教育上一篇终极NW.js示例应用大全快速上手桌面应用开发下一篇如何快速上手 Stable Diffusion零基础 AI 绘图开源项目完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
