Repeated 'The model returned no content because the response was blocked by content filtering' on legitimate technical reasoning turns

[KarnikJain]

(content withdrawn by author)

[kayone007]

Reproduced again today (2026-05-22), 3 distinct turns in the same session

Same bug, same session, same model. Still silent empty turn with the placeholder text and no diagnostic.

Environment

• Copilot CLI version: 1.0.52-2
• Model: Claude Opus 4.7 (1M context)(Internal only) (claude-opus-4.7-1m-internal)
• OS: macOS (Darwin)
• Session topic: deep technical RCA on a firmware bring-up issue. Source-code excerpts and log excerpts pasted in context. Nothing harmful, sensitive, copyrighted, or policy-violating.

Trip count today

Turn	User prompt (paraphrased / sanitised)	Result
1	"Question about a specific signal and its behaviour. Ask the model to scan two source branches and produce an analysis."	Empty turn, placeholder text
2	"retry"	Recovered, produced normal output (5 KB analysis file)
3	"Verification question referring to an internal log URL."	Empty turn, placeholder text
4	"retry?"	Recovered, produced normal output
5	"Follow-up question about whether the issue is API-related, plus a request to re-check using the model's prior knowledge."	Empty turn, placeholder text
6	"retry?"	Recovered, produced normal output

Pattern observed

All three blocks were on prompts that:

• Asked for cross-layer technical analysis (RTL + firmware + log files)
• Required the model to read and reason over source files it had already touched earlier in the session
• Contained zero policy-sensitive content
• Were typed in informal English (lowercase, typos, abbreviations)

In all three cases, a one-word "retry" or "retry?" from the user immediately recovered, with the model producing high-quality output on the very next attempt. So the model CAN produce the answer — something in the first attempt is being post-hoc filtered.

What this confirms from the original bug report

• Silent loss of work (no diagnostic)
• Affects long sessions with built-up state (this session is now 35+ turns)
• No identification of which content tripped the filter
• No automatic retry
• Recovery via manual user retry suggests the filter is non-deterministic or context-window-position-sensitive, not content-deterministic

Severity is increasing

In long deep-investigation sessions (the exact use case Copilot CLI is most valuable for), these silent blocks are now happening 3+ times per session. Each one costs ~30 seconds of user latency plus cognitive overhead.

The silent recovery on simple retry is the strongest signal that this is a false-positive filter trigger, not a real policy issue. Adding an automatic retry (even just once, transparent to the user) would likely resolve 90%+ of these in the wild.

What would help most (re-prioritised)

1. Auto-retry on this specific empty-content failure mode — single highest-value fix. The retry works.
2. A distinct error code so we can grep / count occurrences across sessions.
3. A --debug-content-filter flag that prints what got blocked (last user message, model draft, or context window) — so we can submit specific repros.

Happy to provide further detail privately on request through a secure channel.