https://codexer.com/tags/memories/Recent content in Memories on CodexerHugozh-cnSun, 06 Sep 2026 09:00:00 +0800https://codexer.com/posts/2026-09-06-codex-memories-cross-provider-leak/Sun, 06 Sep 2026 09:00:00 +0800https://codexer.com/posts/2026-09-06-codex-memories-cross-provider-leak/<p>设想这样一个场景：你格外在意隐私，于是把 Codex 接到了一个跑在本地的模型上，所有对话都不出你的机器。你还顺手在配置里关掉了 analytics，把 OpenTelemetry 的 exporter 全部设成 none。你觉得自己已经把能关的都关了。可突然有一天，你收到了 OpenAI 发来的账户警告，说你「滥用」。你翻遍了所有通过 OpenAI 进行的对话，找不到任何能解释这条警告的内容。那 OpenAI 到底看到了什么？</p> <p>2026 年 8 月 30 日，一位安全研究者在 OpenAI 开源的 codex 仓库提交了一份数千字的 issue（编号 #41711），用一个精心设计的受控实验给出了答案：问题出在 Codex 的记忆功能（Memories）上。它在挑选「哪些历史对话值得生成记忆」时，并没有把「这段对话来自哪个模型供应商」纳入筛选条件。结果，你在本地模型下的聊天内容，可能被随后一次由 OpenAI 支撑的会话静默打包，发送到 chatgpt.com 的服务器。</p> <h2 id="一次受控实验把这条通道钉死了">一次受控实验，把这条通道钉死了</h2> <p>研究者没有停留在「感觉这里有隐患」的层面，而是做了一次干净的复现。他用的是 Windows 版的 Codex 二进制文件 0.150.0-alpha.12.2，在隔离的环境里开启 Memories，同时显式关掉 analytics 和所有 OpenTelemetry exporter。他构造了一段带有唯一「金丝雀」标记的合成对话，并把它的供应商标签设为非 OpenAI 的本地来源。</p> <p>随后，他触发了一次由 OpenAI 账户支撑的 Codex 会话。抓包结果非常直接：Codex 向 chatgpt.com/backend-api/codex/responses 发出了一帧 38,095 字节的 WebSocket 请求，其中 request_kind 明确写着 memory。请求里包含了五个被保留的源对话条目。服务端返回的记忆文本里，那些唯一金丝雀被原样复现了多次。这说明那一段「本地来源」的对话内容，确实被送到了 OpenAI，并被模型处理了。</p> <p>这段请求的细节也很能说明问题：31,000 字符的记忆指令，外加一个 3,817 字节的包装层，里面裹着 3,092 字节的源对话内容。服务端用模型 gpt-5.6-luna 处理，消耗了 7,337 个输入 token。换句话说，这不是一次「试探性连接」，而是一次真正的内容级处理。</p>