Table of contents

When Claude stops on you, the first thing you do is search the message you just got, exactly as printed. And for some messages, that search turns up almost nothing. These are examples.

The model returned no content because the response was blocked by content filtering
The response was blocked by the provider's content filter
Streaming response ended before any complete data was received
Could not locate the Claude CLI on PATH
Connection to Claude's response was lost. Claude may still be working

What these five have in common is that they appeared while you were using Claude, yet searching Claude's official documentation seems to turn up nothing. The reason is plain: the program that wrote the message now on your screen is not necessarily the one you think it is.

There is no longer a single route to Claude. The claude command in a terminal, an IDE extension, a different agent such as OpenCode, a path through GitHub Copilot — every one of them decides for itself how to phrase a failure. The same event is worded differently by each layer that writes it.

This article does not explain each individual cause from scratch. It is the entrance hall: identify who wrote the message, then send you to the right explanatory article. The details stay in the existing articles; here we handle only tracing the source. What could be confirmed from primary sources and what could not are kept apart.

IN SHORT
① FIRST MOVE
Match it against the official catalogue

Claude Code officially lists the messages it prints. Whether yours matches exactly already narrows down the layer that wrote it. Do this before you start reasoning about the cause.

② THE TRAP
The named cause can be wrong

Third-party tools name a cause in their wording, and a public issue records real cases where that name does not match what happened. Believe the wording and you will fix the wrong place.

③ LOOKS TELL YOU NOTHING
Two of the five were official

Checking the five strings above against the catalogue, two of them were listed in Claude Code's official error reference. You cannot guess the layer from how a message feels.

1. Do this first — look for an exact match in the official catalogue

There is something to do before you start reasoning about the cause: confirm whether the message belongs to Claude Code's own vocabulary.

Claude Code has an official error reference, and it enumerates the messages Claude Code puts on your screen. Authentication, rate limits, context overflow, network, streaming, MCP, plugins — each one appears as the literal display string. So "is the string I saw listed there" is not a guess but a match.

RESULT A
Exact match

Either Claude Code itself, or a message the docs classify as printed by the launcher. The official explanation and fix apply as written. Two of the five at the top landed here.

RESULT B
Similar but not identical

Another program most likely paraphrased it. A named cause is sometimes added during that paraphrase, so do not take the name at face value.

RESULT C
Not there at all

That message is the vocabulary of the tool you are using. What you should be searching is not Anthropic's material but that tool's repository and its issues.

The word "Claude" in a message does not make it Anthropic's. Claude or model appears in the sentence because the tool calls Claude, not as evidence that Anthropic wrote the sentence. The reverse combination exists too: printed by a program Anthropic makes, yet absent from the main body of the official catalogue (Chapter 5).

2. Which of four layers wrote the error message

Break the route to Claude apart and there are four places that can write a string when something fails. Which layer wrote it changes how you read it and where a fix will land.

LAYER ①
The backend that serves the model

The Anthropic API, but also Amazon Bedrock, Google Vertex AI, the GitHub Copilot gateway and others. The HTTP status and the JSON error.message often reach the screen unchanged.

Example: Output blocked by content filtering policy

LAYER ②
Claude Code itself

A note the CLI adds on its own judgement. Being listed verbatim in the official error reference is the mark of this layer, and the meaning and recovery steps are documented.

Example: Streaming response ended before any complete data was received

LAYER ③
The launching program (IDE extension or wrapper)

Printed by whatever tried to launch Claude Code and failed. The official reference gives these a separate chapter, "Wrapper and IDE errors", and describes them as printed by the launching program rather than by Claude Code itself.

Example: Could not locate the Claude CLI on PATH

LAYER ④
Third-party clients

Another agent that calls Claude as its model. The wording is written by that project itself and does not exist in the official catalogue. It frequently names a cause, and that name can miss.

Example: The response was blocked by the provider's content filter

Of these four, layer ④ is the one most easily misread. Layers ① to ③ tend to state what happened, whereas layer ④ wording often goes all the way to why it happened. That assertion, however, is no more than an inference made by that tool. The next chapter works through a documented example.

3. When it says "content filter", whose filter is it?

Two of the five listed at the top both say the response was blocked by a content filter. This is where the mix-up is most likely, because using Claude does not mean it was Anthropic's filter that stopped you.

3-1. The model returned no content because the response was blocked by content filtering

🟡 Source (observation only): the one primary source where this string could be confirmed verbatim was Issue #3348 in github/copilot-cli, in GitHub's own repository. Its title reads "Repeated 'The model returned no content because the response was blocked by content filtering' on legitimate technical reasoning turns", carrying the string as it is. However, the author withdrew the body, and no technical answer from a maintainer is attached. The status is closed as not planned. The string itself is not visible in GitHub's public documentation. This article therefore claims nothing beyond "it is a message reported in GitHub Copilot CLI".

