Claude Code 部分执行后卡死：分清「上下文压缩 / 工具挂 / 流断」

Q: 为什么 Claude Code 只做了一部分就停了、还不报错？

三种原因最常见：auto-compaction 在任务中途把 plan 丢了、某个 bash 工具调用挂过了超时、或流式响应断了但后端还在跑。先用 `git diff` 看活儿是不是真没完，再对照上面的表格判断属于哪种形态。

Q: 重启 Claude Code 会不会丢我的活儿？

通常不会。`claude --continue` 重载你最近一次 session，`claude --resume` 让你从列表里挑一个，两者都会恢复你攒下来的上下文。不管怎样，先 commit 一个 WIP checkpoint（`git add -A && git commit`），让已完成的改动稳妥保存。

Q: `Esc` 和 `Ctrl+C` 都停不下来，怎么强制退出？

工具调用进行中时，打断是已知薄弱环节。快速连按两下 `Ctrl+C`。如果整个 CLI 都卡死，用 `ps aux | grep claude` 找到 PID、`kill -9 `，再用 `claude --continue` 重启。

Q: 怎么让 Claude Code 别在 2 分钟就 kill 掉我的长跑命令？

在 `~/.claude/settings.json` 的 `env` 块里加 `BASH_DEFAULT_TIMEOUT_MS`（必要时再加 `BASH_MAX_TIMEOUT_MS`），然后重启。shell 里 export 会被忽略，而且硬上限约 10 分钟——比这更长的，就自己跑、再把输出喂回去。

Q: `/compact` 是干什么的，要不要手动跑？

`/compact` 会摘要 session 历史以释放 context，同时保留一段回顾。在干净 checkpoint 主动跑它，能避开那种会把你 plan 丢掉的中途 auto-compaction。想彻底重置、不带任何历史时，改用 `/clear`。

Claude Code 做完 60% 就没声了——不报错也没完成消息。判断属于三种形态（context 压缩、工具挂、流式断开）中的哪种，不重做活儿地恢复。

发布于: 2026/05/17 更新于: 2026/06/15 作者: AI Productivity Guide Team 🌐 查看英文版本

Claude Code 打了 5 步任务的第 1、2、3 步——然后没了。没报错、没”我做完了”，就剩转圈提示 esc to interrupt 或一个闪烁光标。等 60 秒，再等一分钟，还是没动静。活儿没完，agent 没说为什么停，重新 prompt 它只走到第 4 步，又卡在第 5 步。

最快路径： 先按 Esc（或快速连按两下 Ctrl+C）打断当前这一轮、又不丢 session，然后输入一句简短的 continue from where you stopped。如果几秒内毫无反应，说明这一轮是真卡住了——跑 git status 看实际落了哪些改动，kill 掉挂住的工具进程，再用 claude --continue 重启（或 claude --resume 从列表里选 session）。活儿通常在 server 侧还在，你要做的就是确认哪些已完成、然后接着做、别重做。

「部分执行后卡死」有三种不同形态、修法各异：上下文压缩（agent 摘要了自己的历史、把 plan 弄丢了）、工具挂（pnpm test 之类的 Bash 调用没返回）、流式断开（响应停在你的终端这边，但后端还在跑）。不要硬撑 stuck session——分清是哪种形态、存好状态、从一份新的 STATUS.md 重新接上。

你属于哪一种？

症状	最可能的原因	第一步
session 很长、工具调用很多，卡之前 token 计数已经接近顶	context 接近满 / auto-compact 抖动	`/compact`，或 `claude --continue` 重启
卡之前最后可见动作是某个具体命令（测试、构建、dev server）	工具挂（bash 超时 / 等不存在的 callback）	kill 掉进程，再按 `Esc` 接着跑
冻住前正好赶上网络抖动、VPN 重连、笔记本休眠	流式断开	连按两下 `Ctrl+C`，再 `claude --continue`
`git diff` 显示活儿其实做完了，只是缺了「完成」消息	最终消息被截断	什么都不用做——它完成了，确认一下即可
转圈没了但新输出停了 `< 60s`	可能还在推理	等满 60 秒再判它是不是卡死

常见原因

按命中率从高到低排。

1. context 接近满，auto-compaction 把 plan 弄丢了

context 接近满时，Claude Code 会自动压缩（auto-compact）自己的对话历史——截至 2026 年 6 月，触发点大约在窗口的 95%（剩约 25% 余量）。超过 ~80% 还会出现”伪卡死”：响应慢到爬、token 计数蠕动，看着像挂了其实没有。压缩如果发生在任务中途，正在执行的 plan 可能被摘要掉——agent 做完它还”记得”的部分就不输出了，因为在压缩后的视角里任务已经完了。

如何判断：卡之前 session 很长、工具调用多，context 进度条已经接近顶。/clear 重开（或对一个已压缩再重启的 session 用 claude --continue）后，同一个 prompt 能跑完——说明卡的是 context 不是任务本身。

