目录

用 Claude 的时候卡住了，第一反应是把屏幕上出现的那句话原样拿去搜。可搜出来的东西几乎为零——这样的句子有好几条。比如下面这些。

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

它们的共同点是，“明明是在用 Claude 时出现的，可翻遍 Claude 的官方文档也找不到（看上去是这样）”。原因很清楚：写下你此刻屏幕上这句话的，未必是你以为的那个程序。

调用 Claude 的路径已经不止一条。终端里的 claude、IDE 扩展、像 OpenCode 这样的另一个智能体、经由 GitHub Copilot 使用——每一条路径都自己决定失败时怎么说。同一件事，写它的层不同，说法就不同。

本文不是从零讲解每一种原因的文章。它是一个入口：先判定“这句话是谁写的”，再把你送到正确的那篇解说文章去。细节交给已有的文章，这里只处理出处的判定。用一手资料能确认的和不能确认的，分开来写。

先说结论
① 第一步
拿官方目录去比对

Claude Code 把自己会显示的文字官方地列成了清单。是否全字一致，就能把写它的层缩小到一个。在推理原因之前先做这件事。

② 陷阱
指认会指错

第三方工具的文字会直接指认原因，可是指认与实情不符的实例已经记录在公开 Issue 里。信着它去改，改的会是另一个地方。

③ 光看外表分不出来
五条里有两条是官方的

把开头列出的五条真去比对，其中两条就写在 Claude Code 官方的错误参考里。凭语感是猜不出层的。

1. 第一步该做的事——在官方目录里找全字匹配

在推理原因之前，有一件事要先做：确认这句话是不是 Claude Code 自己的词汇。

Claude Code 有一份官方错误参考，把 Claude Code 会显示在屏幕上的文字系统地列了出来。认证、速率限制、上下文超限、网络、流式传输、MCP、插件——全都按实际显示的字符串原样排在那里。所以“我看到的这串字是不是在上面”，不靠猜，靠比对就能定。

结果 A
全字一致

要么出自 Claude Code 本体，要么是官方归类为“由启动方显示”的文字。官方的说明与处理办法可以直接照用。开头五条里有两条属于这一类。

结果 B
很像，但对不上

多半是另一个程序改写过。改写的过程里常常会添上对原因的指认，这个指认不要照单全收。

结果 C
连影子都没有

这句话是你正在用的那个工具的词汇。该翻的不是 Anthropic 的资料，而是那个工具的仓库和 Issue。

写着“Claude”也不等于是 Anthropic 写的。 句子里出现 Claude 或 model，只说明那个工具在调用 Claude，并不能证明这句话由 Anthropic 写下。反过来，也有由 Anthropic 自家程序显示、却不在官方目录本体一侧的组合（第 5 章）。

2. 写下这句错误信息的，是四个层里的哪一个

把使用 Claude 的路径拆开，失败时可能写出这串字的位置有四个。由哪个层写下，读法和处理该落到哪里，都会跟着变。

层①
提供模型的后端

除 Anthropic API 之外，还有 Amazon Bedrock、Google Vertex AI、GitHub Copilot 的网关等。HTTP 状态码和 JSON 里的 error.message 常常原样出现在屏幕上。

例：Output blocked by content filtering policy

层②
Claude Code 本体

CLI 自己判断后加上的说明。逐字写在官方错误参考里就是这一层的标志，含义与恢复步骤都有文档。

例：Streaming response ended before any complete data was received

层③
启动方程序（IDE 扩展、封装器）

由试图启动 Claude Code 却失败的那一方显示。官方参考把它单独放进“Wrapper and IDE errors”一章，并说明这是由启动方程序打印、而不是 Claude Code 自身的内容。

例：Could not locate the Claude CLI on PATH

层④
第三方客户端

把 Claude 当作模型来调用的另一个智能体。文字由那个项目自己写，官方目录里并不存在。常常带着对原因的指认，但也会指错。

例：The response was blocked by the provider's content filter

这四层里，最容易读错的是层④。层①到层③偏向于陈述“发生了什么”，而层④的文字常常连“为什么发生”都一口咬定。可那个断言，不过是那个工具自己下的推测。下一章讲它的实例。

