OpenClaw mcp serve stdout banner 污染 MCP stream

[yjc6456]

Title: [Bug] openclaw mcp serve prints ASCII banner to stdout, breaking stdio MCP bridge

Environment:

• OpenClaw v2026.4.24
• Running: openclaw mcp serve --url ws://...

Expected: stdout emits pure JSON-RPC (MCP protocol)
Actual: First lines are ASCII art banner ("Half butler, half debugger..."), causing supergateway/bridge parsers to fail

[yjc6456]

AI大模型给的问题整理，不知道是否准确，我的问题的核心是openclaw在windows，hermes在wsl，openclaw可以调用hermes，但是hermes调用不了openclaw。不知道目前是否可以实现？新手，如有不妥，请见谅！

[xiwan]

感谢反馈！我们做了验证测试：

测试结果

模拟了一个会在 stdout 先输出 banner 的 agent（类似 OpenClaw 的行为），Bridge 能正常处理：

=== Test 1: initialize (after banner) ===
✅ initialize succeeded

=== Test 2: ping ===
✅ ping returned: True

=== Test 3: session/new ===
✅ session/new succeeded

Bridge 的 _read_loop 在解析 stdout 时，遇到非 JSON 行（banner）会直接跳过（json.loads 失败 → continue），不影响后续 JSON-RPC 通信。所以 banner 污染对 ACP Bridge 不构成问题。

关于你评论中提到的场景

openclaw在windows，hermes在wsl，openclaw可以调用hermes，但是hermes调用不了openclaw

这个跟 #6 是同一个根因：WSL 中的进程无法直接执行 Windows 的 .cmd 文件。

建议方案：在 WSL 中也安装 OpenClaw（npm install -g openclaw），这样 Hermes 和 OpenClaw 都在同一个 Linux 环境中，互调就没问题了。

如果你的场景确实需要跨 WSL/Windows 调用，能否提供更多信息？

1. 你是通过 ACP Bridge 编排这两个 agent，还是 agent 之间直接互调？
2. Bridge 本身跑在哪一侧（WSL 还是 Windows）？

这样我们可以更针对性地给出方案。