修法：在进度条满之前、在一个干净的 checkpoint 自己跑 /compact，并通过在 CLAUDE.md 里加一段简短的 # Compact Instructions 来引导它保留什么（例如：“Always preserve the current task plan and which steps remain”）。大任务可以在干净点 fork，让原 session 永远不必压缩。

2. 工具调用挂了，agent 等一个永远不来的 callback

pnpm test 启动了但永远不返回（测试 setup 死循环、卡住的 dev server、watch 模式那种永不退出的命令）。Claude Code 的 bash 层阻塞着等命令结束，所以没输出到你这边。注意默认上限：截至 2026 年 6 月，Claude Code 默认会在 2 分钟后 kill 掉一个 bash 命令（除非你调高），但 watch / serve 类命令往往在超时触发前就把这一轮卡死了，而且 bash 超时无论怎么配都有个约 10 分钟的硬上限。

如何判断：最后可见动作是某个具体命令。看进程：ps aux | grep -E "node|python|pnpm|vitest"。如果有一个活着却不干活（无 CPU、输出不增长），就是它。

修法：kill 掉它（见下面 Step 3）。要防止复发，别让 Claude 直接跑 watch / serve 命令；对确实慢的命令，在 ~/.claude/settings.json 里调高默认值：

{
  "env": {
    "BASH_DEFAULT_TIMEOUT_MS": "300000",
    "BASH_MAX_TIMEOUT_MS": "600000"
  }
}

BASH_DEFAULT_TIMEOUT_MS 设默认值（这里 5 分钟）；BASH_MAX_TIMEOUT_MS 是上限。改完要重启 Claude Code 才生效。这两个必须放在 settings.json 的 env 块里——shell 里 export 会被 Claude Code 内部的超时机制忽略，而且无论怎么配上限都封在约 10 分钟。

3. 流式连接静默断了

WiFi 抖动、VPN 重连、笔记本休眠——把 server 的流式响应切断了。Claude Code 的 HTTP 客户端没有读超时机制，所以上游一旦中途停发包，进程就一直干等永远不会来的数据。后端这时可能还在跑，你只是看不到输出了。这是一类已知 bug（某个最终流事件在状态切换时被丢掉，导致请求既不 resolve 也不 reject），所以即便网络稳定也可能发生。

如何判断：冻住的时间点正好对上某个网络事件，或者转圈卡住、连 Esc 都没反应。

修法：连按两下 Ctrl+C 强制停掉这一卡住的轮次，然后 claude --continue 重载上一次对话，或 claude --resume 从列表里选。server 侧状态通常能让活儿接着干。

4. agent 的 plan 自然结束，但实际没完

agent 内部是 3 步 plan，你要的是 5 步。第 3 步后它认为完了就不输出了。Plan 和现实分叉。

如何判断：问它 Did you complete the task? List the remaining steps.。它说”是”但你看到没完成——说明它的 plan 比你的小。

修法：把完整的验收标准明确再说一遍（“任务只有在 X、Y、Z 全部通过时才算完成”），让它内部的 plan 对齐真实范围。

5. 结尾「完成」消息被截断

某个流上限剪掉了 Claude Code 的最终总结。代码应用了，你没看到收尾。agent 真完了，你不知道而已。

如何判断：git status 和 git diff 显示活儿确实做完了——卡死只是呈现问题，不是真停了。

6. 长推理 vs 真挂——重启前先分清

某些 extended-thinking 步骤会跑 30 秒以上、不出 token。过早重启就把在跑的活儿扔了。

如何判断：没输出先等满 60 秒再判 stuck。客户端如果还显示 “thinking” 指示或 esc to interrupt 提示，模型还在跑。（注意：工具调用进行中时，Esc / Ctrl+C 打断是已知薄弱环节，第一下可能不响应——多按一下。）

最短修复路径

按收益从高到低。Step 1 诊断形态，对应修法就出来了。

Step 1：先尝试打断，再诊断

1. 按 Esc，或快速连按两下 Ctrl+C，停掉当前这一轮、又不丢 session。
   然后输入：continue from where you stopped。
2. 几秒内没反应，跑 /doctor 做一次内建健康检查。
3. 跑 `git status` 和 `git diff`——活儿**真的**没完吗？
4. 看进程：ps aux | grep -E "node|python|pnpm|vitest"——有挂的吗？
5. 看 top / 活动监视器——有什么在烧 CPU 吗？

如果 diff 显示没完 + 进程空闲 + 60 秒以上无输出——真卡了。

Step 2：重启前存状态

# 快速 checkpoint commit
git add -A && git commit -m "wip: stuck during step N"

# 写本来下一步该做什么
cat > STATUS.md <<EOF
Task: <一句话>
Done: steps 1-3（改了文件 A、B、C）
Remaining: steps 4-5（要改 D、E）
Last action visible: <Claude 当时在做什么>
EOF

