OpenClaw CLI 在 v4.5+ 后可能卡 20 到 40 秒：为什么 Gateway 明明健康，命令行却像死了一样

最新一条 OpenClaw bug 报告指向了一个很伤运维体验的 CLI 回归问题。从 v4.5 开始，像 openclaw gateway status、openclaw sessions list 这类命令，可能会在执行时卡住 20 到 40 秒，甚至更久。更麻烦的是，按报告描述，这时候 Gateway 本身并没有真的挂掉。

来源： openclaw/openclaw#63242

对运维来说，关键不只是“命令慢”。这条报告描述的是一种割裂状态：Gateway 健康检查约 8ms 就能返回，但 CLI 会在 hooks 加载完成之后长时间停住，随后像 chat.history、models.list 这样的 RPC 调用又各自耗掉约 35 秒。

当前 issue 实际报告了什么

根据 issue 描述，现象大致是这样：

在 v4.2 这样的旧版本里，CLI 行为正常
升级到 v4.5+ 后，几乎所有 CLI 命令都明显变慢
用户能看到卡顿发生在日志 loaded 4 internal hook handlers 之后
直连 Gateway 的 health 检查依然很快
慢的不是终端渲染本身，而是后续 RPC 也一起被拖慢

报告里的环境信息包括：

OpenClaw 2026.4.5+
Node v22.22.2
WSL2 Ubuntu
npm 安装方式

为什么这不是一个“忍一忍就好”的小问题

这种问题比普通命令变慢更危险。

很多团队把 CLI 当成排障和运维时最直接的控制面，用它来做这些事：

快速确认 Gateway 是否在线
在后续操作前查看 session 列表
检查 cron 状态
验证模型是否可用
在故障处理中做即时判断

如果 Gateway 其实还健康，但 CLI 表现得像死机，运维很容易做错判断。比如：

误以为服务整体已经坏掉
过早重启一个其实还工作的 Gateway
把问题误判成网络、代理或系统负载异常

所以这类回归真正伤到的，不只是等待时间，而是 它会诱导错误的运维决策。

它和“机器整体变慢”不是一回事

这条 issue 值得关注，是因为它把两个常常会被混在一起的层次拆开了：

Gateway 健康路径还是快的
CLI 命令路径在 hooks 之后明显变慢

这意味着问题边界更可能落在下面这些层里：

CLI 启动后的 post-hook 连接流程
CLI 与 Gateway 之间的 WebSocket 建连过程
CLI 常用 RPC 方法的调用链
v4.2 到 v4.5+ 之间引入的跨版本回归

换句话说，这看起来不像“整台机器都很慢”，而更像是 命令行控制面这条链路退化了，但基础服务面还活着。

怎么确认你撞的是不是同一个故障

如果下面几条大多都成立，就很像是这次报告的同类问题：

直连 Gateway 的健康检查仍然很快
CLI 命令会在 hooks 加载后卡住
卡顿集中在 20 到 40 秒，甚至更长
日志里像 chat.history、models.list 这样的 RPC 明显耗时异常
问题是在从 v4.2 升到 v4.5+ 之后出现的

这组特征能帮你把它和一些更简单的问题区分开，例如：

Gateway 进程本身已经死了
DNS 或代理把所有请求都拖慢了
shell 配置坏掉
一次性的网络抖动
本机 CPU、磁盘、内存整体都处在高压状态

上游修复前，运维怎么止损

在上游根因更明确之前，比较稳妥的做法是：把 CLI 视为退化中的控制面，而不是唯一可信信号。

1）先单独确认 Gateway 健康

如果 CLI 像死机一样卡住，先做一次独立的 health 检查，再决定要不要重启。当前 issue 的核心恰恰就是“CLI 很慢，但 Gateway 可能没坏”。

2）把 hooks 到 WebSocket / RPC 的时间差记下来

重点记录这几个时间点：

hooks 加载完成
WebSocket 开始连接
RPC 方法返回

这类时间轴，比一句“CLI 很慢”更能帮助上游定位问题。

3）业务路径没坏时，不要急着 panic restart

如果 API、自动化任务或健康检查仍然正常，贸然重启反而可能把关键现场抹掉，让后续更难诊断。

4）有条件的话，拿旧版本做一次对照

