developer 撞上 422、被拦的回答写成正常结束：两处都是标签写错了
v8.0.51 把 Codex 请求里的 system 写成 developer，接严格上游直接 422，而这条行为是被一条单测钉住的；同一版的 Antigravity→Claude 翻译器把 SAFETY 等八种拒答都译成 end_turn。两张补丁都还没进发行版，其中一张的评审里还挂着一条未闭合的 P1。
过去这一小时（北京 12:58–13:36）四个仓库都没发版：CLIProxyAPI 停在 v8.0.51，sub2api 0.2.19，codex-proxy v2.1.21，codex2api v3.1.2。主干上也没有新合并的提交。
CLIProxyAPI 的
HEAD、main 与 v8.0.51 指向同一个提交 7cad1cb7，dev 停在 06ec5eac，还是上期那个合并提交。窗口里的动作一共三条：一条报障、两张补丁。它们撞的是同一个毛病的两面——一个值被写成了另一个值。
请求里的一条消息带着
developer 这个角色出去，撞在上游的 422 上；回答里的一次拒答被写成 end_turn，客户端以为一切正常。developer 角色：一条单测把它钉住了，接严格上游直接 422
报障写得很具体：Codex 的
/v1/responses 经 openai-compatibility 转成 /chat/completions 之后，首条消息角色是 developer，DeepSeek 官方 API 回 HTTP 422。1报障贴出的上游原文是
messages[0].role: unknown variant 'developer'，它只认 system、user、assistant、tool、latest_reminder 五种。这个
developer 不是上游给的，是我们自己写出去的。v8.0.51 的 Codex→Chat 翻译器在拼消息时做了一次角色改写：源角色是 system，输出就写成 developer。
internal/translator/codex/openai/chat-completions/codex_openai_request.go 第 218–222 行：system 被改写成 developer，其余角色原样透传。更要紧的是它被一条测试钉住了。发行版里那条
TestOpenAICompatExecutorPreservesResponsesInstructionRoles 断言的八个角色里，有三处是 developer。
internal/runtime/executor/openai_compat_executor_roles_test.go 第 68 行，期望的角色序列里第 2、4、7 位都是 developer；函数名在第 18 行。所以这不是手滑，是被断言钉住的行为。想让它变回
system，得同时改代码和这条断言——补丁正是这么做的。报障给的归因只说对了一半
报障说这是 v8.0.51 才出现的回归，来自提交
00b76771。那笔提交确实存在，作者时间 2026-11-01T17:03:01Z，标题是「保留 responses 到 chat completions 的 developer 角色」。2它改的是另一条翻译路：
openai/openai/responses。在 v8.0.50 里，那条路会把 developer 降级成 user。
internal/translator/openai/openai/responses/openai_openai-responses_request.go 第 255–259 行：注释写着 developer 内容「以用户文本发出」，代码把角色改成 user；v8.0.51 里这两行已被删掉。v8.0.51 的发布时间是 17:08:04Z，比这笔提交晚五分钟。所以「OpenAI 格式的
/v1/responses 从 v8.0.51 起开始带 developer 出去」这个判断成立。但 Codex 那条路不是。我把 v8.0.33 与 v8.0.51 的同名翻译器整份比过：那段
system → developer 逐字节相同，两版只差 parallel_tool_calls 一行。走 Codex 格式的请求，在更早的版本上就已经带着 developer 出去了。这条修正直接影响处置：你那台如果跑的是 v8.0.50 或更早、客户端是 Codex，退回旧版本救不了 422，旧版本一样会撞。
反过来说，旧版本上用 OpenAI 格式客户端，问题不是 422，而是请求被降级成用户消息——指令优先级掉了，但不会被拒。
补丁：三条路径都覆盖，排在 payload 规则之前
从报障到补丁只隔 15 秒：报障 05:25:43Z，补丁 05:25:58Z。3
改法是在 OpenAI-compatible executor 的最终请求体上做一次归一化，插在三个位置：非流式
executeWithCredentials、流式 executeStreamWithCredentials、CountTokens。三处都排在
ApplyPayloadConfigWithRequest 与 NewPayloadFinalizer 之前。所以配置里的 payload 规则看到的，是改好之后的角色。实现是原位改写原始字节：按 gjson 给出的
role 字段偏移，把 "developer" 换成 "system"。偏移对不上、或替换区间越界，就整份返回原样。
internal/runtime/executor/helps/developer_role.go 第 26–58 行（fork 分支 Lingbou/CLIProxyAPI 的 fix/openai-compat-developer-role）：第 49 行是那段「偏移对不上就整份放弃」的判断。「整份放弃」是它的安全阀，也是它的软肋：真走到那一步，补丁一声不响地不生效，422 照旧。
补丁也不是一次写对的。机器评审在 05:28:28Z 抓到一条 P2：客户端若发转义写法
"\u0064eveloper"，gjson 解出来是 developer，但原字节比对不等，于是整份放弃。4作者两分钟后补了第二笔提交，把替换改成用 gjson 返回的原始 JSON 表示，并加了转义写法的用例。第二笔提交的时间是 05:30:41Z。
最终那条评审在 05:33:51Z 记
has_any_findings: false。补丁现在 open、mergeable clean、4 文件 +198/−2、两笔提交、无 draft。一个副作用要先说：补丁没有开关。合并之后，所有
openai-compatibility 上游收到的 developer 都会变成 system。如果你的链路需要
developer 语义——比如同一份请求之后还要转去 Codex——这一改会把它抹掉。反过来，因为归一化排在 payload 规则之前，合并后你仍可以用一条 override 把某个固定的位置改回 developer。今天能做什么
认：上游 422 的正文里出现
unknown variant 并点名 developer，同时这个上游是 openai-compatibility 配的。处置三条，按代价从小到大：
- 换一条接受
developer的上游，或把这个模型从这个 key 的模型白名单里摘掉。 - 等 #7194 合并进发行版。它不在 v8.0.51 里，也没有别的版本带上它。
- 自己打补丁，或照上面那条偏移判断自己写一版。
想用配置绕过去不现实。
payload 的 override 规则按 JSON 路径写，比如 messages.0.role；但一份请求里 developer 出现几处并不固定，发行版那条测试里就有三处。按索引写规则，只能挡住你确认过的那一种排布。Antigravity 的拒答：八种结束原因都被译成正常结束
第二处标签错位在出口侧。Antigravity 上游用
finishReason 说明这次生成为什么结束，翻译成 Claude 格式时要变成 stop_reason。v8.0.51 只认两种结局。
internal/translator/antigravity/claude/antigravity_claude_response.go 第 594–607 行：只处理 MAX_TOKENS 与 STOP、FINISH_REASON_UNSPECIFIED、UNKNOWN，其余全落到 end_turn。非流式第 827–842 行是同一套 switch 的第二份拷贝。于是这八种上游结局都被写成正常结束：
SAFETY、RECITATION、PROHIBITED_CONTENT、SPII、BLOCKLIST、IMAGE_SAFETY、MALFORMED_RESPONSE、MALFORMED_FUNCTION_CALL。不是没人知道这份名单。同一个仓库里，
antigravity → openai 那条翻译器早就按这八种判内容过滤。5
internal/translator/antigravity/openai/chat-completions/antigravity_openai_response.go 第 278 行调用 isAntigravityContentFilterFinishReason，名单在第 292 行；命中后写的是 OpenAI 侧的 content_filter。同一个值，走 OpenAI 那条路会标成
content_filter，走 Claude 这条路变成 end_turn。流式还有第二个小毛病：尾包里
finishReason 是空串时，会把前面已记下的值覆盖掉。第 477–482 行把值赋进去之前没有判空。客户端为什么看不出
所以「
end_turn 加空内容」不是可用判据：它既可能是模型自然说完，也可能是被安全策略拦下。这正是这个 bug 值钱的地方。预算上也不好看。补丁自带的用例里，被
SAFETY 拦下的那一次，上游仍报了 8149 个输入 token、输出 0——这段没生成的回答，输入照算。补丁带了一条还没闭合的 P1
refusal 是 Claude 的正式取值：表示模型拒绝生成，仍然是 HTTP 200，不是错误。但它顺手修的那个空值覆盖，带出一个新洞。机器评审在 05:29:57Z 给了一条 P1：原生 web 搜索流里，正文先被暂存在
WebSearchTextBuffer，只有 HasFinishReason 为真时才倒出来；新的空值保护让那条只带空 finishReason 的路径不再置位，[DONE] 那条分支又不做兜底，于是客户端拿到一段空回答。8最终评审记
has_any_findings: true、has_unresolved_findings: true。补丁现在 open，mergeable_state 标 unstable，unstable 的具体原因我没查。所以这条别整体照抄。要那八种映射可以，那条空值保护得连带处理缓冲区；作者还没回这条。
今天能做什么
认：上游返回的
finishReason 是这八个值之一，而下游 Claude 客户端显示 end_turn。这条只能从上游侧看，客户端自己分辨不出来。处置：等作者回那条 P1 再取补丁，或只取映射、不取空值保护。
盯：别把
end_turn 当健康信号，也别反过来把 end_turn 加空内容当成被拦——它本来就可能是正常空响应。三条条目现在什么状态
| 条目 | 改了什么 | 规模 | 状态 |
|---|---|---|---|
| #7193 | 报障：developer 撞严格上游 422 | 报障单，无补丁 | open、0 评论、无标签 |
| #7194 | developer → system，三条路径 | 4 文件 +198/−2、2 提交 | open、mergeable clean、评审无 finding |
| #7192 | 八种拒答 → refusal | 2 文件 +171/−22、1 提交 | open、unstable、1 条 P1 未闭合 |
上期那两张（#7190 读 OpenRouter 日限重置时刻、#7191 补刷新令牌过期的终局措辞）窗口内仍是 open、clean、各 1 提交，没有新动作。
两张新补丁都基于
dev，都没合并，也都不在 v8.0.51 里。今天能升到的最新版就是 v8.0.51，而这两处它都没修。能动的只有上游与模型白名单；剩下的动作是等，或者自己打。
今晚三步
认：422 看上游正文有没有
unknown variant；拒答看上游 finishReason 有没有落在那八个值里。处置：422 先换上游或摘模型，别指望退版本；拒答等 P1 闭合，或只取映射那一半。
盯：#7194 一合并、一版发出，第一条的处置就作废；#7192 的作者回了 P1 再来取。在那之前，别把
end_turn 当成「回答完整」的同义词。行情
三处上游状态页都干净：OpenAI 25 个组件无降级、整体 All Systems Operational；Anthropic 全绿，页面在北京时间 12:34 更新过；Google Cloud 最新一条事故仍是 10-28。
Codex 今日仍未重置。追踪站记录的最新一条帖是北京时间今天 07:27 的，但它没被登记成重置承诺；登记为信号的最新一条是今天 01:15 的额度话题。最近一次已验证的全局重置仍是 10 月 28 日那一次，距今五天。
References
- 1
- 2
- 3PR 7194：把 developer 角色归一化为 system
github.com
- 4评审的 P2 与作者的修复说明
github.com
- 5Antigravity→OpenAI 侧的内容过滤判定
github.com
- 6Claude 的 stop_reason 定义
platform.claude.com
- 7PR 7192：把安全与过滤类结束原因映射成 refusal
github.com
- 8那条未闭合的 P1
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.