3. 出现“content filter”时，那是谁的过滤器

开头列出的五条里有两条，都在说“被内容过滤器拦下了”。这里格外容易搞混。因为你在用 Claude，并不代表拦下你的就是 Anthropic 的过滤器。

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

🟡 出处（只到观测为止）： 能逐字确认到这串字的一手资料，只有 GitHub 自家仓库里的github/copilot-cli 的 Issue #3348。标题是“Repeated 'The model returned no content because the response was blocked by content filtering' on legitimate technical reasoning turns”，字符串原样写在里面。不过正文已被发帖人撤回，也没有维护者的技术性回复。状态是 closed as not planned。GitHub 的公开文档里找不到这串字本身。因此本文不主张“它是在 GitHub Copilot CLI 上被报告过的文字”以外的任何内容。

另一方面，✅ 有一件事可以确定。GitHub 的官方文档《Hosting of models for GitHub Copilot》就使用 Claude 的情形写明了下面这一点。

“即使使用 Claude，输入提示与输出补全仍会继续经过 GitHub Copilot 的内容过滤器——一个是关于与公开代码是否匹配（如适用）的过滤器，一个是关于有害或冒犯性内容的过滤器”

也就是说，经由 Copilot 使用 Claude 时，能拦下输出的过滤器在 GitHub 一侧也存在。同一个页面还说明，Copilot 上可用的 Claude 模型托管在“Amazon Web Services, Anthropic PBC, and Google Cloud Platform”——并不一定是直接请求 Anthropic 的 api.anthropic.com 的架构。

所以处理办法也随之改变。 在 Anthropic API 或 Claude Code 上直接出现的 Output blocked by content filtering policy，主因是阻止复现既有作品的输出过滤器，处理方向要往“别让它逐字照抄”上靠（→ Output blocked by content filtering policy 的原因与对策）。可是经由 Copilot 时，GitHub 自己写明还会看“与公开代码是否匹配”。如果做的是生成与既有代码相似的输出，就有可能是在那一边被拦下。同样是“content filtering”这个词，看的对象未必相同。

区分办法一个就够。把同一段提示，也放到终端的 claude（直连 Anthropic 的路径）上跑一次。那边能过、只有 Copilot CLI 被拦，那么拦下你的就不是 Anthropic 的过滤器。反过来两边都被拦，多半是模型提供方一侧的判断。

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

✅ 出处（已确认）： 这串字来自OpenCode（开源的编码智能体）。仓库 anomalyco/opencode 的 Issue #35736 里，逐字报告了这句话。

而这个 Issue 正是本文最想给你看的实例。标题译过来是这样——“Vertex 提供方的错误（404、套接字断开、stop_reason:refusal）全部以同一句‘blocked by content filter’浮出水面”。

实情 1
404 NOT_FOUND

所设定的区域里没有那个模型。Issue 里的例子是 claude-opus-4-8@default。这只是配置写错，与过滤器毫无关系。

实情 2
套接字断开、连接重置

长时间会话中与 Vertex API 的连接掉了的情况。这是网络层面的事件，输出的内容根本没有被判定过。

实情 3
真正的拒绝

以 HTTP 200 返回，同时带着 stop_reason: refusal 与安全类别（Issue 里的例子是 cyber）的情况。只有这一种与字面相符。

三种里与字面相符的只有一种。可屏幕上出现的却是同一句话。这就是层④的文字不能照单全收的理由——把它读成“被过滤器拦下”，再去把措辞改得温和些，只要实情是 404，就永远改不好。该改的是模型 ID 与区域的配置。

同一个仓库里还有 Issue #35643“即使内容过滤器拦下了输出，已生成的部分照样计费”。两个在本文写作时都还是 open。

🟡 没能确认的： OpenCode 的源码在哪里拼出这串字，Issue 里没有写，所以无从判定。Issue 提到过去有过一次部分修复 PR #31745，但报告的意思是并没有做到把三种失败都区分开。