既然报告明确指出是从 v4.2 到 v4.5+ 的回归，对照一个已知正常版本，通常是确认同类问题最快的方法之一。

这件事更大的运维启示

这条报告最值得记住的一点其实很朴素：CLI 延迟，不等于 Gateway 已死。

如果后面有更多人复现这个问题，团队最好把 runbook 改一下，不要把一条卡住的 CLI 命令直接当成“平台已挂”的唯一证据。

更稳妥的排障顺序应该是：

先看 Gateway 健康
再对比 CLI 时延与 endpoint 时延
再抓 RPC 耗时细节
最后再判断问题是在服务面、传输面还是 CLI 面

值班时的快速决策树

如果你在值班窗口里碰到 CLI 卡住，不要直接把它当成 Gateway 已挂。更稳的分流顺序是：

health endpoint 仍然很快，但 CLI 在 hooks 后卡住
- 先把它当成 CLI / RPC 链路回归，而不是整站故障。
- 优先保留时延证据，而不是立刻重启 Gateway。
health、业务请求、自动化任务也一起变慢或失败
- 这时问题面更大，不该再只盯 CLI，应该改查宿主机、网络或更上游服务面。
只有升级到 v4.5+ 后才出现
- 优先验证版本回归边界，必要时用 v4.2 或已知正常版本做对照。

宣布事故结束前，还要补验什么

即便你已经让 CLI 恢复可用，也别只跑一条命令就结束。至少还要补验这四件事：

openclaw gateway status 或 openclaw sessions list 的时延已经恢复到可接受范围；
同一时间窗里的 direct health check 仍然稳定快速；
一条真实值班关键命令或 agent 相关命令可以正常跑完，不再卡在 hooks 后；
事故记录里已经保存卡顿命令样本、health 对照时延、受影响版本和日志锚点。

如果你已经确认是 CLI 回归，下一步最值得点哪两个入口

如果这页已经帮你判断出问题更像 CLI / RPC 链路回归，而不是 Gateway 真挂了，下一步最值得继续点的通常是这两个入口：

先看 OpenClaw Agents 排障指南：任务卡住、工具不回、结果异常时先查什么，确认是不是还叠加了工具调用、权限、provider 或消息链路异常；
如果你怀疑症状里还混着 runtime 或 provider 选择错乱，再看 Codex OAuth 登录成功但运行时仍回退默认配置，避免把运行时路由残留误判成纯 CLI 卡顿。

这样做的意义，是把“CLI 很慢”继续分流成更具体的下一跳，而不是让用户处理到一半又回搜索结果页重新找路。

决策矩阵：该重启、回滚，还是继续留证据？

CLI 在 hooks 后卡住时，下一步不应该靠直觉，而应该看哪条信号还健康：

Gateway health 很快，但 CLI RPC 很慢：先保留 Gateway 现场，记录 hooks 到 RPC 的耗时，不要默认重启。
问题紧跟 v4.5+ 升级出现：优先做灰度回滚或版本对照，不要把整个值班窗口都耗在宿主机资源图上。
health、自动化路径、CLI 命令全都慢：扩大事故边界，因为这已经不像本文描述的窄口径 CLI 回归。
只有某个 shell profile、插件包装或单台机器复现：先查本地 wrapper 与环境漂移，再决定是否升级成平台级故障。

这张矩阵对搜索入口尤其重要，因为它把“OpenClaw CLI 卡住”这种模糊症状，直接分流成三类动作：留证据、回滚版本，或扩大故障面。

结论

OpenClaw issue #63242 值得持续关注，因为它打到的是高价值运维场景，也就是故障处理中最依赖的命令行控制能力。

如果你的 CLI 在升级到 v4.5+ 后开始在 hooks 加载后长时间卡住，不要立刻认定 Gateway 本身已经失效。按当前报告，更像是命令行链路出现了回归，导致服务还活着，但 CLI 已经慢到接近不可用。

常见判断问题 FAQ

如果 `openclaw gateway status` 很慢，但 health endpoint 还是快的，第一反应该是什么？

第一反应不该是“Gateway 肯定挂了”，而应该是先把它当成 CLI 控制链路退化 来看。

因为按当前报告，这类问题的危险点正是：

