acpx 0.4.x 可能让 Claude ACP 会话“静默创建失败”：怎么确认、为什么危险、当前最稳的回退办法

OpenClaw 最新一条 bug 报告指向了一个比“直接报错”更麻烦的故障形态：[email protected] 和 [email protected] 可能表面上执行成功，但实际上根本没有创建出 Claude ACP session。

来源 Issue： openclaw/openclaw#60970

对运维和内容自动化来说，最危险的不是“创建失败”本身，而是它会伪装成一种很像“看起来没问题”的状态：命令 exit code 为 0、没有报错、没有输出，但 sessions list 仍然是空的，网关日志里只留下 ensureSession returned no events。

这种静默失败很容易把排障方向带偏。

当前报告到底在说什么

根据 issue 描述，故障链路大致如下：

执行 acpx claude sessions new --name test
命令正常退出，但没有返回 session ID
再执行 acpx claude sessions list
输出仍然是 No sessions
OpenClaw 侧如果通过 sessions_spawn(runtime: "acp", agentId: "claude", ...) 发起任务，也会因为拿不到有效 session 标识而失败
把 acpx 从 0.4.x 回退到 0.3.1 后，行为立即恢复正常

报告环境包括：

Ubuntu 24.04
OpenClaw 2026.4.2
Claude Code 2.1.92
使用 OAuth 登录，权限范围覆盖 Claude Max 的 session 能力

同时，报告还指出：直接运行 Claude Code 是正常的。这一点非常关键，因为它能帮助你缩小故障边界。

为什么这不是“小问题”

这不是一个无关痛痒的 CLI 细节。

很多 OpenClaw 部署会把 ACP session 创建当成前置入口，用在：

线程绑定的 Claude Code 工作流
通过 sessions_spawn 拉起的一次性 ACP 任务
需要后台实现、修复、出结果的自动化流程
任何“先建 session，再往里投任务”的编排模式

一旦创建阶段静默失败，团队往往会先怀疑这些方向：

Claude 登录坏了
OpenClaw 路由错了
sessions_spawn 参数写错了
网关偶发异常

但如果真正坏掉的是 acpx 0.4.x 的 session 创建路径，那你在错误层上花再多时间都很难快速恢复。

它和其他 ACP / session 类故障不是一回事

站内之前写过一些 ACP / session 相关问题，但这次的断点不同。

这次报告打的是创建阶段，不是：

任务已经跑完，但 sessions_history 暂时看起来为空
session 空闲超时后，sessions_send 很难重新唤起
transcript 已经落盘，但 API 投影层还没跟上

换句话说，这次不是“已经有 session，但展示或恢复链路出问题”，而是：session 可能从一开始就没有被成功创建成可用对象。

这会直接改变你的排障顺序。

快速确认：先别猜，按这 3 步看

1）先确认 session 到底有没有真的被创建出来

直接跑：

acpx claude sessions new --name test
acpx claude sessions list

如果前者 exit 0 但没有返回 session ID，后者仍然显示 No sessions，那就更像是真实的创建失败，而不是 UI / API 展示延迟。

2）对照网关日志，确认是不是“没收到 session 事件”

issue 中给出的典型日志是：

[plugins] acpx ensureSession returned no events after sessions ensure
[plugins] acpx ensureSession returned no events after sessions new

如果你也看到类似模式，说明 OpenClaw 网关很可能没有从 ACP backend 那里拿到它期望的 session 事件。

3）把“Claude 可用”与“acpx 建 session 可用”分开看

报告里一个很有价值的信息是：直接跑 Claude Code 没问题。

这意味着你可以这样分支判断：

如果 Claude 直连可用
但 acpx claude sessions new 建不出 session

那更应该怀疑的是 acpx 的 session bootstrap / creation 路径，而不是泛化成“Claude 整体登录坏了”。

当前最稳的止血办法：回退到 0.3.1

根据现有报告，最低风险、最容易复现成功的 workaround 很明确：

npm install -g [email protected]

然后确保 OpenClaw ACP 插件里的期望版本与之匹配，再按你的常规变更流程重启网关。

实话说，在这种“新版本静默失败、旧版本立刻恢复”的场景里，优先回退通常比现场硬修更稳。

可能的根因边界在哪里

当前 issue 还不能证明精确根因，但它已经给了一个很有用的排查边界。

从现象看，问题大概率落在这些环节之一：