现在该按这个顺序去试。①确认配置的模型 ID 与区域是不是真实存在的组合 ②看同一段提示是必现还是偶发（偶发就偏向连接一侧） ③如果能拿到原始响应，就看 stop_reason。只有在③里看到 refusal，才可以当成内容问题来处理。

4. Streaming response ended before any complete data was received——这是 Claude Code 本体的文字

接下来讲两条看着像第三方工具的说法、实际上是 Claude Code 官方词汇的。

✅ 已确认： 这串字作为条目存在于Claude Code 官方错误参考。而官方的说明，与多数人想象的内容不一样。

“API 返回了响应头，但响应体里没有装进 Claude API 的消息”

也就是说，不是“来到一半断了”，而是“一点内容都没来”。Streaming 和 ended 这两个词，很容易让人读成响应正在流的过程中断线了，可官方的定义指的是只返回了头、体是空的那种状态。这里读错，就会没完没了地去试防断线的办法。

官方给出的处理有两步。①再发一次——原来的消息还留在对话里，不必重贴长提示，输入 try again 就够。②如果每次都一样，就去怀疑网络、代理、提供方的网关——官方把你引向“Unable to connect to API”那一条。

支撑这种读法的，是排在旁边的几个同类条目。官方参考里有 API returned an empty or malformed response（头显示成功，体却不是有效的 Claude API 消息），还有 Bedrock streaming response has content-type "..."; expected "application/vnd.amazon.eventstream" 这样直接点出网关返回的内容类型不对的条目。这一组都属于“200 是返回了，可里面不是 Claude 的响应”这一系。

一点内容都没来的那一侧

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

要怀疑的是链路。企业代理、TLS 终结、API 网关、位于 Bedrock 或 Vertex 前面的中转。→ 网络、代理、TLS 证书错误的文章

输出已经出来之后才断的那一侧

Connection lost mid-response
The response stopped arriving

这一边屏幕上出现的部分会保留，用 continue 就能从中断处接着来。→ Connection lost mid-response 的文章

5. Could not locate the Claude CLI on PATH——官方归类为“由启动方显示”的文字

✅ 已确认： 这串字同样写在官方错误参考里。不过它被放在哪里很关键，它在“Wrapper and IDE errors”这个独立的一章里。官方对这一章的说明是，由启动方程序打印、而不是 Claude Code 自身的错误。

官方的定义是“启动方程序没能在系统 PATH 上找到 claude 命令”。作为处理办法，官方给出的是下面两条。

  • 重新安装。 安装程序会把 claude 加进 PATH
  • 把安装位置加进 PATH。 macOS 与 Linux 上通常是 ~/.local/bin 或 /usr/local/bin，Windows 上通常是 %APPDATA%\Anthropic\Claude\bin 或 C:\Program Files\Anthropic\Claude\bin

可是——实际显示在屏幕上的文字，有时比官方目录的标题更长。anthropics/claude-code 的 Issue #80087 里，逐字记录了 VS Code 扩展显示出来的实物。

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.

后半段是扩展自己加上的说明。搜不到就是因为这个，要搜就只搜开头那一句才对。这一点对层③的文字普遍成立——启动方会把自己的情况嫁接到官方的标题后面。

🟡 Issue #80087 报告的内容（含未确定部分）： 报告者在 Windows 11 上说，终端里的 claude 正常工作，唯独扩展失败。v2.1.212 上可以用，v2.1.214 与 v2.1.217 上复现，因此推测是 v2.1.214 引入的回归。原因上被怀疑的是 Windows 下 where.exe 输出的处理方式（用户名里含非 ASCII 字符的环境），但这是报告者的推测，不是已经定下的原因。Issue 在本文写作时仍是 open，规避办法给出的是把扩展固定在 v2.1.212。

区分只要这一行就够。在终端敲 claude --version。那里能显示版本、唯独扩展失败，那么坏掉的不是 CLI，而是启动方看到的那个 PATH。从图标启动编辑器时，那个进程拿到的 PATH，可能与登录 shell 组装出来的 PATH 是两回事。至于安装本身还没做完的情况，command not found 的文章里已经整理过。

