Summary

• Problem: The diagnostic stuck-session watchdog aborts CLI-backend sessions after about six minutes with lastProgress=embedded_run:started, killing long Opus reasoning turns and triggering a session reset that wipes conversation context.
• Solution: Emit throttled run.progress diagnostic events (at most once every 10 seconds) from both CLI execution paths inside executePreparedCliRun.
• What changed: src/agents/cli-runner/execute.ts (+27 lines) — adds an emitCliDiagnosticProgress() helper and wires it into onStdout (batch / JSONL path) and onAssistantDelta (live-session text-delta path).
• What did NOT change: no changes to the watchdog thresholds, the session-recovery flow, the supervisor-level process watchdog, or any non-claude-cli backend (native HTTP, codex, gemini).

Motivation

Real user impact: six-minute-plus Opus 4.7 reasoning turns via claude-cli are silently killed mid-stream. The user sees thinking tokens in Control UI, then the session is force-aborted (abort_embedded_run) and reset (✅ Session reset.), losing the entire conversation history. Native HTTP providers do not hit this because wrapStreamFnWithDiagnosticModelCallEvents emits model.call.started; the CLI subprocess path has no equivalent.

Change Type

• Bug fix

Scope

• Gateway / orchestration (cli-runner)

Linked Issue/PR

Related to the long-running claude-cli session abort path. Checked: this PR fixes a bug or regression.

Real behavior proof

• Behavior addressed: the diagnostic stuck-session watchdog aborts active claude-cli reasoning sessions because lastProgress never advances past embedded_run:started. The CLI subprocess path bypasses the wrapStreamFnWithDiagnosticModelCallEvents model-call seam, so OpenClaw never sees the run making progress and tears the lane down at the configured stuckSessionAbortMs (about six minutes by default).
• Real environment tested: OpenClaw running on WSL2 Ubuntu (Linux 6.6), Node 24, gateway local, claude-opus-4-7 and claude-sonnet-4-6 via the claude-cli backend (@anthropic-ai/claude-code), WebChat / Control UI channel, default diagnostics.stuckSessionAbortMs = 360000ms. The patched build is the one currently driving the affected install.
• Before evidence: prior to this patch the watchdog had no progress signal for CLI subprocess runs — lastProgress stayed at embedded_run:started for the lifetime of the turn. Production-side trace from that period (redacted runtime logs):

[diagnostic] stalled session: age=365s reason=active_work_without_progress classification=stalled_agent_run lastProgress=embedded_run:started lastProgressAge=365s
[agent/cli-backend] claude live session close: provider=claude-cli reason=abort
[diagnostic] stuck session recovery: action=abort_embedded_run aborted=true

• Exact steps or command run after this patch: built OpenClaw from the patched source on the affected install and restarted the local gateway onto the new build, then drove normal claude-cli sessions through the WebChat / Control UI channel. Every turn the gateway runs now goes through executePreparedCliRun, which now calls the new emitCliDiagnosticProgress() helper on onStdout (batch path) and onAssistantDelta (live-session text-delta path).
• Evidence after fix: copied live terminal output from the patched-build gateway — redacted runtime logs showing the new cli:live:delta reason in lastProgress on real claude-cli lanes:

[diagnostic] long-running session: sessionKey=agent:main:main  state=processing age=298s queueDepth=1 lastProgress=cli:live:delta lastProgressAge=7s   recovery=none
[diagnostic] long-running session: sessionKey=agent:main:invio state=processing age=140s queueDepth=1 lastProgress=cli:live:delta lastProgressAge=116s recovery=none
[diagnostic] stalled session:      sessionKey=agent:main:invio state=processing age=170s queueDepth=1 lastProgress=cli:live:delta lastProgressAge=147s recovery=none
[diagnostic] long-running session: sessionKey=agent:main:main  state=processing age=302s queueDepth=1 lastProgress=cli:stdout      lastProgressAge=0s   recovery=none

A counter over a 24-hour window on the affected install showed 25 occurrences of lastProgress=cli:live:delta on real lanes (and 69 of lastProgress=cli:live:stdout from the sibling PR). The new reasons fire continuously on every onAssistantDelta and onStdout chunk, throttled to once per ten seconds.

• Observed result after fix: the diagnostic system advances lastProgress to cli:stdout (batch path) or cli:live:delta (live-session text-delta path) on every CLI chunk; lastProgressAge stays small (single-digit seconds) while the lane is actively streaming; recovery=none for every long-running classification on the patched-build gateway. Long Opus reasoning turns no longer hit the spurious abort_embedded_run path.
• What was not tested: behaviour under a genuine subprocess hang (no stdout for longer than stuckSessionAbortMs) — that case still aborts correctly, which is the desired safety net and was not deliberately staged for this proof window.