这是你的 resume 点。盲重启的代价比花两分钟写这个高得多。

Step 3：必要时 kill 挂住的进程

# 找挂住的工具进程
ps aux | grep -E "node|python|pnpm|vitest" | grep -v grep

# kill 孤儿（替换 PID）
kill -9 <PID>

# 需要时凶猛清理
pkill -9 -f vitest
pkill -9 -f "pnpm test"

kill 掉挂住的工具后 session 解锁——你就找到了原因，记下以后别让 Claude 直接跑这条命令（尤其是 watch / serve 类）。

Step 4：用 session + STATUS.md 作 handoff 重启

接续之前的对话，而不是从零开始：

claude --continue          # 重载最近一次 session
# 或
claude --resume            # 从交互列表里选 session

然后把快照交给它：

Read STATUS.md and pick up the task.
Verify against `git log` what's already committed.
Do not redo completed work. Start from "Remaining".

如果原因本来就是 context，先跑 /clear 再从 STATUS.md 重新开始，免得旧 plan 残留。

Step 5：同一步反复卡就拆它

某一步反复 stall，通常是它太大或含一个有问题的子任务。拆开：

原 step 5："Update all consumers and run integration tests"

拆成：
  5a: 更新 src/api/users.ts 里的 consumer。停。
  5b: 更新 src/api/orgs.ts 里的 consumer。停。
  5c: 跑 `pnpm test src/api/users.test.ts`。停。
  5d: 跑 `pnpm test src/api/orgs.test.ts`。停。

每个子步都小到不会触发那个失败模式。

Step 6：工具挂就你自己先跑

pnpm test 在 Claude 那里一直挂——你自己在另一个终端跑一次。跑通后告诉 Claude 跳过这一步、直接用你给的结果：

我自己跑了 `pnpm test`，输出如下。
用这份输出，不要自己跑测试命令。

[贴]

这是绕开不可靠工具、又不用中途放弃 agent 的办法。

怎么确认已经修好

以下全部成立才算真的不卡了：

git status / git diff 显示任务要求的每个文件都改到了。
你预期要跑的构建 / 测试确实跑了并通过了（不确定就自己跑一遍）。
新开一句 prompt——List anything still incomplete from STATUS.md——返回为空。

任一条不成立，说明你接到了旧 plan 上；用 /clear 加一份新的 STATUS.md 重做 Step 4。

预防建议

每个大步之后，让 Claude 更新 STATUS.md——三种 stuck 形态它都能扛过去。
主动在干净 checkpoint 跑 /compact，别等 auto-compaction 在 95% 附近自己触发。
在 CLAUDE.md 里加一段 # Compact Instructions，让它在压缩时保留任务 plan。
任务控制在大约 1 小时的预期 agent 时间内——小 checkpoint 更耐操。
在稳定网络上跑——移动热点是流式连接的隐形杀手。
别让 Claude 直接跑 watch / serve 命令，把测试和 edit 分开。
对确实慢的命令，在 ~/.claude/settings.json 里调高 BASH_DEFAULT_TIMEOUT_MS，免得卡在 2 分钟默认值上被 kill。

常见问题

为什么 Claude Code 只做了一部分就停了、还不报错？ 三种原因最常见：auto-compaction 在任务中途把 plan 丢了、某个 bash 工具调用挂过了超时、或流式响应断了但后端还在跑。先用 git diff 看活儿是不是真没完，再对照上面的表格判断属于哪种形态。

重启 Claude Code 会不会丢我的活儿？ 通常不会。claude --continue 重载你最近一次 session，claude --resume 让你从列表里挑一个，两者都会恢复你攒下来的上下文。不管怎样，先 commit 一个 WIP checkpoint（git add -A && git commit），让已完成的改动稳妥保存。

Esc 和 Ctrl+C 都停不下来，怎么强制退出？ 工具调用进行中时，打断是已知薄弱环节。快速连按两下 Ctrl+C。如果整个 CLI 都卡死，用 ps aux | grep claude 找到 PID、kill -9 <PID>，再用 claude --continue 重启。

怎么让 Claude Code 别在 2 分钟就 kill 掉我的长跑命令？ 在 ~/.claude/settings.json 的 env 块里加 BASH_DEFAULT_TIMEOUT_MS（必要时再加 BASH_MAX_TIMEOUT_MS），然后重启。shell 里 export 会被忽略，而且硬上限约 10 分钟——比这更长的，就自己跑、再把输出喂回去。

/compact 是干什么的，要不要手动跑？ /compact 会摘要 session 历史以释放 context，同时保留一段回顾。在干净 checkpoint 主动跑它，能避开那种会把你 plan 丢掉的中途 auto-compaction。想彻底重置、不带任何历史时，改用 /clear。