6. 没能确定出处的那一句，以及自己查明的四步

开头五条里有一条——Connection to Claude's response was lost. Claude may still be working——🔴 没能确定出处。本文在这里不点出名字。

查过的范围与结果写在这里。把 Claude Code 官方错误参考的全部条目通读了一遍，没有这串字。Remote Control（把手边的会话在手机或浏览器上接着用下去的功能）的官方文档也全文查过，同样没有。官方里语感相近的是 Connection lost mid-response 与 Couldn't reconnect to your Remote Control session 这两条，与它都不是同一串字。

所以层上不是③就是④，但是哪个工具写的，没能确认。“Claude may still be working（Claude 可能还在干活）”这种说法，暗示写下这句话的一方并不是正在跑 Claude 的那一方——它是从外面看着另一个进程或另一台机器——不过这🟡 只是从措辞推出来的，没有拿到佐证。

这种时候，读者可以自己把它判定下来的步骤放在这里。它对前面各章的所有情形同样适用。

步骤 1
看它画在哪里

它是混在 Claude 响应的流里出现的，还是出现在外面的框、通知、面板上。如果在外面，写它的就是层③或层④。

步骤 2
用原生的 claude 复现

把同样的活儿放到终端的 claude 上跑。复现不了，这句话就属于那个工具。复现得了，就往层①或层②下沉。

步骤 3
在官方目录里找全字匹配

在浏览器里搜索官方错误参考。搜索词只用开头那一句——后半段有可能是启动方嫁接上去的（第 5 章）。

步骤 4
搜那个工具的 Issue

官方没有，该找的就不是 Anthropic 的资料。用字符串去搜你在用的那个工具的仓库 Issue。本文的出处判定也是这么做的。

7. 对照表——从文字到去处

把到这里为止的结论汇成一张表。“谁写的”这一栏，决定了这句话可以信到什么程度。

屏幕上出现的文字 谁写的 实际发生的事 去处
The model returned no content because the response was blocked by content filtering 🟡 层④
在 GitHub Copilot CLI 上被报告过的文字		 输出被过滤器拦下。不过有可能是 GitHub 一侧的过滤器（它也看与公开代码是否匹配） 输出过滤器的文章
The response was blocked by the provider's content filter ✅ 层④
OpenCode		 有三种——模型 ID 的 404、连接断开、真正的拒绝。与字面相符的只有第三种 第 3 章的区分办法
Streaming response ended before any complete data was received ✅ 层②
Claude Code 本体（官方）		 头来了，可体是空的。不是中途断掉。要怀疑链路（代理、网关） 网络与代理的文章
Could not locate the Claude CLI on PATH ✅ 层③
启动方（官方写明）		 启动方看到的 PATH 上没有 claude。CLI 本身多半是好的 command not found 的文章
Connection to Claude's response was lost. Claude may still be working 🔴 没能确定
官方目录里没有		 未确定。官方里语感相近的是 Connection lost mid-response 第 6 章的四步 与 语感相近的官方文字的文章

横着读这张表就能看出，只有层④的两行在“实际发生的事”这一栏里是摇摆的。层②与层③有官方定义，所以不摇摆。这个差别，就是“这句话可以信到什么程度”的差别。

8. 已经确定的与尚未确定的

✅ 用一手资料确认到的
  • Streaming response ended… 与 Could not locate the Claude CLI on PATH 作为条目存在于 Claude Code 官方错误参考里
  • 官方把后者放进“Wrapper and IDE errors”，说明它是由启动方程序打印的内容
  • 前者的含义是“头返回了，可体里没有 Claude API 的消息”——不是中途断掉
  • OpenCode 的 Issue #35736 报告说，404、连接断开、真正的拒绝会变成同一句话
  • GitHub 官方写明，使用 Claude 时输入与输出同样会经过 GitHub Copilot 的内容过滤器
🟡 有报告但尚未确定
  • The model returned no content because… 的出处。逐字确认到的只有 github/copilot-cli 的 Issue #3348 的标题，正文已被撤回
  • Issue #80087 提到的 VS Code 扩展回归的原因（where.exe 输出的处理方式）是报告者的推测
  • OpenCode 里是哪段代码显示出这句话，Issue 里没有写
  • “Claude may still be working”是从外面看着另一个进程的一方的说法，这一点只是从措辞推出来的
