【免费下载链接】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 仓库中devlog/_fin/260722_issue_bug_sweep/031_patch_v_upstream_tracking.md处置文档配合同目录007_rca_v_v2_encrypted_newtask.mdRCA 结论完整讲解 Codex 多智能体 V2 跨提供商路由场景下 NEW_TASK 任务负载因后端加密而不可读这一问题的根因、责任边界、现有本地防御机制的源码级实现以及如何建立 upstream 追踪契约与重试触发条件。读完本文你将掌握判断上游缺陷 vs 本地可修复缺陷的方法论、OpenCodex 对encrypted_content槽位的三类处置策略及其测试证据、以及 fail-fast 诊断改进的取舍边界。问题背景V2 跨提供商子代理任务为何会丢失OpenCodex 作为 OpenAI Codex 与 Claude Code 的统一提供商代理支持将任意 LLM 路由到 Codex CLI、App、SDK 与 Claude Code在多智能体场景中支持 native 父代理如 gpt-5.6-sol向 routed 子代理如 xai/grok-4.5发送 V2 任务。这里routed指请求经由 OpenCodex 转发到非 OpenAI 原生模型其底座是 Codex 的 V2 协作表面collaboration.spawn_agent、send_message、followup_task等命名空间工具。根据 007 RCA 文档 记录的症候对应 Issue #92native 父代理发起 V2 spawn 时子代理收到的 NEW_TASK 消息形如可读的封装头信封 空的Payload: 纯 Fernetencrypted_contentOpenCodex 的 sanitizer 改写计数为rewritten: 0即没有发生任何恢复子代理最终无法获得任务正文只能依据空内容继续执行。关键点在于这不是 OpenCodex 可以本地修复的功能性缺陷。RCA 判定责任完全在 upstreamopenai/codex——Responses 后端在生成 V2 任务时即对工具参数加密Codex 客户端只传递并保存密文InterAgentCommunication.content被有意置为String::new()当请求到达代理时唯一的明文副本已经不存在了。因此 031 文档的结论是显式的 no-functional-patch / upstream-tracking 结论文档不新增功能性的本地 diff转为追踪 upstream 修复。负载分类与现有处理三类槽位的三种命运007 RCA 文档给出了encrypted_content槽位在 OpenCodex 中的完整分类矩阵这是理解现有本地防御的核心。需要说明的是文档引用当时的src/server/responses.ts:300,313,350,373等行号而当前仓库中该文件已拆分为src/server/responses/*模块src/server/responses.ts 现为 AUTO-SPLIT 外观门面重新导出各模块实际实现集中在 src/server/responses/encrypted-payload.ts。负载形态现有处理结果纯明文存放在 encrypted 槽位ciphertext 启发式判定不通过looksLikeBackendCiphertext见 encrypted-payload.ts→ 恢复为input_text整条明文 agent_message 按 user message 归一化已恢复明文前言 Fernet 混合槽位FERNET_TOKEN_RUN切分 → 明文部分还原为input_textFernet 段原样保留仅明文前言被传递纯 Fernet通过looksLikeBackendCiphertext→ 字节级原样保留无法恢复这三条路径全部由 sanitizeEncryptedContentInPlace 驱动其核心判断函数 isStructurallyValidFernetToken 只做密钥无关的 Fernet 线格式校验base64url 编码、首字节0x80版本、version(1) timestamp(8) IV(16) AES-CBC 密文(16*n) HMAC(32)结构、密文长度按 16 字节对齐、且len 100 len % 4 0。之所以刻意只校验结构不校验真实性是因为未知的重放历史没有真实性证明——代码注释明确要求不能把任何长的 base64 形似文本都当成密文授予权威否则会误伤正常明文输出例如恰好 64 字符的 SHA-256 摘要、长密钥、相邻的短编码片段。routed 子代理实际收到什么在解析器里同样有据可查function_call_output中的encrypted_content被替换为[encrypted content omitted]占位标记见 src/responses/parser-content.ts对应FunctionCallOutputContentItem::EncryptedContent对 routed 模型不透明V2 NEW_TASKagent_message在 src/responses/parser.ts 中处理调用inputContentParts提取内容由于该函数对encrypted_content块没有分支见 src/responses/parser-content.ts纯密文任务被静默跳过当没有任何明文部分时兜底为(sub-agent message received)占位parser.ts。解密边界分析为什么本地无法修复031 文档明确给出了不能做的三件事及其理由这是理解本结论的技术前提添加解密器—— 不可行。Fernet 密钥存在于 OpenAI Responses 后端/会话安全上下文中本地 CLI 与代理均无密钥Fernet→文本重写—— 不可行。会破坏 native Responses replay已发布的密文字节必须保持原样以便重放全局移除 ciphertext—— 不可行。同样会摧毁 native replay 且无法恢复任务。upstream 的边界在设计源头上就已划定openai/codex 的 PR #262102026-06-05 合并明确了 Responses 后端对 V2 消息工具参数进行加密、Codex 仅传递与保留密文、InterAgentCommunication.content有意为空字符串。这也解释了 007 RCA 中唯一明文副本在代理看到请求前已消失的结论——任何本地实现都无法传递一个已经不存在的原稿。当前仓库的 encrypted-payload.ts 在注释中同样记录了这条边界Unknown replay history has no authenticity proof、后端铸造的密文串是 Fernet 令牌等并演化出更细的检测手段hasUnreadableEncryptedAgentTask仅检测尾部的 agent_message 是否完全不可读见 encrypted-payload.ts、stripAgentMessageCiphertextInPlace面向无法接受私有条目的目的地将密文替换为省略标记见 encrypted-payload.ts以及AGENT_MESSAGE_ROUTING_ENVELOPE封装头剥离正则encrypted-payload.ts。现有本地防御的测试证据本地防御并非无操作——它精确区分三种槽位并各自动作这在 tests/codex-integration/multi-agent-compat.test.ts 中有完整的单元测试证明注意 007/031 文档引用的旧行号:364,391,405已随文件演化以下为当前行号明文停放在加密槽位 → 恢复为 input_text真实密文 blob 存活测试用例[CXC-LEAF-GUARD] plain text with spaces被改写为input_text而 73 字节的 Fernet fixture 原样保留混合槽位hook 前言 内嵌 Fernet 任务→ 拆分为 text encrypted 两部分测试用例[CXC-LEAF-GUARD] follow the rules.前言行保留为input_textFernet 段作为encrypted_content保留纯 Fernet 槽位 → 字节级原样保留测试用例rewritten: 0这正是 007 文档中恢复不可行分支的直接证据sanitize-then-parse 端到端投递测试用例模拟handleResponses的顺序先 sanitize/归一化 raw input再parseRequest验证 routed 路径上子代理能收到 NEW_TASK 任务负载含Message Type: NEW_TASK封装头与明文任务正文。这套测试锁定的行为契约正是 031 文档所称现有本地防御充分且正确——它把可恢复的明文/混合槽位全部救回同时对纯后端密文保持字节一致绝不越界解密。追踪契约目标 issue、无关 issue 与重试触发条件031 文档的核心产出是一份精确的 upstream 追踪契约追踪对象openai/codex#33551截至 2026-07-22 为 open 状态、未分配。该 issue 请求 provider-aware 的明文传输即让外部提供商能够解密 V2 的agent_message.encrypted_content无关 issue#32453被明确排除——它是模型切换后的 429 compaction 问题Issue #92 评论区若链接了它如需更正只能通过评论进行外部状态变更需用户批准相关 upstream 状态链#26210 是加密设计原点#28058 确认了 V2 通信以空 content 存储#26753 被 close 为 not plannedOpenAI 侧建议 V2 开发中慎用、以 V1 作为 workaround0.144.4 版本无 provider-aware 修复no user-facing changes。重试触发条件满足其一即按 multi-agent-compat.test.ts 基准重新评估纯 Fernet 路径upstream 发布明文保留plaintext preservationupstream 发布provider-aware 传递provider-aware deliveryupstream 发布解密委托decryption delegation。本地复现状态方面端到端复现捕获标记为 unverified007 文档明确但代码证明单元测试与 upstream issue 开放状态共同构成 031 的 gate 证据——即单元测试证明纯 Fernet 路径字节一致保留 #33551 仍开放这两点即可支撑判定。可选的后续改进fail-fast UX 补丁需单独批准031 文档特别强调下述方案不是任务传递修复而是纯粹的诊断改进且不属于本结论文档的结论内容需要另行审批、并以独立的 decade 文档032升级触发条件routed 模型请求 agent_message为纯后端 ciphertext 无可读 Payload预期行为子代理不再在无任务情况下幻觉编造而是返回一条推荐使用 V1 的显式兼容性错误实现位置仅方向性src/server/responses.tssanitizer 附近当前对应 src/server/responses/encrypted-payload.ts在hasUnreadableEncryptedAgentTask检测之前或 parser 边界更弱的替代方案遥测发出v2_cross_provider_encrypted_task_unreadable结构化事件不包含密文作为静默丢失的观测手段。这与 007 RCA 的本地缓解优先级一致① V1 引导已实现README.md 文档化了子代理路由能力如 Sub-agents on any model —— feature routed models in Codexs sub-agent picker, with v1/v2 surfaces是唯一保留任务传递的路径② fail-fast 是可行的诊断缓解防止幻觉而非恢复任务③ 警告/遥测较弱但有用④⑤⑥ 分别否决了父侧明文重发send_message/followup_task 同样走加密机制、compat-decrypt 开关代理看到请求时已太晚、自动 V2→V1 降级模式根植于客户端状态当前不可行。接受标准与本处置文档的价值031 文档的接受标准清单如下责任判定与依据已文档化007 本文档追踪目标 issue 精确无误#33551而非 #32453后续upstream 发布说明监控——触发条件出现时重开测试周期。这份 no-functional-patch 结论文档在工程实践中的价值在于把看起来像缺陷、但实际无法本地修复的问题从无休止的本地打补丁循环中解放出来转化为精确的 upstream 追踪 受控的遥测观测 明确的恢复重试门。它对维护者和使用者的指导意义同样明确在使用 V2 跨提供商子代理时若子代理收到空任务请优先确认是否为纯 Fernet 密文场景并将影响上报至 upstream issue #33551在本地V1 表面multi_agent_v1命名空间 send_input仍是当前唯一能完整保留任务传递的路径。附源码与文档导航结论文档031_patch_v_upstream_tracking.mdRCA 文档007_rca_v_v2_encrypted_newtask.md加密负载处理实现src/server/responses/encrypted-payload.ts请求解析实现src/responses/parser.ts、src/responses/parser-content.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 V2 跨 Provider 子代理任务加密载荷丢失NEW_TASK encrypted_content根因分析与责任边界判定opencodex V2 跨 Provider 子代理任务加密载荷丢失NEW_TASK encrypted_content根因分析与责任边界判定 在 opeHyprnote行动项提取任务分配与责任追踪Hyprnote行动项提取任务分配与责任追踪 痛点会议行动项管理的困境 你是否经历过这样的场景会议结束后满屏的讨论要点和决策事项却难以快速识别出具体的AI 应用人工智能语音本地部署桌面应用音频opencodex 跨模型 spawn_agent 加密任务限制92文档真相对齐与上游 Issue 草稿opencodex 跨模型 spawn_agent 加密任务限制 92文档真相对齐与上游 Issue 草稿 导读 本文以 opencodex 仓库中关于创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考