On the other hand, ✅ one thing can be stated with certainty. GitHub's official documentation, Hosting of models for GitHub Copilot, is explicit about what happens when you use Claude.

"When using Claude, input prompts and output completions continue to run through GitHub Copilot's content filters for public code matching, when applied, along with those for harmful or offensive content."

In other words, when you use Claude through Copilot, there is also a filter on GitHub's side that can stop the output. The same page goes on to describe the hosting for the Claude models available in Copilot as "Amazon Web Services, Anthropic PBC, and Google Cloud Platform" — which means you are not necessarily on a setup that calls Anthropic's api.anthropic.com directly.

That is why the fix changes. The Output blocked by content filtering policy you get directly from the Anthropic API or Claude Code is mainly an output filter stopping the reproduction of existing copyrighted work, and the fix leans towards not asking for verbatim copies (see Output blocked by content filtering policy: causes and fixes). Through Copilot, though, GitHub itself writes that matching against public code is also inspected. If the work produces output resembling existing code, that may be where it is being stopped. The same phrase "content filtering" does not guarantee the same thing is being inspected.

One test is enough to separate them. Run the same prompt through the claude command in your terminal, which is a route straight to Anthropic. If it passes there and only Copilot CLI stops, the thing stopping you is not Anthropic's filter. If both stop, the judgement is likely coming from the side that serves the model.

3-2. The response was blocked by the provider's content filter

✅ Source (confirmed): this string belongs to OpenCode, an open-source coding agent. Issue #35736 in the repository anomalyco/opencode reports the wording verbatim.

And this issue is the single example this article most wants to convey. Its title says that Vertex provider errors — a 404, a socket drop, and stop_reason:refusal — all surface as the same "blocked by content filter".

REALITY 1
404 NOT_FOUND

The model does not exist in the region you configured. The issue's example is claude-opus-4-8@default. This is nothing but a configuration mistake and has no connection to any filter.

REALITY 2
Socket drop or connection reset

The connection to the Vertex API broke during a long session. A network event, in which the content of the output was never even judged.

REALITY 3
A genuine refusal