🔴 没能确认的
  • Connection to Claude's response was lost… 是哪个工具显示出来的。官方错误参考与 Remote Control 的官方文档里都没有
  • 针对 GitHub Copilot CLI 那句话的GitHub 一侧的技术说明（Issue #3348 是 closed as not planned，没有维护者的回复）
  • OpenCode 那两个 Issue 的修复完成（本文写作时都还是 open）

归纳起来是这样。从文字的外表看不出写它的是哪一层。开头那五条全都“看着像第三方工具写的”，可实际上两条是官方、两条是第三方、一条不明。所以第一件事不是推理原因，而是拿官方目录去比对。一分钟就能做完，而且它会替你定下接着该去哪里找。

FAQ

Q1. 明明在用 Claude，翻 Anthropic 的文档却找不到这句话。

这句话有可能不是 Anthropic 写的。把 Claude 当作模型来调用的工具（IDE 扩展、另一个编码智能体、经由 Copilot 使用等）各自决定失败时怎么说。请先在官方错误参考里找全字匹配，找不到就用字符串去搜你在用的那个工具的仓库 Issue。

Q2. 出现“content filter”，就说明被 Anthropic 的过滤器拦下了吗？

未必如此。GitHub 的官方文档写明，使用 Claude 时输入提示与输出补全同样会经过 GitHub Copilot 的内容过滤器。而在 OpenCode 上，与过滤器毫无关系的 404 和套接字断开也会以同一句“content filter”显示出来，这在 Issue #35736 里有报告。请把同一段提示也放到终端的 claude 上跑，用能不能复现来区分。

Q3. Streaming response ended before any complete data was received 是说连接断了吗？

不是。官方错误参考的定义是“API 返回了响应头，但体里没有装进 Claude API 的消息”。它指的是并非送到一半断掉，而是一点内容都没来的状态。请先再发一次（输入 try again 就够），如果每次都一样，就去怀疑代理、网关这一类链路。

Q4. 终端里 claude 能跑，唯独 IDE 扩展报“Could not locate the Claude CLI on PATH”。

问题不在 CLI，在启动方。官方参考把这句话归类为“Wrapper and IDE errors”——由启动方程序打印、而不是 Claude Code 自身。从图标启动编辑器时，那个进程拿到的 PATH 可能与登录 shell 组装出来的 PATH 不同。也有像 Issue #80087 这样因扩展版本产生回归的报告。

Q5. 搜不到，是因为这个错误很罕见吗？

多半是因为字符串太长。层③的文字，有时是启动方把自己的说明嫁接在官方标题后面（第 5 章的实例里，官方标题只有一句，实际显示却有四句）。请只搜开头那一句。

Q6. 不能相信文字里写的原因去处理吗？

要看是哪一层。与官方目录全字一致的文字（层②、层③）含义与处理都有文档，照着做就行。问题在层④。OpenCode 的 Issue #35736 报告说，三种完全不同的失败会变成同一句“被 content filter 拦下”。实情明明是配置写错，却信着这句话去改措辞，永远也改不好。

Q7. 不用第三方工具就没这回事了吗？

没必要做到那一步。这里谈的不是工具好坏，只是失败时那句话的出处。做法上，区分时用原生的 claude 复现一次就够。至于该选哪个工具，请参考Cursor、Claude Code、GitHub Copilot 与 Codex 的对比。

Q8. Connection to Claude's response was lost. Claude may still be working 该怎么修？

本文没能确定它的出处。Claude Code 官方错误参考与 Remote Control 的官方文档里，都没有这串字。所以写它的不是启动方就是第三方客户端，但具体是哪个工具没能确认，因此本文不点出名字。请用第 6 章的四步在自己的环境里判定。至于响应中途断掉这个现象本身，官方里语感相近的 Connection lost mid-response 的文章可以参考。

相关文章

参考的一手资料