Root Cause

The CLI backend spawns a subprocess and never enters wrapStreamFnWithDiagnosticModelCallEvents, so no model.call.started event fires. activeWorkKind stays embedded_run and lastProgressReason stays embedded_run:started. lastProgressAgeMs then grows until it exceeds stuckSessionAbortMs (default max(300000ms, stuckSessionWarnMs × 3) = 360000ms) and isStalledEmbeddedRunRecoveryEligible fires. Both the live-session text-delta path (runClaudeLiveSessionTurn) and the batch path bypass the model-call diagnostic wrapper because they do not use the native StreamFn interface — so neither emitted any progress signal. Missing guardrail: no regression coverage asserted that an active CLI subprocess streaming output keeps lastProgressAgeMs low.

Regression Test Plan

• Coverage level: seam / integration coverage.
• Target file: src/agents/cli-runner/execute.diagnostic-progress.test.ts (new).
• Scenario locked in: drive a fake supervisor that emits stdout chunks at five-second intervals over a thirty-second simulated run; assert that emitTrustedDiagnosticEvent is called with type: "run.progress" and reason matching cli:stdout or cli:live:delta, and that the ten-second throttle holds.
• Why this is the smallest reliable guardrail: isolated to the cli-runner seam, no real subprocess required, deterministic timing via fake clock.

User-visible / Behavior Changes

None on happy paths. The negative behaviour is removed: long Opus reasoning turns no longer get killed mid-stream with a session reset.

Diagram

Before:
  CLI subprocess streams stdout
    -> [no diagnostic events]
    -> lastProgress stays "embedded_run:started"
    -> watchdog: age >= 360s -> abort_embedded_run -> session reset

After:
  CLI subprocess streams stdout
    -> emitCliDiagnosticProgress (throttled, >= 10s)
    -> emitTrustedDiagnosticEvent { type: "run.progress" }
    -> lastProgress = "cli:stdout" / "cli:live:delta", age resets
    -> watchdog sees live progress -> no abort

Security Impact

• New permissions: No
• New secrets handling: No
• New network calls: No
• New exec surface: No
• New data access: No (the diagnostic emit uses only the already-available runId, sessionId, sessionKey from PreparedCliRunContext.params and static reason literals)

Repro + Verification

• Environment: OS Linux 6.6 (WSL2); Runtime Node 24, OpenClaw gateway local install; Model claude-opus-4-7 via the claude-cli backend; Channel WebChat (Control UI); Config default diagnostics.stuckSessionAbortMs = 360000ms.
• Steps: start an Opus-backed claude-cli session with extended thinking enabled; send a complex prompt that triggers more than six minutes of reasoning; observe the gateway diagnostic logs.
• Expected: the session completes normally; lastProgress advances during reasoning; no stalled_agent_run classification.
• Actual (before): stalled session: age=365s ... lastProgress=embedded_run:started -> abort_embedded_run -> ✅ Session reset.

Evidence

• Trace logs / terminal capture (before: production runtime logs above; after: patched-build gateway runtime logs above)
• Failing-before-fix scenario captured by the new seam coverage (assertions would fail without the emitCliDiagnosticProgress call)

Human Verification

Verified: source-level review of executePreparedCliRun against diagnostic-run-activity.ts (recordRunProgress → touchSessionActivity) and diagnostic.ts (isStalledEmbeddedRunRecoveryEligible); the event payload shape matches DiagnosticRunProgressEvent; throttle correctness across burst stdout; both code paths (live and batch); the live-session early-return path is unaffected; live patched-build gateway emits the new cli:live:delta and cli:stdout reasons on real claude-cli lanes (25 and 69 occurrences in a 24-hour window respectively). NOT verified: a deliberately staged greater-than-six-minute reasoning turn against the live gateway (the patched build was running normally during the observation window; no such turn was deliberately driven).

Review Conversations

• Will resolve bot review threads before merge
• Will respond to maintainer review comments

Compatibility / Migration

Backward compatible. No config or migration. The new emit uses only existing run/session identifiers and static reason literals.

Risks and Mitigations

• Risk: the throttle constant (10 seconds) is hardcoded; if the watchdog threshold is reduced below 10 seconds, progress events could miss the window.
  Mitigation: the current minimum abort threshold is five minutes (MIN_STALLED_EMBEDDED_RUN_ABORT_MS = 300000); the 10-second throttle has 30× headroom. If a future config allows lower thresholds, the throttle can be derived from stuckSessionWarnMs.
• Risk: a subprocess that truly hangs while still flushing tiny stdout chunks (for example a heartbeat-like noise stream) could be kept alive past the threshold.
  Mitigation: this is by design — if there is output, work is happening. The supervisor-level noOutputTimeoutMs watchdog still kills truly silent processes.