6 月 5 日，Reddit 的 r/codex、r/OpenAI 和 r/ChatGPT 出现多条 OpenAI / ChatGPT / Codex 账号被停用的反馈。当前可确认的是社区反馈密集出现，且部分用户称收到“误停用后恢复”的邮件；OpenAI 状态页尚未把它列为账号封禁事故。
社区反馈集中在 Codex 与付费账号
这轮反馈最密集的位置不是传统媒体，而是 Reddit 的 Codex 用户社区。多条帖子在 6 月 5 日集中出现，描述相似：账号被 deactivated、disabled 或 banned，邮件理由笼统，用户无法确认具体触发项。
受影响者的自述覆盖几类场景：Pro 账号、5x / 20x 额度账号、Business workspace、长期使用 Codex CLI 或相关开发工具的账号。也有用户称自己没有使用 VPN、没有共享账号，只是在多台电脑上使用 Codex 和 ChatGPT。
这些都是用户自述，不等同于独立统计。没有公开样本量、封禁比例、地区分布，也没有 OpenAI 对单个案例的核验说明。可以写成“集中反馈”，不能写成“OpenAI 已确认大规模误封”。
部分用户称账号已恢复，但订阅状态仍有争议
更值得关注的是后续状态。r/codex 中有用户称收到 OpenAI Support 邮件，内容是账号被错误停用，访问权限已恢复。另一些用户反馈账号恢复后降回免费版，或订阅权益没有立即恢复。
这说明两个问题。第一，至少有部分反馈者认为自己的案例不是正常风控封禁，而是误判。第二，即使账号恢复，订阅、额度、工作区和 Codex 任务状态可能仍需要单独处理。
这里仍有可信度边界：这些恢复邮件来自用户贴文，无法从公开渠道验证邮件真伪，也无法确认是否适用于整轮事件。
官方状态页没有列出“封禁事故”
截至本文写作时，OpenAI Status 的历史记录列出了 6 月 3 日 Codex、ChatGPT 和 Responses API 错误率升高，以及 6 月 4 日 Image API 401 错误等事件，但没有单独列出“账号封禁 / 误封 / deactivation”事故。
这并不证明没有问题。状态页通常覆盖服务可用性、错误率、登录和 API 故障，不一定覆盖账号风控误判。但它限制了报道口径：目前不能把这次事件写成 OpenAI 官方确认的全站事故。
OpenAI 的公开规则给出了一条解释线索
OpenAI 帮助中心的账号停用说明列出几类原因：违反使用政策、违反服务条款、安全风险或未完成身份验证。服务条款相关示例包括规避安全或访问限制、共享账号或 API key，以及以可能损害他人或破坏服务完整性的方式使用服务。
OpenAI 在社区安全文章中还解释过，平台会使用自动化检测系统在规模化场景下识别可疑活动，信号可能来自内容、行为模式、分类器、推理模型、哈希匹配、阻止列表和其他监控系统。一旦认定达到可封禁程度，可能立即撤销访问；用户可以申诉。
这能解释“为什么会有自动停用”，不能解释“6 月 5 日这些案例具体为什么被停用”。把 VPN、第三方客户端、多账号登录、Codex 高并发使用直接写成原因，证据不足。
对开发者的真实风险不是一次封号，而是账号成为开发环境入口
Codex 让 ChatGPT 账号从聊天入口变成开发入口。账号里可能绑定订阅、项目任务、代码代理、工作区、团队席位和历史上下文。一旦账号被停用，损失不只是无法打开 ChatGPT，还可能中断当天的开发流水线。
这也是这轮反馈在 Codex 社区发酵更快的原因。对开发者来说，账号风控的误判成本高于普通消费级聊天：它会把一个 SaaS 账号问题放大成工程交付问题。
现阶段更稳妥的做法是保留申诉邮件、账号 ID / 组织 ID、订阅账单、近期使用说明和关键任务记录。OpenAI 官方帮助中心建议通过停用通知邮件里的申诉链接，或使用申诉表单提交上下文。