health 还活着
Gateway 可能还在正常服务
但 CLI 卡得像整个平台死了一样

值班上最容易犯的错，就是把一个慢 CLI 误判成必须立刻重启的服务事故。

什么时候更该回滚版本，而不是继续盯宿主机资源？

如果你已经确认 health endpoint 仍然很快、自动化任务没有整体瘫掉，而问题又明确出现在从 v4.2 升到 v4.5+ 之后，那比起继续盯 CPU、磁盘或 WSL2 本机资源，更该优先把它当成版本回归来处理。尤其当 openclaw gateway status、openclaw sessions list、models.list 这类命令都在同一时间窗里变慢时，继续只查宿主机资源，往往会浪费你的值班窗口。

这时最稳的下一跳通常是两步并行：一边回看 OpenClaw Agents 排障指南：任务卡住、工具不回、结果异常时先查什么，确认是不是别的 Agent、Gateway、provider 或权限问题叠加；另一边再对照 Codex OAuth 登录成功但运行时仍回退默认配置，避免把 provider 优先级错乱、运行时配置残留误判成纯 CLI 性能回归。

如果下面几条同时成立，就更该优先验证版本回滚：

升级到 v4.5+ 后才出现
旧版本如 v4.2 没有同类现象
health 检查仍然快
慢点集中在 hooks 后和 RPC 上

这组信号比“宿主机突然全面变慢”更像版本级回归。

搜 `loaded 4 internal hook handlers 后卡住` 的人，页面最该先帮他判断什么？

最该先判断三件事：

Gateway health 是不是依然快
卡顿是不是集中在 hooks 之后
这是版本升级后出现，还是机器本来就一直慢

这三步能最快把用户分流到“CLI/RPC 路径回归”还是“更大范围的服务故障”。

一线支持在升级故障单前，最该先收哪三类证据？

至少先收一条命令样本、一组时延对照、一个版本分界点：

哪条命令卡住了，比如 openclaw sessions list
同一时间窗里 direct gateway health 是否仍然很快
卡顿是不是从升级到 v4.5+ 后才开始出现

这组信息足够帮助支持同事先判断，它更像版本回归，还是更广泛的宿主机 / 网络问题。

为什么这页值得继续扩写，即使当前单页流量还不高？

因为它对应的是很强的高意图搜索。

会搜 openclaw loaded 4 internal hook handlers 卡住、openclaw gateway status 很慢但 health 正常 这类词的人，通常已经在真实值班或排障现场里。只要页面能帮他们快速分清“CLI 卡死”和“Gateway 真挂”，它就比泛泛的更新日志更有机会吃到长期排障流量。

如果团队今晚还要靠 CLI 值班，最稳妥的立即止损动作是什么？

如果今晚还需要继续用命令行做值班判断，最稳妥的短期动作通常是 先把决策依据切回 direct health check 和已知正常旧版本，再决定要不要做大范围重启。

这样做的核心价值，是先保住今晚还能用的控制面，避免一个“只是 CLI 变慢”的问题把整个值班动作带偏。

准备回滚或 pin 回旧版本前，最该先留哪组证据？

在回滚前，至少留一组小型对照证据：

一条已经卡住的代表性命令，比如 openclaw gateway status
同一时间窗下对应的 gateway health 耗时
当前受影响版本和最后一个已知正常版本
一段显示卡在 loaded 4 internal hook handlers 之后的日志片段

这组证据通常已经足够支撑内部回滚判断，也方便后面等上游修复后再做复测对比。

在把锅直接甩给 hooks 之前，团队最该先查什么？

loaded 4 internal hook handlers 这行日志很关键，但它更像一个时间锚点，不等于已经证明 hooks 就是根因。

在让团队直接移除 hooks、停用 hook 逻辑或重写 hook 前，更该先查三条更窄的边界：

卡顿是刚好发生在 hooks 加载后，还是只在 WebSocket / RPC 真正开始后才出现
同一套 hooks 在 v4.2 是否正常，而在 v4.5+ 才开始明显变慢
health 路径是否仍然很快，但命令传输链路已经变慢

如果这三条同时成立，那 hooks 更可能只是最后一条可见日志，而不是最终根因。这里的结论会更接近 CLI 传输链路回归，而不是“自定义 hooks 写坏了”。