acpx 0.4.x 调起 Claude Code 的方式变了
它等待 / 解析 session 事件的方式变了
它在 session bootstrap 时引入了对 OAuth 环境不友好的启动参数
它把“子进程退出成功”错误地等价成了“session 创建成功”

报告里还特别提到一个线索：如果 0.4.x 在底层引入了类似 --bare 的运行方式，就可能影响 OAuth 登录态。

但这一点目前还只是线索，不该当成既定事实。

回退到 `[email protected]` 前，先做 4 个判断

如果你是从搜索进来，最容易卡在“要不要马上回退”这个决策点。建议先用下面四个信号判断，不要把所有 Claude ACP 异常都直接归因到 0.4.x。

信号	更像当前问题吗	建议动作
直接运行 Claude Code 正常，但 `acpx claude sessions new` 没有可用 session	是	优先回退到 `[email protected]` 止血
`acpx claude sessions list` 一直为空，网关出现 `ensureSession returned no events`	是	先确认 session 创建链路，再补 issue 证据
Claude CLI 自己也登录失败或 OAuth 循环	否	先修 Claude 登录态，不要急着回退 acpx
session 已经创建，只有 history API 看起来为空	否	转向 transcript / history 投影问题

这张表的价值，是把值班决策从“凭感觉回退”变成“按入口是否建成来判断”。只要 session 创建入口没建出来，后续 prompt、路由、history 排查都很可能是在错误层上耗时间。

如果你也中招，反馈时最好补这些证据

如果要去 issue 下补充“我也复现了”，建议别只留一句 me too。更有价值的是这些信息：

acpx --version
OpenClaw 版本
Claude Code 版本
直接运行 Claude CLI 是否正常
acpx claude sessions list 的实际输出
网关里 ensureSession 附近的日志
回退到 [email protected] 后是否恢复

这组证据能帮助维护者更快判断：大家遇到的是不是同一个断点。

结论

如果你的 Claude ACP 工作流在升级到 acpx 0.4.x 后突然“启动不起来”，先不要急着把问题归咎于 prompt、路由配置，或者 OAuth 本身。

从当前报告看，更值得优先怀疑的是：acpx 0.4.0 / 0.4.1 的 session 创建路径本身就可能存在静默失败。

在上游确认或修复前，回退到 [email protected] 仍然是目前最务实、最稳的恢复方案。

面向搜索入口的对比判断：ACP session 根本没建出来，还是 run 已存在但 history 看起来是空的

这两类故障很容易被混成一句“Claude ACP 没反应”。但它们的排障分支完全不同，混着查只会拖慢恢复。

更该判断成session 创建失败的信号包括：

acpx claude sessions new 退出了，但没有返回可用 session ID
acpx claude sessions list 依然看不到活动 session
网关日志里出现 ensureSession returned no events

更该判断成已有 session 但可见性/投影异常的信号包括：

任务其实已经执行过
transcript 文件已经落盘
看起来为空的是 sessions_history 之类的投影 API，而不是创建动作本身

这也是搜索意图上的关键区别。搜 acpx 0.4 session 没建出来 的人，通常不是想补看 transcript，而是在判断编排入口本身是不是已经坏了。

缓解后，下一位值班同事至少要接到什么

故障止血后，建议交接里最少写清这四项：

具体是哪个 acpx 版本出问题，回退到哪个版本后恢复
故障期间直接运行 Claude Code 是否仍然正常
一条能代表故障模式的 ensureSession 日志或 CLI 输出
回退后 OpenClaw ACP 流程是不是立刻恢复，还是还需要额外重启一次网关

这条交接的价值很直接，它能防止下一位同事重新走回错误的 ACP 排障分支。

常见判断问题 FAQ

为什么这类问题比“ACP history 暂时为空”更该优先查？

因为这次断点更靠前，坏的是 session 创建入口，不是创建后展示层的投影结果。

如果是本文这类故障，你通常会看到：

acpx claude sessions new 退出了，但没有返回 session ID
acpx claude sessions list 仍然是空的
网关只留下 ensureSession returned no events

而如果是 history / transcript 可见性问题，至少通常还能找到“session 已存在”或“任务确实跑过”的证据。

一线值班时，先回退版本还是先继续深挖日志？

如果业务正在被阻断，而且你已经用最小复现确认 0.4.x 建不出 session、0.3.1 能立即恢复，那一般应先回退止血，再补日志。

原因很实际：

