截至 2026 年 11 月 4 日，OpenAI 没有确认 Codex 的 “Improve the model for everyone” 为什么会被重新打开。Hacker News 上有多人报告遇到过这件事，帖子里引用的上一次报告发生在 9 月 10 日。能确认的是，个人账号里的这个开关，不是设完就能忘的组织策略；团队需要一套可重复的检查。
如果你用个人 ChatGPT 账号跑 Codex，或者团队没有统一工作区、成员各用各的账号，这篇对你最直接。本文只讨论训练数据共享，不讨论聊天历史、滥用监控和 API 留存，它们是不同的开关。
先给结论：先查账号类型，再查开关状态，最后查证据链。不要把 “我看到是关的” 当成控制措施。
用户报告了什么
11 月 3 日的帖子（HN 50352757，2026 年 11 月 4 日抓取时 443 分）里，发帖者说公司很在意 IP 泄露，团队一直关闭 Codex 和 Claude Code 的数据共享。但前一天，他和同事发现 Codex 的设置被重新打开，没有人主动重新选择。帖子给出的检查路径是 chatgpt.com/settings/data-controls，找 “Improve the model for everyone”；另一个入口是 privacy.openai.com。
这不是第一次。发帖者引用了 9 月 10 日的另一个帖子（HN 49643556，487 分）。发帖人 jacquesm 说自己重置过不止一次，最后一次特意记了时间，再检查时发现又被打开。
评论区有人说自己也遇到，也有人说刚检查过仍是关闭。没有人给出复现步骤，OpenAI 也没有公开说明原因。所以这仍然是一组用户报告，不能写成 “OpenAI 已经承认偷偷训练”。客户端更新、账号迁移、bug，甚至看错工作区，都可能造成同样的现象。文章后面只处理可验证的部分。
这个开关控制什么
Codex 没有单独的隐私开关。官方登录文档写得很清楚：用 ChatGPT 登录，Codex 的使用跟随当前 ChatGPT 工作区的权限、RBAC、留存和驻留设置；用 API key 登录，就跟随 API 组织的留存和数据共享设置。
对个人账号，Improve the model for everyone 控制的是你的内容能不能被用于改进模型。OpenAI 的帮助文档把它和聊天历史分开：可以保留历史，同时关闭模型训练。反过来，关闭训练也不等于删除历史，更不等于零留存。滥用监控、法律保全和第三方插件各有自己的规则。
Business、Enterprise 和 Edu 工作区不一样。OpenAI 的Work 安全文档写明，这些工作区的业务数据默认不用于训练模型，传输和静态加密也覆盖三档。但审计日志、Compliance API 和自定义 RBAC 只面向 Enterprise/Edu；Business 采购时要单独确认审计覆盖。API 也默认不用 API 数据训练，Codex 定价页把这条列为默认能力。
这就是最容易混淆的地方：公司买了企业版，不代表员工个人账号里的 Codex 自动受保护；个人账号的开关也不会变成组织策略。采购时要按 “谁在哪个账号、用哪种登录方式、处理哪类数据” 分开看。
为什么会变回去
官方文档没有列出 “哪些操作会重置这个开关”。截至 11 月 4 日，也没有看到 OpenAI 对这次报告的原因说明。能确认的只有一件事：数据策略跟着登录方式和工作区走。管理员可以用 forced_login_method = "chatgpt" 和 forced_chatgpt_workspace_id 限制成员只能登录指定工作区。
所以，切换账号、切换工作区、从 API key 改成 ChatGPT 登录，都会换一套适用策略。它看起来像 “开关被改了”，也可能只是你正在看另一个账号的设置。客户端更新、重新登录、合并工作区会不会把开关重置成开，文档没有写，标为待核实。
审计也没有想象中完整。当前的 Compliance API 文档和治理文档里，我能找到的 Codex 记录类型是 conversation_message 和 codex_log，没有找到 “训练开关变更” 这一类事件。Enterprise/Edu 的审计日志不能假定覆盖每一次个人设置变化；Business 不要默认有这条日志。采购时要把这个问题写进合同或安全问卷，不要靠口头承诺。
一套可验证的团队检查流程
第一步，列账号。把 ChatGPT 个人版、Business/Enterprise 工作区、Codex 桌面端、CLI、IDE、API key、Bedrock 或网关逐项列出。每个入口记录：账号邮箱、工作区、登录方式、谁在用、会放什么数据。凡是拿个人账号处理公司代码的，先标成 “不受控”。
第二步，查状态。打开 chatgpt.com/settings/data-controls，记录 Improve the model for everyone 的状态；再用 privacy.openai.com 交叉检查。历史记录开关单独记，不要混在一起。截图要带上账号菜单、工作区、日期和客户端版本，只截一个开关说明不了问题。
第三步，收口。公司代码只允许在受管工作区里跑，管理员强制登录方式和 workspace。API 工作流单独放在 API 组织里，签了 ZDR 才按 ZDR 设计。不要让成员在个人账号和企业工作区之间来回切。
第四步，定期验证。高敏感团队每周抽查一次；客户端更新、重新登录、换工作区、新人入职后各查一次。Enterprise 和 Edu 可以用 Compliance API 看活动，但 Compliance API 证明不了开关状态，别拿活动日志代替设置截图。analytics 能不能证明开关状态，文档没有写，标为待核实。如果想把这类检查扩到整个研发流程，可以顺着看关掉网页搜索，为什么拦不住 AI Agent 漏数据和Codex 团队工作流：一套配置，全组共用。
第五步，准备替代路径。合同要求 ZDR，就不要把希望放在一个网页开关上。API 有 API 的 ZDR；本地 Codex 可以走 Amazon Bedrock，官方文档写明这条路径不经过 OpenAI 托管的 Responses API，但 Bedrock 自己的留存条款仍要核对。自托管或组织网关也是同一逻辑：换的是数据路径，不是换个开关。
如果任务跑在 HiFox 这类平台上，至少可以把上下文清单写清楚。HiFox 文档列明，任务执行会把标题、描述、评论、空间、指令、技能、仓库、环境变量和密钥交给 Agent，运行结果写回同一个任务。采购时拿这张清单逐项问：发到哪个 Runtime、用谁的账号、日志留多久。文档没有写组织级训练开关，别默认它有。
发现被打开之后
先停。暂停这个账号上的敏感任务，不要再往里贴客户数据、密钥或未公开代码。
再留证。截设置页、账号菜单、工作区、时间和客户端版本，导出这段时间的会话或任务清单。没有账号信息的截图，事后无法证明是哪个工作区。
然后划范围。从上一次确认关闭的时间开始，列出碰过的仓库、密钥、客户数据和提示词。检查 API 用量、Git 提交、CI 日志和云环境密钥。别只查一个人的账号，同一批同事都要查。
接着处置。出现在提示词或仓库里的密钥要轮换；Codex access token 要撤销；云环境里的 secret 要重新核对。按公司安全流程通知安全和法务，不要自己判断要不要上报。
最后问厂商。提支持工单，问清楚四件事：开关什么时候变的、原因是什么、这段时间的数据有没有用于训练、能不能删除。不要期待当天有答案，但要保留工单号。
如果拿不到合同级保证，就把工作负载迁到有约束的路径，或者缩短检查周期。继续用不是不行，但不能假装风险已经消失。
三个坑
第一个坑，把关闭训练当成零留存。训练、历史保存、滥用监控、法律保全、第三方插件是五件事。关掉一个，不会自动关掉另外四个。
第二个坑，把个人设置当成组织策略。个人账号的开关只对那个账号有意义。Business、Enterprise、Edu 工作区的默认不训练，是工作区合同和设置带来的，不是员工手机里那个开关带来的。
第三个坑，只查自己。数据共享是账号级问题，泄露却是团队级后果。管理员要能回答：谁还在用个人账号、谁还在用 API key、谁最近换过工作区。
结论
这次事件到现在仍是用户报告，原因没有官方结论。它值得警惕的地方，不是某一个开关被打开，而是很多团队把 “设置过一次” 当成了控制。可验证的做法很朴素：账号清单、开关截图、强制工作区、异常后的处置。
今天花十分钟查一遍，比等一个解释更有用。下一步，把这项检查做成每周任务，负责人、截图和结论都留在任务里；需要 ZDR 的工作负载，先迁到有合同约束的路径，再谈开关。
HiFox