这页还应该覆盖哪些搜索问法

openclaw loaded 4 internal hook handlers 后卡住
openclaw gateway status 很慢但 health endpoint 正常
openclaw sessions list 升级后要 30 秒
openclaw v4.5 hooks 后 cli 卡死
openclaw models.list 35 秒才返回
openclaw chat.history 很慢但 gateway 正常

如果你是从 2026.3.13 发布说明跳过来的

这页现在和 2026.3.13 发布说明处在同一组 GA4 小流量入口里，但它回答的是另一个问题。这里应该被当作事故分诊页，而不是泛泛的升级摘要。

继续留在这页：如果症状是 hook loading 后卡 20-40 秒、gateway status 慢、sessions list 慢，但直接 health check 仍然很快。
回到 2026.3.13 发布说明：如果你还在判断登录态 Chrome attach、批量 browser action、有界 gateway timeout 是否值得采用。
两页一起对照：只有在已经记录版本、hook 数量、Node 版本和一条明确变慢命令之后再做，否则很容易把发布评估和 on-call 回归混在一起。

这个分流能让搜索访客更快点到下一步：发布采用判断留在 release note，命令路径延迟证据留在这页。

临时恢复后，先留一份 4 点复盘证据

如果你通过重启、回滚或禁用 hooks 暂时恢复了 CLI 响应，不要立刻把事故关掉。建议先留下这 4 个证据点：

恢复动作：写清是重启 CLI、回滚版本、禁用某个 hook，还是切换到另一台机器。
恢复前后耗时：记录同一条命令在恢复前后的耗时，避免只凭体感判断 20-40 秒卡顿已经消失。
hook 边界：标出哪些 hook 仍然启用、哪些被临时关闭，方便后续判断是 hook 本身慢，还是 hook 加载后的某段初始化慢。
复发触发点：记录下一次卡顿发生在冷启动、首次模型调用、目录切换，还是每条命令都会复现。

这份复盘证据能把“CLI 又能用了”变成可追踪的性能恢复结论，也能帮助读者在搜索 loaded 4 internal hook handlers hang 时直接判断下一步是回滚、继续留证，还是升级到更稳定版本。

把 CLI 回归流量导向一个负责人动作

证据包留好后，不要只在群里停留在“CLI 很慢”这类描述。建议马上指定一个负责人动作：

版本负责人：对比受影响版本和最后一个快版本，决定是临时 pin 住旧版，还是等上游修复后再前滚。
运维负责人：把 health check、direct gateway check 和 CLI 耗时拆开记录，避免因为 CLI 慢而重启本来健康的服务。
支持负责人：把命令、版本、hook 边界、恢复前后耗时贴到上游 issue 或内部事故单里。

这样这篇页承接高意图搜索流量时，不只给诊断，还能把读者推到明确的升级、运维或支持动作。

90 秒值班分流：先保 CLI，还是先保服务？

如果 direct 或搜索流量进到这里，读者通常不是来了解新闻，而是在值班窗口里判断下一步。先按影响面分流：

只有 CLI 在 hook loading 后慢，服务 API 和 Gateway health 仍正常：先保留证据，避免把问题扩大成全站重启。
CLI 慢同时影响自动化任务交付：临时 pin 回已知稳定版本，并记录第一条变慢命令。
CLI、Gateway、Web UI 同时异常：这已经不是单页 CLI 回归，直接进入总排障路径并升级为运行事故。

这段分流的目标是减少误操作：把性能回归、服务中断和升级评估拆开处理。

给搜索访客的 6 条命令证据包

如果你准备把这次 CLI 卡顿升级给维护者，先不要只写“很慢”。把下面 6 条证据复制到 issue、群聊或内部值班记录里，后续判断会快很多：

openclaw --version：确认是否刚从 v4.2、v4.3 升到 v4.5+；
time openclaw gateway status：记录卡在 hook loading 前后各耗时多少秒；
curl -s -o /dev/null -w "%{http_code} %{time_total}\n" <health-url>：证明 Gateway health 是否仍然快；
同一台机器上一个无关命令的耗时，例如 time node -v 或 time git status；
最近一次升级、重启、模型配置或插件配置变更时间；
是否只有 CLI 慢，还是 Feishu/Discord/API 自动化也同时慢。