这类故障会直接阻断 Claude ACP 编排入口
静默失败很容易让团队把时间浪费在错误层
先恢复 session 创建能力，通常比带故障继续值班更划算

搜 `acpx claude sessions new exit 0 but no session` 的人，最该先看哪三个点？

建议优先看这三个：

sessions new 是否真的返回了可用 session ID
sessions list 是否仍然显示 No sessions
网关日志里是否出现 ensureSession returned no events

这三个点能最快把问题收敛到“创建阶段坏了”，而不是把它泛化成 Claude 整体不可用。

怎么区分是 Claude 登录本身出问题，还是 acpx 建 session 的 bootstrap 出问题？

最稳的办法，是先做一个最小分支判断。

更像是 Claude 登录 / 账号态问题 的信号包括：

直接运行 Claude Code 也失败
OAuth 授权反复跳转、失效，或者根本走不完
acpx 和 Claude 直连命令都在类似位置失败

更像是 acpx session bootstrap 失败 的信号包括：

直接运行 Claude Code 仍然正常
acpx claude sessions new 看起来成功退出，但什么都没建出来
acpx claude sessions list 仍然为空
OpenClaw 侧只看到 ensureSession returned no events

这个分支很关键，因为后续动作完全不同。前者通常该修认证，后者更该优先回退版本，或者继续查 ACP backend / session 创建链路。

如果一线值班要尽快恢复 Claude ACP，最低风险的回退检查清单是什么？

如果线上工作已经被卡住，建议别临场乱试，直接按一个短清单执行：

先记下当前 acpx 版本
回退到 [email protected]
再次确认 acpx claude sessions new --name test 是否能返回真实 session ID
再确认 acpx claude sessions list 不再是 No sessions
如果环境没有立刻恢复，再按常规流程重启 OpenClaw gateway
在交接里写清失败版本、恢复版本，以及一条能证明故障模式的日志

为什么“静默建不出 session”比直接报错更危险？

因为直接报错会快速把团队注意力收敛到正确层，而这种“看起来成功、其实没建出来”的故障，会把人持续拖在错误排障分支里。

遇到这类回归时，团队很容易把时间花在 prompt、网关路由、OAuth scope、sessions_spawn 参数上，但真正坏掉的地方其实更靠前，是 Claude ACP session 从一开始就没被创建成可用对象。

对于依赖自动化编排的团队，这种差别非常实际，因为排队中的任务表面上像是“只是慢了”，但实际上入口已经失效。

宣布回退成功前，最该补哪几条证据？

不要只看到“命令不报错了”就收工，最好把整个入口恢复链路一起确认下来：

acpx claude sessions new --name test 已能返回可用 session ID
acpx claude sessions list 已能看到新 session，而不是 No sessions
至少有一条 OpenClaw ACP 任务可以重新正常启动
同一路径下不再出现 ensureSession returned no events

这组证据的价值，是把“感觉回退好了”变成“可以交接、可以复盘、可以放心关单”的收口证明。

这套清单的重点，是先把 session 创建能力恢复回来，而不是一边带故障值班，一边在坏版本上无限深挖。

为什么 `sessions_spawn(runtime: "acp")` 会在 Claude Code 还能直接打开时依然失败？

因为 OpenClaw 判断的不是“Claude 二进制有没有被拉起来”，而是 ACP 层有没有返回一个 真实可用的 session 对象，供后续编排继续挂接。

这个回归里，更像是出现了这样的分叉：

Claude Code 底层仍然能启动
但 acpx 0.4.x 没有把可用 session ID 或 session event 正常抛出来
导致 sessions_spawn(runtime: "acp") 后续拿不到可持续跟进的目标对象

所以一线同事才会看到一种很迷惑的状态：Claude CLI 本身像是活的，但 OpenClaw 编排层表现得像“什么都没创建出来”。

在怀疑 OpenClaw 路由、prompt 或网关配置前，最该先查什么？

先把创建链路本身查清，不要一上来改 prompt 或路由：

运行 acpx claude sessions new --name test
确认是否真的返回了可用 session ID
再运行 acpx claude sessions list
对照网关日志里是否出现 ensureSession returned no events

如果创建阶段已经坏掉，改 prompt、改 router、改网关配置都救不回 Claude ACP 工作流，因为那些都属于更下游的层。

哪些搜索词最值得在这页里直接回答？

这页更适合覆盖的是“已经怀疑 session 根本没建出来”的高意图搜索，而不是泛泛写成 Claude 不可用。

