拦截发生在请求进入模型之前，重试同一份上下文无效；多数人靠新开会话恢复，触发源大概率藏在被一起打包上行的上下文里。
Invalid prompt: your prompt was flagged as potentially violating our usage policy 拦下，重试同一份上下文无效，新开会话多数能恢复，OpenAI 暂未就此发布说明。社区汇总的反馈里，这轮拦截的特征相当一致：不是某类敏感提问被拒，而是日常的改代码、跑测试、读日志都可能中招，而且同一个会话一旦开始报错就会持续报错。报错文案末尾附的链接指向 OpenAI 的推理模型提示词建议文档，言下之意是"换个说法再试一次"，但被拦的人普遍表示自己并没有写什么需要换说法的东西。
这条报错对应的是 HTTP 400、invalid_request_error、错误码 invalid_prompt。三个字段合起来说明了一件事：请求在进入模型之前就被网关侧的内容分类器打回了，模型根本没开始推理。
这和平时见到的"模型生成了一段拒绝的话"是两回事，实际后果也不同。模型拒答时，换个措辞、补一句用途说明常常就过去了；请求层的拦截则是确定性的——同一份上下文重发十次，十次都是同样的 400，重试和排队都没有意义。这也解释了为什么不少人最初以为是网络抖动或者额度问题，反复重连之后才发现毫无变化。
关键在于，编码代理送去过审的"prompt"并不是你刚敲下的那一句话。Codex 每一轮上行的是一整包东西：系统提示、项目里的 AGENTS.md、此前的完整对话、它读进来的文件片段、执行命令后的终端输出、准备应用的 diff。会话越长、读过的文件越多，这一大坨文本里出现能触发分类器的片段的概率就越高——一段处理密码或密钥的代码、一份抓下来的网页正文、一段带脏话的报错日志，都可能是那个片段。
而这些内容一旦进了上下文，就会跟着之后每一轮重复上行。这正好对上了反馈里最典型的那个现象：会话前半段一切正常，从某一步开始就再也发不出去，连删掉最后一句提问都没用。新开会话之所以有效，不是因为清了什么缓存，而是把那段一直在陪跑的上下文丢掉了。（OpenAI 未公开具体判定规则，这一层属于从报错行为反推的推断。）
这个拦截器长期有误伤记录。openai/codex 仓库里的 #16907 开在 2026 年 4 月 6 日，报告版本 codex-cli 0.118.0，提交者明确写了与账号和 API 无关、重装也不解决，至今仍是 open；更早的 #7250、#12011 是同一句报错。另一条线索在 modelcontextprotocol/servers 的 #4031——GPT-5.5 走 Sequential Thinking 之后触发同样的拦截，看上去模型自己生成的中间步骤同样会被送去过审。
Invalid prompt: your prompt was flagged as potentially violating our usage policy.，HTTP 400，错误码 invalid_prompt所以真正反常的不是"会误判"，而是这次的密度：以往是零星个案，这次是同一时间段里一片人同时中招，而没人改过自己的用法。这种形态通常指向服务端的分类器阈值或版本发生了变动，而非客户端出了问题——在官方给出说明之前，这也只能算推测。
把两种场景摆在一起，这件事的分量就出来了。聊天窗口里被误判，代价是重写一句话；编码代理里被误判，代价是整条工作流停摆，而且系统不会告诉你是哪一段内容惹的祸——报错既不引用触发片段，也不给类别。这大概是出于防规避的考虑，但对按月付费的开发者来说，等于只能靠二分法删上下文去猜。
眼下能做的事有限，但顺序值得理清：先确认报错确实是 400 invalid_prompt，而不是 401/403/429——后面这几个是账号、权限或额度问题，和这轮拦截无关。确认之后，新开会话、缩小代理能读到的目录范围、把明显敏感的文件挪出工作区，是目前反馈里有效的几招；长会话养成主动压缩或重开的习惯，也能降低踩中的概率，这类日常配置在 Codex 稳定使用 那篇里有更细的整理。
还有一层容易混淆：由账号和出口环境引发的异常——登录被判 Unusual Activity、区域限制、连接频繁中断——和内容拦截是完全不同的两类问题，症状看着都是"用不了"，处理方式却南辕北辙。分不清的时候，先用 GPT / Codex IP 检测 把出口环境这一层排掉，再回头折腾上下文，能省掉不少无用功。