Summary

When OpenClaw runs through the Claude CLI backend (agentRuntime.id = "claude-cli") and a turn produces no output for the configured CLI watchdog window, Telegram receives only the generic message:

Something went wrong while processing your request. Please try again, or use /new to start a fresh session.

The gateway remains healthy and the CLI OAuth path is valid, but the user/operator cannot distinguish a CLI no-output timeout from provider billing, auth, gateway downtime, or a Telegram channel failure. This is especially confusing for long-running Claude CLI Opus/resume sessions where 300s can be a normal-but-slow turn rather than a broken provider.

Environment

• OpenClaw: 2026.4.29 CLI installed; gateway service description pinned to v2026.4.25
• Platform: Linux server, systemd user service
• Channel: Telegram bot
• Runtime: claude-cli via OAuth/subscription
• Primary model: anthropic/claude-opus-4-7
• agents.defaults.agentRuntime.id = "claude-cli"
• agents.defaults.timeoutSeconds = 300 before mitigation
• CLI backend watchdog before mitigation:

{
  "fresh": { "noOutputTimeoutMs": 300000 },
  "resume": { "noOutputTimeoutMs": 300000 }
}

Observed incidents

The following user-visible Telegram errors all mapped to the same gateway-side timeout pattern:

2026-05-03 19:22:51 UTC
2026-05-03 22:34:27 UTC
2026-05-03 22:51:55 UTC
2026-05-03 23:58:18 UTC

Gateway log pattern:

[agent/cli-backend] claude live session close: provider=claude-cli model=claude-opus-4-7 reason=abort
[agent/cli-backend] claude live session turn failed: provider=claude-cli model=claude-opus-4-7 durationMs=300003 error=FailoverError
[model-fallback/decision] model fallback decision: decision=candidate_failed requested=anthropic/claude-opus-4-7 candidate=anthropic/claude-opus-4-7 reason=timeout next=none detail=CLI exceeded timeout (300s) and was terminated.
Embedded agent failed before reply: CLI exceeded timeout (300s) and was terminated.
[telegram] sendMessage ok chat=<redacted> message=<id>

At the same time:

systemctl --user status openclaw-gateway.service => active/running
curl http://127.0.0.1:18788/health => {"ok":true,"status":"live"}

Direct Claude CLI smoke test worked:

claude --model claude-opus-4-7 --print "reply ok only"
# ok

So this was not gateway downtime and not a dead OAuth/CLI installation.

Expected behavior

1. Telegram should surface the real failure class, for example:

Claude CLI timed out after 300s with no output for claude-opus-4-7. Gateway is still healthy. Try /new, lower effort, use Sonnet, or increase agents.defaults.timeoutSeconds / cliBackends.claude-cli.reliability.watchdog.*.noOutputTimeoutMs.

1. Status/diagnostics should distinguish:

• gateway down
• provider auth/billing failure
• CLI subprocess no-output timeout
• overall agent turn timeout
• Telegram delivery failure

1. For claude-cli backends, the runtime should consider a safer default for Opus/resume sessions or expose a clear recommendation when timeoutSeconds and CLI noOutputTimeoutMs are both 300s.

2. If agentRuntime.id = "claude-cli", model-fallback/status messages should show the execution backend (claude-cli) prominently, not only the canonical model namespace (anthropic/...).

Local mitigation applied

We increased the local deployment timeouts:

{
  "agents": {
    "defaults": {
      "timeoutSeconds": 900,
      "cliBackends": {
        "claude-cli": {
          "reliability": {
            "watchdog": {
              "fresh": { "noOutputTimeoutMs": 900000 },
              "resume": { "noOutputTimeoutMs": 900000 }
            }
          }
        }
      }
    }
  }
}

After restart:

/health => {"ok":true,"status":"live"}
runtime => {"id":"claude-cli"}
model unchanged => anthropic/claude-opus-4-7

This mitigates premature aborts, but it does not fix the platform UX: Telegram still collapses the root cause into a generic error and operators must inspect gateway logs to understand what happened.

Related issues

This appears related to, but broader than, #75264. That issue reports a specific Telegram + CLI backend stall during a file Read tool call. This report focuses on the generic platform behavior for Claude CLI no-output/turn timeouts and the lack of actionable error propagation to Telegram/status.