这组证据能把“感觉卡住”变成可复现的性能回归线索，也能避免读者把一个 CLI hook 问题误升级成整站事故。

事故单里的 5 行决策日志

CLI 性能回归最怕留下很多命令输出，但没有明确决策。建议在事故单或 issue 里补一段 5 行日志：

判定：这是 CLI 传输慢、hook 初始化慢、还是 Gateway / Web UI 同时异常。
范围：影响哪些机器、哪些版本、哪些自动化任务。
临时策略：pin 旧版、禁用某个 hook、等待上游，还是继续采样。
恢复条件：同一条命令低于多少秒，连续多少次才算恢复。
回看时间：下一次检查版本、日志和公网 issue 的时间点。

这 5 行能让读者从“我收集了证据”进入“我知道该怎么收口”。对搜索流量来说，这比再多贴一条慢命令更有用。

下一步优先覆盖的精确搜索词

这页已经进入最新 GA4 高意图入口，下一步增长重点不是泛泛扩写，而是覆盖值班现场会直接搜索的长尾症状：

openclaw loaded 4 internal hook handlers 卡住
openclaw gateway status 很慢 health 很快
openclaw sessions list 35 秒 models.list
openclaw cli v4.5 升级后变慢

这些搜索背后的真实问题很直接：先把 CLI 启动延迟、Gateway health、RPC 耗时拆开，再决定要不要重启。如果只有 CLI 链路慢，优先留证据并对照已知正常版本，不要直接把 Gateway 判死。

从 CLI hang 流量转成性能回归定位清单

如果你是因为 OpenClaw CLI 在 hook loading 后卡 20 到 40 秒搜到这里，先不要只重装依赖。要把启动路径拆成四个时间点：命令入口、hook discovery、插件初始化、以及首个 agent/runtime 调用。每一段都单独计时，才能判断是本地 shell、插件扫描、网络认证还是 runtime 初始化导致的等待。

最小定位清单包括：一次带时间戳的启动日志、当前 Node/pnpm 版本、启用的 hooks 或 skills 列表、以及禁用插件后的对照启动时间。这样 CLI 性能流量会被引导到“可复现 benchmark、降级开关、团队升级阻断评估”三类高意图入口，而不是停在笼统的卡顿描述。

FAQ：CLI 很慢但 Gateway health 正常时怎么判断

`gateway status` 慢，是不是就该重启 Gateway？

不一定。如果 direct health check 很快，而只有 CLI 命令在 hook loading 后等待 20 到 40 秒，更像 CLI 启动、hook 初始化或本地插件扫描问题。先记录同一条 CLI 命令耗时和 health URL 耗时，不要把健康服务误重启成新事故。

如何判断是本地机器慢，还是 OpenClaw 版本回归？

至少做两个对照：同机运行 node -v、git status 这类无关命令确认 shell 没整体变慢；再在同配置下对比上一个已知快版本。如果只有 OpenClaw v4.5+ 命令变慢，且慢点集中在 hook loading 后，才更像版本级性能回归。

团队临时止损应该优先 pin 版本还是禁用 hooks？

先选影响面最小的动作。单机或单团队复现时，优先 pin 到最后一个快版本并保留慢版本证据；如果已经定位到某个 hook 或 skill 扫描异常，再临时禁用它。不要同时改版本、配置和 Gateway，否则后续很难归因。

CLI 卡住 20 秒时，先量 hook loading 而不是重装

遇到 openclaw CLI 每次启动都慢 20 到 40 秒，第一反应不应该是重装依赖。更稳的做法是先把耗时拆成三段：shell 启动、OpenClaw hook loading、真实命令执行。只有确认等待发生在 hook loading 之后，才继续追配置加载、插件扫描或网络初始化。

建议现场保留三类证据：

同一命令在冷启动和第二次运行时的耗时差异；
加 time 或 debug 日志后，停顿点是否稳定落在 hook loading 附近；
临时禁用非必要 plugin / skill / startup hook 后，启动时间是否明显恢复。

这能承接 “OpenClaw CLI slow after hook loading”“openclaw command hangs 20 seconds”“CLI performance regression” 这类搜索意图，把读者从盲目清缓存引到可复现的性能分层。

来源

Bug 报告： openclaw/openclaw#63242