400 with empty error body when context contains regional-indicator pairs (flag emoji, e.g. 🇹🇼) #51348

Summary

Requests whose conversation context contains regional-indicator symbol pairs (U+1F1E6–U+1F1FF — e.g. the flag sequence 🇹🇼 = U+1F1F9 U+1F1FC) are rejected by the opencode.ai/zen/go gateway with HTTP 400 and an empty error body:

{"model":"deepseek-flash"}

(31-byte response family; the error field is absent entirely.) No error.type, no message — clients can only report "400" with zero diagnostic information.

Reproduction (single-variable mutation test)

Same request body; only the user text differs:

Interleaved timeline against the same gateway in one window: 200 → 400 400 … → 200 — the trigger is the content, not timing or rate.

• Endpoint: POST /v1/messages (Anthropic Messages), model deepseek-flash
• Context size: 55k–154k tokens (well under any context limit)
• First observed: 2026-09-24 15:59 UTC
• Deterministic whenever the code-point sequence is present at this size

Why this is probably not #51201 / #50761

• provider: opencode-go 400 stub on long sessions varies per attempt (identical bytes replay 200/400/200) #51201 (same bytes returning 200/400/200 on an 870k-token session) and provider: opencode-go route-dependent context limits cause unparseable HTTP 400 in long sessions #50761 (dual-upstream context-limit routing) are size / session-length paths.
• This report: a single content variable flips the outcome at ~55–150k tokens; removing those two code points yields 200 with everything else byte-identical.

Impact

Behind Claude Code auto mode, the permission classifier sends the full conversation context on every tool call. It receives this 400 → fail-closed → every file/bash write is blocked for the rest of the session. One content match bricks the session until the context is scrubbed or the model is switched.

Side observation: a different provider (DeepSeek official API) rejects the same content with an explicit 400 Content Exists Risk message — so upstream content moderation on this sequence is plausible. If zen/go moderates this content too, that is fine — but please return a descriptive error (standard Anthropic error envelope with type/message) instead of an empty body, so clients can distinguish "content rejected" from "gateway broken".

Ask

1. Either stop rejecting regional-indicator pairs, or
2. Return a proper error payload identifying the rejected content class.