Version

• OpenClaw: 2026.3.2 (commit 85377a2)

Issue Description

After upgrading to 2026.3.2, the health-monitor subsystem aggressively triggers stale-socket restarts for all Telegram providers, causing:

1. Connection restart storms across all configured Telegram bots
2. Device re-pairing events repeatedly
3. Duplicate outbound message sends during reconnection windows

This pollutes user chat with noise and causes message duplication.

Observed Symptoms

1. Stale-socket restart storms

From /tmp/openclaw/openclaw-2026-03-07.log:

[telegram:cyba] health-monitor: restarting (reason: stale-socket)
[telegram:default] health-monitor: restarting (reason: stale-socket)
[telegram:descard] health-monitor: restarting (reason: stale-socket)
[telegram:mira] health-monitor: restarting (reason: stale-socket)

All four Telegram providers restarted at the same time: 2026-03-07T01:39:50Z

2. Duplicate message sends

Outbound logs show duplicate sends during reconnection:

telegram sendMessage ok chat=redacted message=1834  (01:32:56 UTC)
telegram sendMessage ok chat=redacted message=1837  (01:34:33 UTC)
telegram sendMessage ok chat=redacted message=1840  (01:38:21 UTC)
telegram sendMessage ok chat=redacted message=1841  (01:38:21 UTC)

Note: Messages 1840 and 1841 sent at exact same millisecond (2026-03-07T01:38:21.883Z) — same target, same timestamp.

3. Device re-pairing loops

device-pair: /pair invoked channel=telegram sender=redacted action=new
device-pair: telegram split send ok target=redacted account=default thread=none
device-pair: /pair invoked channel=telegram sender=redacted action=new
device-pair: telegram split send ok target=redacted account=default thread=none

Re-pair events triggered repeatedly during the restart storm window.

4. MEMORY.md truncation warnings

workspace bootstrap file MEMORY.md is 21850 chars (limit 20000); truncating in injected context

This is unrelated but adds noise on every user turn.

Gateway Status

• Running normally
• No configuration errors
• Bind mode: loopback
• Port: 18789
• Health probe: OK

Root Cause Analysis

The health-monitor stale-socket detector appears overly aggressive for Telegram connections after 2026.3.2 upgrade. It incorrectly flags healthy Telegram sockets as stale, triggering provider restarts. These restarts then:

1. Re-trigger device pairing (causing /pair invoked storms)
2. Send duplicate messages during reconnection

This is internal gateway behavior — not from agent-level code. The duplication is happening in the Telegram send path after restart, not in message routing.

Workarounds Attempted

1. Checked gateway health: Running normally
2. Verified config: No health-monitor tunables exposed
3. Checked for CLI flags: None to disable health-monitor or adjust stale-socket thresholds
4. Tested alternative bind mode: Not yet tried

Expected Behavior

• Health-monitor should only restart truly stale sockets
• No duplicate message sends on reconnection
• No device re-pairing storms unless actual pairing occurs
• Stable, quiet restart behavior (not 4 providers restarting simultaneously)

Additional Context

• The user’s agent (agent:main:telegram:direct:redacted) did not touch any gateway or Telegram configuration today.
• Only work done was on project_shodan_freedom (PR Bird tool repository appears to be private #24 merge + steps 17-20).
• This issue emerged after 2026.3.2 upgrade.

Suggested Fix

1. Add health-monitor sensitivity configuration for stale-socket detection
2. Disable or dampen Telegram health-monitor restarts specifically
3. Improve message deduplication after provider restart
4. Add exponential backoff to re-pair events to prevent storms