Error messages

Output blocked by content filtering policy

Output blocked by content filtering policy

This one comes from Anthropic's API rather than from Claude Code. The server started generating Claude's reply, a filter stopped it partway, and the request came back as a failed one. Depending on the version and how you're running it, the line looks like one of these:

API Error: 400 Output blocked by content filtering policy

API Error: {"type":"error","error":{"details":null,"type":"invalid_request_error","message":"Output blocked by content filtering policy"},"request_id":"req_..."}

As of September 25, 2026, 136 issues in the anthropics/claude-code repo quote "Output blocked by content filtering". We looked for the string in the Claude Code 2.1.282 binary and found it only in a check that sorts errors into categories. When a failed request's message contains it, Claude Code files the failure as output_content_filtered in its logs. It doesn't write its own explanation, which is why you only see the server's text.

What Anthropic has said about it

Boris Cherny, who works on Claude Code at Anthropic, answered a report about it in August 2026. The message "comes from a safety filter on the API side that rejects a response while it is being generated", he wrote, and "Claude Code just shows the error it received, it doesn't do any filtering itself." He tried the reporter's task on 2.1.233 and it completed normally, so he called it a "context-specific false positive from the server-side filter".

That's about as far as the official word goes. I couldn't find the string in Claude Code's error reference or in the API's error docs, and nobody at Anthropic has said publicly what this filter looks for. It's a separate mechanism from the Usage Policy refusal, which arrives as a normal response with a refusal stop reason and a category, where this one is an HTTP 400 invalid_request_error.

What people were doing when it fired

The reports are mostly ordinary work. One person was writing the Contributor Covenant 2.1 into a CODE_OF_CONDUCT.md verbatim, and another a Business Source License file. Others hit it on a public-domain 1889 translation of Aristotle going into LaTeX, on a US-state checkout rule for an online shop, and on a chapter of fiction based on Revelation 15. Several of those involve reproducing a well-known text word for word, which is a pattern reporters noticed themselves. Nobody at Anthropic has confirmed it's the cause, so I'd treat it as a guess.

The timing surprised me more. In one July report the answer had already been shown in full, and the error line turned up underneath it. A commenter on the same thread saw it right after an Edit that had succeeded, and the turn stopped there, so it looked as though the session had hung with the file already written.

Why it can keep coming back

Some people get it once. Others get it on every message after the first, including a bare "hello" in the Revelation report. The filter is judging the reply, and the reply is built from everything in the conversation, so whatever led to the first block is still in the context for the next one. That's also why the advice below leans on starting over.

What helps

Retry first. Back in 2025 Cherny called it something that "happens occasionally due to security checks" and said a retry usually fixes it. His August list was longer. Retry, rephrase the task to say plainly what you're building (his example was "block checkout for these states and show a notice"), or start a fresh session so the earlier context isn't part of the request. /clear does that without leaving the project.

If it still fires on work that's clearly fine, report it with the exact prompt, the version you're on and ideally the conversation itself. Cherny asked for a /share link. In 2.1.282 that's another name for /bug, which the command list describes as "Report a bug or share your conversation", and a concrete example is what he said the team that owns the filter needs.