openclaw - 💡(How to fix) Fix [Bug]: Gateway buffers claude-cli stream events; surfaces only see the final assembled message

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

When agentRuntime.id = "claude-cli", the gateway receives 46–105 stream-json events per turn from claude.exe but relays zero of them to WebChat or TUI surfaces during the turn; both surfaces only render the final assembled message after the turn closes.

Steps to reproduce

1. Configure agents.defaults.models["anthropic/claude-opus-4-7"].agentRuntime.id = "claude-cli".
2. Open the WebChat dashboard at http://127.0.0.1:<gateway-port>/, or run openclaw chat for the TUI — both reproduce.
3. Send a prompt that triggers a tool call, e.g. Read MEMORY.md and summarize it in one sentence.
4. Observe the surface during the turn.

Expected behavior

Prior observed behavior in the same install (user testimony): for approximately 5 days before 2026-05-21, the WebChat dashboard's typing indicator stayed visible during the turn and partial reply text became visible incrementally during the turn rather than only at the end. Expected restoration of that observed behavior: per-event updates from claude.exe's stream-json output (between the cli exec and claude live session turn log lines) should reach connected surfaces as they arrive, rather than only at turn close.

Actual behavior

Observed in gateway log C:\Users\Max\AppData\Local\Temp\openclaw\openclaw-2026-05-23.log and reproduced live in the openclaw chat TUI:

• Each turn produces a cli exec ... line followed (12–127 s later) by a claude live session turn ... rawLines=N line where N ∈ {22, 29, 46, 70, 83, 105} across the six observed turns.
• Between those two log lines, the gateway/ws subsystem emits no outbound WS messages to the connected client=openclaw-control-ui webchat connection. The first post-turn gateway/ws line is always commands.list or chat.history, both UI-initiated requests.
• User-visible (WebChat dashboard): typing indicator clears ~3 s into the turn and stays cleared for the remainder; no partial text appears; no tool-use announcement appears; the full assembled reply appears at the end.
• User-visible (openclaw chat TUI): the streaming • Ns | local ready counter increments but no text appears until the turn closes, then the full reply renders at once. No tool-use announcement appears.

OpenClaw version

2026.5.20 (build e510042).

Operating system

Windows 11

Install method

npm global install

Model

claude-opus-4-7

Provider / routing chain

Effective path: claude-cli agentRuntime → spawned claude.exe subprocess (Claude Code CLI) → Anthropic API. Subprocess invocation observed via Get-CimInstance Win32_Process: claude -p --include-partial-messages --verbose --setting-sources user --allowedTools mcp__openclaw__* --resume <uuid> --permission-mode bypassPermissions --strict-mcp-config --mcp-config <temp-path>\mcp.json --model opus --input-format stream-json --output-format stream-json --permission-prompt-tool stdio --replay-user-messages --include-partial-messages and --output-format stream-json confirm the subprocess is configured to emit partials.

Additional provider/model setup details

• agents.defaults.models["anthropic/claude-opus-4-7"].agentRuntime.id = "claude-cli".
• Auth profiles configured: anthropic:claude-cli (mode oauth), anthropic:default (mode api_key).
• Auth order for anthropic: ["anthropic:claude-cli", "anthropic:default"] (claude-cli preferred).
• cli-backend watchdog: fresh and resume both minMs: 600000, maxMs: 1500000, noOutputTimeoutRatio: 0.9.
• agents.defaults.skills at time of report: ["openclaw-skills:taskflow", "loop", "schedule"].
• agents.defaults.typingMode, blockStreamingDefault, blockStreamingBreak are unset (defaults apply).

Logs, screenshots, and evidence

Six consecutive turns from `openclaw-2026-05-23.log` (timestamps local `+02:00`; resume-session UUIDs redacted to last 12 chars):


01:04:36  cli exec  promptChars=75   useResume=false  session=none
01:05:06  claude live session turn complete  durationMs=29571   rawLines=46
01:05:25  cli exec  promptChars=51   useResume=true   resumeSession=…161d432d9437
01:05:38  claude live session turn complete  durationMs=12508   rawLines=22
01:07:11  cli exec  promptChars=50   useResume=true
01:07:26  claude live session turn complete  durationMs=15242   rawLines=29
01:07:46  cli exec  promptChars=49   useResume=true
01:08:21  claude live session turn complete  durationMs=35356   rawLines=83
01:08:37  cli exec  promptChars=64   useResume=true
01:09:15  claude live session turn complete  durationMs=37264   rawLines=70
01:12:20  cli exec  promptChars=65   useResume=true
01:14:27  claude live session turn complete  durationMs=127280  rawLines=105


During every `cli exec` → `turn complete` window, the `gateway/ws` subsystem produced zero outbound messages to the connected webchat client. The first post-turn WS line was always `commands.list` or `chat.history`.

Log line meta points to the relay subsystem: `_meta.path.fullFilePath: "file:///C:/Users/Max/AppData/Roaming/npm/node_modules/openclaw/dist/subsystem-BIvbRvCg.js"`, with the `cli exec` and `turn` lines under `subsystem: "agent/cli-backend"`.

TUI reproduction confirmed at 2026-05-24 01:23 local with prompt `Read MEMORY.md and tell me in one sentence what's in it.` Display: `streaming • Ns | local ready` counter ticked through the wait; no text or tool announcement appeared until reply rendered in full at the end.

Impact and severity

• Affected users / systems / channels: All installs running agentRuntime.id = "claude-cli" interacting via the WebChat dashboard or the openclaw chat TUI. Telegram surface behavior is not retested in this report.
• Severity: Blocks workflow visibility. Final replies still arrive correct; intermediate feedback does not.
• Frequency: Every turn, observed across six consecutive turns spanning both fresh (useResume=false) and resumed sessions.
• Consequence: Users cannot distinguish "agent working" from "agent hung." Combined with the cli-backend watchdog minMs: 600000 (10 minutes), users have no progress signal to decide whether to wait or intervene. Concrete instance from this install: subprocess PID 30236 spawned at 2026-05-23T22:22:52 hung silently for 21 minutes before the watchdog terminated it; user had no in-UI signal to distinguish from normal slow processing.

Additional information

User reports the symptom emerged on or about 2026-05-21 and compounded across subsequent chats. Workspace evidence shows the install transitioned from a saved config snapshot Kael Backup/openclaw/openclaw.json.bak.pre-watchdog-bump (which has meta.lastTouchedVersion: 2026.5.12) to current 2026.5.20 between then and 2026-05-23. Specific "last known good" and "first known bad" OpenClaw versions: NOT_ENOUGH_INFO — no version-bound log evidence available from the period before 2026-05-21.

Workarounds attempted and verified ineffective on 2026-05-23 / 2026-05-24:

• Removed agents.defaults.typingMode, blockStreamingDefault, blockStreamingBreak overrides; defaults applied.
• Trimmed agents.defaults.skills from 10 entries to 3.
• Restarted gateway via openclaw gateway restart.
• Archived three bloated claude-cli session transcripts in ~/.claude/projects/C--Users-Max--openclaw-workspace/ (sizes 1.0–1.1 MB) so resumes start fresh.

None changed the observed streaming behavior. An unrelated context-bloat issue (base64 image tool_result blocks accumulating via --resume) was addressed in this install during the same debugging session; that resolution is independent of this report.