优先应该直接回答的搜索表达包括：

acpx claude sessions new exit 0 but no session
acpx 0.4.1 no sessions
ensureSession returned no events
Claude ACP silent session creation failure
OpenClaw sessions_spawn claude no session id

如果你的现场现象与这些词更接近，优先把它归到 session 创建故障，而不是 transcript、history 或 UI 展示延迟。

如果你是从 Feishu 停不下来、Kimi 重置或发布评估入口来的

这些入口都可能表现成“OpenClaw 会话不可控”，但 ACPX silent session 的断点更早：Claude ACP session 根本没有被创建成可用对象。建议先这样分流：

Feishu 线程还在跑，只是 /stop 或 /new 没有中断执行：优先看 Feishu /stop 排障，那是 interrupt 事件没有落到执行层。
普通消息一发出就被提示 /new 或 /reset：优先看 Kimi-Claw 强制重置，那更像 session 生命周期被错误重建。
升级后 Claude ACP 任务一开始就没有 session ID：再回到本文，用 acpx claude sessions new、sessions list 和 ensureSession returned no events 三个证据确认是不是创建入口静默失败。
你是在评估版本、迁移或安全成本时撞到它：先把 2026.3.13 发布评估、迁移指南和安全/成本页的前置检查补齐。

这段路由的目标，是把“停不下来”“被重置”“版本升级后不稳”和“ACP session 根本没建出来”拆开。只有最后一种，才应该优先按本文回退 [email protected] 止血。

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

当读者从 ACPX 0.4.x 的窄搜索进入这里，先判断失败发生在 session 创建前、harness 内部，还是 caller 已经丢失 run id 之后。

ACPX 0.4.x silent session creation failure：先确认 agent session 是否真的创建成功，再去排查模型输出或 prompt 内容。
OpenClaw ACPX run starts but no session appears：重复执行前，先看 harness response、session 目录和 gateway logs 是否有同一个 run 的痕迹。
fix ACPX silent session failure after upgrade：把 ACPX package version、runtime adapter config、首次 session creation event 放在同一次 smoke test 里核对。

从 silent session 流量转成创建链路验收清单

如果你是因为 ACPX 0.4.x 静默创建 session 失败搜到这里，先不要只看前端有没有弹错。要把创建链路拆成四个验收点：请求是否真正发出、session id 是否落库、运行时是否返回 ready 状态、以及 UI 是否把失败原因吞掉。每个点都要留下可复制的日志或状态码。

最小验收清单包括：一次 session/create 请求记录、返回 payload、后台 session 列表快照、以及前端 toast 或 console 输出。这样 ACPX 故障流量会被引导到“创建链路、状态持久化、UI 错误暴露”三类高意图入口，而不是停在静默失败这一个症状。

silent session 创建失败时，先补一条可观测事件

ACPX 0.4.x 的 silent session 问题最危险的地方，不是创建失败本身，而是调用方以为 session 已经存在，后续任务却没有任何可追踪入口。排查时先把它当成“可观测性缺口”，而不是只重试创建接口：

创建 session 后立刻记录 session id、channel id、agent id 和返回状态，避免后续日志只剩一串空历史；
如果 API 返回成功但 UI 或 session 列表看不到，马上做一次 list/read 交叉验证，不要继续派发长任务；
cron 或部署机器人遇到 silent failure 时，应降级为显式失败并通知，而不是静默吞掉。

这段能承接“ACPX silent session creation failure”“session created but missing history”“自动任务创建会话失败没提示”这类高意图搜索，也能把读者从盲目重试引到更安全的观测与降级路径。

来源

Issue： openclaw/openclaw#60970

值班时的快速决策树

如果你在值班窗口里看到 ACPX 调用“像是成功了”但 session 根本没创建出来，不要先把它当成普通超时。更稳的分流顺序是：

API 返回表面成功，但 session 列表里没有新增记录
- 优先怀疑 silent failure 或落盘链路断裂，而不是先去追前端展示层。
- 先对比请求返回、事件流和最终 session 存储结果是否一致。
同一时段连其他 ACPX 调用也一起异常
- 这时问题面更大，不该只盯 session creation，应该改查 ACPX runtime、网关或上游依赖。
只有特定参数组合才会失败
- 更像 schema、默认值或兼容性边界问题，优先固化最小复现样本。

宣布问题收口前，还要补验什么

即便你已经让 session 能重新创建，也别只看一次成功样本就结束。至少还要补验这四件事：