HTTP 200 comes back carrying stop_reason: refusal and a safety category (cyber in the issue's example). This one alone matches the wording.

Of the three, the wording is correct for exactly one. Yet the screen shows the same sentence for all of them. That is why layer ④ wording must not be taken at face value — read it as "blocked by a filter" and soften your phrasing, and if the reality is a 404 you will never fix it. What needs fixing is the model ID and region setting.

The same repository also carries Issue #35643, "you are still billed for what was generated even when the content filter blocks the output". Both were open when this article was written.

🟡 What could not be confirmed: where in OpenCode's source this string is assembled could not be pinned down, because the issue does not say. The issue does mention PR #31745 as an earlier partial fix, but the point of the report is that it still does not distinguish all three failures.

So the order to try is this. ① Confirm that the model ID and region you configured are a combination that actually exists. ② See whether the same prompt reproduces it or whether it is sporadic, since sporadic points at the connection side. ③ If you can capture the raw response, look at stop_reason. Only once ③ shows refusal may you treat this as a problem with the content.

4. Streaming response ended before any complete data was received — this one was Claude Code's own wording

From here we take the two that look like third-party wording but are in fact part of Claude Code's official vocabulary.

✅ Confirmed: this string exists as an entry in the Claude Code official error reference. And the official explanation is not what most people picture.

"The API returned response headers, but the response body contained no Claude API message."

So it is not "it came partway and then cut off". It is "not one piece of content ever arrived". The words Streaming and ended make it easy to read this as a line dropping while the response was flowing, but the official definition points at a state where only headers came back and the body was empty. Get that wrong and you will spend a long time trying disconnection remedies.

The official guidance offers two moves. ① Send it again — the original message is still in the conversation, so there is no need to paste a long prompt back in; typing try again is enough. ② If it happens every time, suspect the network, the proxy, or the provider's gateway — the docs route you to the "Unable to connect to API" entry.

What backs up this reading is the sibling entries sitting next to it. The official reference has API returned an empty or malformed response (the headers indicate success, but the body is not a valid Claude API message), and it even has Bedrock streaming response has content-type "..."; expected "application/vnd.amazon.eventstream", an entry that names the gateway returning content of the wrong type. This whole family is the "a 200 came back, but the content is not Claude's response" kind.

The side where no content arrived at all

Streaming response ended before any complete data was received
API returned an empty or malformed response

Suspect the route: a corporate proxy, TLS termination, an API gateway, a relay sitting in front of Bedrock or Vertex. See the article on network, proxy and TLS certificate errors

The side that cut off after output had appeared

Connection lost mid-response
The response stopped arriving

Here whatever reached the screen is kept, and continue resumes from where it stopped. See the article on Connection lost mid-response

5. Could not locate the Claude CLI on PATH — wording the docs classify as printed by the launcher

✅ Confirmed: this string is in the official error reference too. Where it sits matters, though: it is in a separate chapter called "Wrapper and IDE errors". The docs describe that chapter as errors printed by the launching program rather than by Claude Code itself.

The official definition is that the launching program could not find the claude command on the system PATH. Two fixes are given.

  • Reinstall. The installer adds claude to PATH
  • Put the install location on PATH. On macOS and Linux this is usually ~/.local/bin or /usr/local/bin; on Windows it is usually %APPDATA%\Anthropic\Claude\bin or C:\Program Files\Anthropic\Claude\bin

But here is the thing: the message that actually reaches your screen can be longer than the heading in the official catalogue. Issue #80087 in anthropics/claude-code records the real thing a VS Code extension printed, verbatim.

Could not locate the Claude CLI on PATH. Launching by name in a PowerShell terminal would run a 'claude' from the open folder instead of the installed CLI, so the launch was blocked. Make sure the Claude CLI's install directory is on your system PATH (not only your PowerShell profile), then restart VS Code and try again.

The second half is explanation the extension added on its own. That is why searching turns up nothing, and why the right move is to search only the first sentence. This holds for layer ③ wording generally: the launcher grafts its own circumstances onto the official heading.

🟡 What Issue #80087 reports, unconfirmed parts included: the reporter is on Windows 11 and states that the terminal claude works fine while only the extension fails. It worked on v2.1.212 and reproduced on v2.1.214 and v2.1.217, so they suspect a regression introduced in v2.1.214. The suspected cause is how Windows' where.exe output is handled in environments where the username contains non-ASCII characters, but that is the reporter's inference, not an established cause. The issue was open when this article was written, and pinning the extension to v2.1.212 is listed as a workaround.

One line is enough to isolate this. Type claude --version in your terminal. If a version prints there and only the extension fails, what is broken is not the CLI but the PATH the launcher sees. When you start an editor from its icon, the PATH that process receives can differ from the PATH your login shell assembles. The case where the install itself never completed is covered in the article on command not found.

6. The message we could not trace, and four steps to trace it yourself

For one of the five at the top — Connection to Claude's response was lost. Claude may still be working — 🔴 the source could not be identified. This article names no tool for it.

What was searched, and what came of it, is on the record. Every entry in the Claude Code official error reference was read through, and this string was not among them. The official documentation for Remote Control, the feature that continues a local session from a phone or a browser, was read in full as well, and it was not there either. The closest official wording is Connection lost mid-response and Couldn't reconnect to your Remote Control session, and neither string matches.

So it is either layer ③ or layer ④, but which tool wrote it has not been confirmed. The phrasing "Claude may still be working" hints that whoever wrote it is not the one running Claude — that they are watching another process or another machine from outside — but this is 🟡 an inference from the phrasing, with no confirmation behind it.

Here is a procedure that lets you settle cases like this yourself. It applies to every case in the previous chapters as well.

STEP 1
See where it was drawn

Did it appear mixed into the flow of Claude's response, or in the frame, notification or panel outside it? If it is outside, layer ③ or layer ④ wrote it.

STEP 2
Reproduce it on bare claude

Run the same work through the terminal's claude. If it does not reproduce, the wording belongs to that tool. If it does, descend to layer ① or layer ②.

STEP 3
Look for an exact match in the official catalogue

Search the official error reference inside your browser. Search only the first sentence, because the rest may be grafted on by the launcher (Chapter 5).

STEP 4
Search that tool's issues

If it is not official, the place to look is not Anthropic's material. Search the string in the issues of the repository of the tool you use. That is how the sources in this article were traced.

7. Lookup table — from message to destination

Here is everything above on one sheet. The "who wrote it" column is what decides how far you may trust the message.

Message on screen Written by What is actually happening Where to go
The model returned no content because the response was blocked by content filtering 🟡 Layer ④
wording reported in GitHub Copilot CLI		 Output stopped by a filter. But it may be GitHub's filter, which also inspects matches with public code The output filter article
The response was blocked by the provider's content filter ✅ Layer ④
OpenCode		 Three possibilities: a 404 on the model ID, a dropped connection, or a genuine refusal. Only the third matches the wording The isolation steps in Chapter 3
Streaming response ended before any complete data was received ✅ Layer ②
Claude Code itself (official)		 Headers arrived but the body was empty. It did not cut off partway. Suspect the route: proxies and gateways The network and proxy article
Could not locate the Claude CLI on PATH ✅ Layer ③
the launcher (stated officially)		 claude is not on the PATH the launcher sees. The CLI itself is often perfectly healthy The command not found article
Connection to Claude's response was lost. Claude may still be working 🔴 not identified
absent from the official catalogue		 Undetermined. The closest official wording is Connection lost mid-response The four steps in Chapter 6 and the article on the closest official wording

Read the table across and you can see that only the two layer ④ rows wobble in the "what is actually happening" column. Layers ② and ③ have official definitions, so they do not wobble. That difference is exactly the difference in how far the wording can be trusted.

8. What is settled and what is not

✅ Confirmed from primary sources
  • Streaming response ended… and Could not locate the Claude CLI on PATH both exist as entries in the Claude Code official error reference
  • The docs place the latter under "Wrapper and IDE errors" and describe it as printed by the launching program
  • The former means "headers came back but the body holds no Claude API message" — not a mid-way cut
  • OpenCode's Issue #35736 reports that a 404, a dropped connection and a genuine refusal all produce the same wording
  • GitHub officially states that even when using Claude, input and output pass through GitHub Copilot's content filters
🟡 Reported but not settled
  • The source of The model returned no content because…. The only verbatim confirmation is the title of Issue #3348 in github/copilot-cli, whose body was withdrawn
  • The cause given for the VS Code extension regression in Issue #80087, the handling of where.exe output, is the reporter's inference
  • Which OpenCode code emits the wording is not stated in the issue
  • That "Claude may still be working" is how a watcher of another process would phrase it is an inference from the wording
🔴 Could not be confirmed
  • Which tool emits Connection to Claude's response was lost…. It was in neither the official error reference nor the Remote Control documentation
  • A technical explanation from GitHub for that Copilot CLI wording (Issue #3348 is closed as not planned, with no maintainer answer attached)
  • Completion of a fix for OpenCode's two issues (both open when this article was written)

It comes down to this. You cannot tell from the look of a message which layer wrote it. All five at the top look like something a third-party tool wrote, yet two were official, two were third-party, and one is unknown. So the first move is not reasoning about causes but matching against the official catalogue. It takes a minute, and it decides where you search next.

FAQ

Q1. I am using Claude, but I cannot find the message anywhere in Anthropic's documentation.

Anthropic may not have written it. Tools that call Claude as their model — IDE extensions, other coding agents, use through Copilot and so on — each decide their own phrasing for a failure. Look for an exact match in the official error reference first, and if it is not there, search the string in the issues of the repository of the tool you are using.

Q2. If it says "content filter", does that mean I hit Anthropic's filter?

Not necessarily. GitHub's official documentation states that even when using Claude, input prompts and output completions run through GitHub Copilot's content filters. And in OpenCode, Issue #35736 reports cases where a 404 or a socket drop, neither of which involves any filter, is shown with the same "content filter" wording. Run the same prompt through the terminal's claude as well and separate the cases by whether it reproduces.

Q3. Does Streaming response ended before any complete data was received mean the connection dropped?

No. The official error reference defines it as "the API returned response headers, but the body contained no Claude API message". It is not that part of it arrived and then cut off; it is that no content arrived at all. Send it again first, where try again is enough, and if it happens every time, suspect the route: proxies, gateways and so on.

Q4. claude works in my terminal, but only the IDE extension says "Could not locate the Claude CLI on PATH".

The problem is the launcher, not the CLI. The official reference classifies this wording under "Wrapper and IDE errors", meaning it is printed by the launching program rather than by Claude Code itself. When you start an editor from its icon, the PATH that process receives can differ from the PATH your login shell assembles. There are also reports of regressions tied to an extension version, such as Issue #80087.

Q5. Does searching turn up nothing because the error is rare?

More often it is because the string is too long. Layer ③ wording sometimes has the launcher's own explanation grafted onto the official heading; in the example in Chapter 5, the official heading is one sentence while the actual display ran to four. Search only the first sentence.

Q6. Should I never act on the cause the message names?

It depends on the layer. Wording that matches the official catalogue exactly, layers ② and ③, has documented meaning and fixes, so following it is fine. The problem is layer ④. OpenCode's Issue #35736 reports that three completely different failures all end up as the same "blocked by the content filter" sentence. When the reality is a configuration mistake, believing the wording and rewriting your phrasing will never fix it.

Q7. Would it be simpler to stop using third-party tools?

There is no need to go that far. What is at issue here is not whether a tool is good but only where the wording of a failure came from. Trying to reproduce it once on bare claude during isolation is enough as a practice. For choosing between tools, see the comparison of Cursor, Claude Code, GitHub Copilot and Codex.

Q8. How do I fix Connection to Claude's response was lost. Claude may still be working?

This article could not identify its source. The string is in neither the Claude Code official error reference nor the Remote Control documentation. It was therefore written either by a launcher or by a third-party client, but since we could not confirm which tool, this article names none. Use the four steps in Chapter 6 to identify it in your own environment. For the phenomenon of a response cutting off partway, the article on the closest official wording, Connection lost mid-response, is a useful reference.

Related articles

Primary sources used