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

[KarnikJain]

Summary

During a long, multi-turn deep technical debugging session, the agent silently produced an empty assistant turn with the only signal being the placeholder text:

"The model returned no content because the response was blocked by content filtering."

This happened twice in the same session on completely benign turns where I was asking the model to do further analysis on data it had already produced earlier in the same conversation, with no harmful, sensitive, copyrighted, or otherwise policy-violating content involved.

Environment

• Copilot CLI version: 1.0.49-1
• Model: Claude Opus 4.7 (1M context) (Internal only) (claude-opus-4.7-1m-internal)
• OS: macOS (Darwin)
• Session was a deep technical RCA on an embedded systems bus-protocol bug (large register-dump excerpts, large console-log excerpts, large code excerpts pasted into context). Nothing harmful, sensitive, copyrighted, or policy-violating involved.

What happened

1. The session ran for ~30+ turns building a layered RCA. The model was reasoning over hardware register dumps, source code excerpts, and wire-capture data.
2. On a routine continuation turn (user said RESUME WORK what are u doing), the assistant turn was empty and the system added the placeholder line The model returned no content because the response was blocked by content filtering.
3. There was no actionable error, no link to which content tripped the filter, no suggestion of what to rephrase, and no automatic retry.
4. A second user turn (Resume the work) hit the same blocked-empty result.
5. After the user gave a small content-correction prompt re-stating a topology fact, the model recovered and produced normal output again.

Why this is a problem

• Silent loss of work. The user can't tell whether the model actually finished thinking and chose not to respond, hit a content-policy false positive, or silently failed for another reason. There is no diagnostic.
• Poor UX in long sessions. When you're 30+ turns into a session and have built up a lot of state, getting an empty turn with no explanation is jarring and erodes trust. The user is left guessing whether to rephrase, retry, restart, or escalate.
• No feedback loop. Because there's no indication of which content triggered the filter, the user can't reliably reproduce or report a specific false-positive trigger to whoever maintains the filter rules.

What I'd expect

At minimum, when a content filter blocks a response:

1. A distinct, identifiable error code (not a placeholder string) so users can grep for it and report it.
2. Some indication of which side tripped the filter (the user's last message, the model's draft response, or the conversation context as a whole).
3. A suggestion (/retry, /compact, /rewind) so the user has a clear next step.
4. Optionally: an automatic retry with a slightly modified prompt or a clearer surface error, like other LLM SDKs do.

Repro hints (best I can offer without leaking work content)

• Long session (~30+ turns) on a deep technical analysis topic
• Many register-dump-style hex blocks pasted by the user (e.g. 0xff 0xfe 0xfd ... patterns)
• Multiple file paths, branch names, log excerpts in context
• Each user turn was a normal "continue / now investigate X / now write up Y" type prompt
• Trigger turn was a plain RESUME WORK what are u doing — it should have just continued the conversation

I cannot share the exact transcript because the underlying domain is internal work content, but happy to provide more detail privately to maintainers if there's a secure channel.

Workspace setup

Standard install via Homebrew on macOS, no custom MCP servers or LSP changes that would plausibly affect content filtering.

---

Filing under my Microsoft GitHub account because this happened during work-related use of the CLI.