Codex 子代理提示词加密：HN 425 分事件梳理

TL;DR2026 年 7 月中旬，社区发现 Codex 开始加密发给子代理的提示词，HN 讨论 425 分。这篇梳理事件与争议焦点，并给出普通用户的三条边界：日常使用基本无感，调试子代理不再透明，安全审计的黑盒度上升。

来源信号 SOURCES

以下内容整理自社区公开讨论，本页只做拆解与核实，不搬运原帖；观点归属原作者。

这些是讨论中被多方印证、或可对照官方文档核实的事实。

2026-07-14 前后，openai/codex 仓库出现 issue「Codex starts encrypting sub-agent prompts」，HN 同题讨论拿到 425 分、249 条评论——热度说明这不是普通的工程细节变更。
事件核心现象：Codex 开始对发给子代理（sub-agent）的提示词做加密处理，外部不再能直接读出子代理收到的完整内容。
该事件已列入本站已知事件档案，与日志疑似写爆 SSD（HN 510 分）、自行绕过 sudo（HN 664 分）同属 2026 年中社区对代理行为边界的集中审视。
加密的实现细节、动机与覆盖范围，以 issue 后续更新与官方文档为准；本篇不替官方解释动机。

社区讨论里的概念不全是事实——每条都标注了它的性质，读之前先看标签。

子代理（sub-agent）已验证事实

由主代理派生、拥有独立上下文的代理实例，常用于并行探索或隔离执行。子代理机制是 Codex 处理复杂任务的基础能力之一。

提示词加密已验证事实

本事件中指子代理收到的提示词内容对外呈现为加密形态。事件本身可核实；至于加密覆盖哪些字段、出于什么考虑，以官方后续说明为准。

可观测性（observability）个人观点

能否看到代理实际收到与发出的内容。加密直接压缩了这一维度：你仍能看到任务结果，但看不到中间的完整指令——这也是讨论区情绪集中的原因，属于对社区立场的概括。

黑盒度上升的取舍个人观点

加密可能带来防提取、防篡改等收益，代价是调试与审计变难。这笔账怎么算，取决于你用 Codex 做的事有多依赖中间可见性——个人判断。

事件时间线很简单：7 月中旬 issue 出现，HN 讨论随后拿到 425 分、249 条评论。真正值得展开的是讨论的分层：工程师关心「我还怎么调试子代理」，安全视角关心「不可读是否等于不可审计」，普通用户大多在问「我要不要做什么」。三个层次各有各的答案。

对普通用户：日常任务的表现基本不受影响，不需要因为这条新闻改变任何设置。对重度用户：如果你此前的调试流程依赖直接读子代理提示词，需要转向官方提供的观察面（日志与追踪能力，以当前版本文档为准）。对安全团队：把「中间过程不可读」纳入威胁建模的新前提。

跟踪建议：关注原 issue 与官方 release notes 的后续，不要从单条 issue 过度推理动机——把「为什么加密」留给官方说清楚，是读这类事件的基本纪律。想看它在本站事件序列里的位置，见事件与重置档案。

想知道今天的重置判定？回到首页实时雷达。