相同输入重复执行多次后，session 都能稳定创建，不再出现“偶发成功”；
新建 session 在列表、历史和底层落盘结果里彼此一致，不存在只显示不落盘或只落盘不展示；
一条真实后续任务已经能接着新 session 正常运行，确认不是“创建好了但马上断链”；
事故记录里已经保存失败请求样本、受影响版本、日志锚点和恢复前后差异。

acpx 0.4.x 可能让 Claude ACP 会话“静默创建失败”：怎么确认、为什么危险、当前最稳的回退办法

当前报告到底在说什么

为什么这不是“小问题”

它和其他 ACP / session 类故障不是一回事

快速确认：先别猜，按这 3 步看

1）先确认 session 到底有没有真的被创建出来

2）对照网关日志，确认是不是“没收到 session 事件”

3）把“Claude 可用”与“acpx 建 session 可用”分开看

当前最稳的止血办法：回退到 0.3.1

可能的根因边界在哪里

回退到 `[email protected]` 前，先做 4 个判断

如果你也中招，反馈时最好补这些证据

结论

面向搜索入口的对比判断：ACP session 根本没建出来，还是 run 已存在但 history 看起来是空的

缓解后，下一位值班同事至少要接到什么

常见判断问题 FAQ

为什么这类问题比“ACP history 暂时为空”更该优先查？

一线值班时，先回退版本还是先继续深挖日志？

搜 `acpx claude sessions new exit 0 but no session` 的人，最该先看哪三个点？

怎么区分是 Claude 登录本身出问题，还是 acpx 建 session 的 bootstrap 出问题？

如果一线值班要尽快恢复 Claude ACP，最低风险的回退检查清单是什么？

为什么“静默建不出 session”比直接报错更危险？

宣布回退成功前，最该补哪几条证据？

为什么 `sessions_spawn(runtime: "acp")` 会在 Claude Code 还能直接打开时依然失败？

在怀疑 OpenClaw 路由、prompt 或网关配置前，最该先查什么？

哪些搜索词最值得在这页里直接回答？

如果你是从 Feishu 停不下来、Kimi 重置或发布评估入口来的

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

从 silent session 流量转成创建链路验收清单

silent session 创建失败时，先补一条可观测事件

相关阅读

来源

值班时的快速决策树

宣布问题收口前，还要补验什么

相关阅读

当前报告到底在说什么

为什么这不是“小问题”

它和其他 ACP / session 类故障不是一回事

快速确认：先别猜，按这 3 步看

1）先确认 session 到底有没有真的被创建出来

2）对照网关日志，确认是不是“没收到 session 事件”

3）把“Claude 可用”与“acpx 建 session 可用”分开看

当前最稳的止血办法：回退到 0.3.1

可能的根因边界在哪里

回退到 [email protected] 前，先做 4 个判断

如果你也中招，反馈时最好补这些证据

结论

面向搜索入口的对比判断：ACP session 根本没建出来，还是 run 已存在但 history 看起来是空的

缓解后，下一位值班同事至少要接到什么

常见判断问题 FAQ

为什么这类问题比“ACP history 暂时为空”更该优先查？

一线值班时，先回退版本还是先继续深挖日志？

搜 acpx claude sessions new exit 0 but no session 的人，最该先看哪三个点？

怎么区分是 Claude 登录本身出问题，还是 acpx 建 session 的 bootstrap 出问题？

如果一线值班要尽快恢复 Claude ACP，最低风险的回退检查清单是什么？

为什么“静默建不出 session”比直接报错更危险？

宣布回退成功前，最该补哪几条证据？

为什么 sessions_spawn(runtime: "acp") 会在 Claude Code 还能直接打开时依然失败？

在怀疑 OpenClaw 路由、prompt 或网关配置前，最该先查什么？

哪些搜索词最值得在这页里直接回答？

如果你是从 Feishu 停不下来、Kimi 重置或发布评估入口来的

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

从 silent session 流量转成创建链路验收清单

silent session 创建失败时，先补一条可观测事件

相关阅读

来源

值班时的快速决策树

宣布问题收口前，还要补验什么

相关阅读

回退到 `[email protected]` 前，先做 4 个判断

搜 `acpx claude sessions new exit 0 but no session` 的人，最该先看哪三个点？

为什么 `sessions_spawn(runtime: "acp")` 会在 Claude Code 还能直接打开时依然失败？