Summary

Telegram group session lanes can enter a permanent wedged state where messages queue but never dispatch. The stuck-session recovery logic detects the wedge correctly but skips action with reason=active_reply_work, creating a tautology: "should I clear this stale lane? the lane state says it's active, so I'll keep it."

Symptom

Diagnostic logs (gateway.err.log) repeatedly show:

[diagnostic] stuck session: sessionId=unknown sessionKey=agent:main:telegram:group:-XXX state=processing age=124s queueDepth=1 reason=queued_work_without_active_run classification=stale_session_state recovery=checking
[diagnostic] stuck session recovery skipped: reason=active_reply_work action=keep_lane sessionId=<UUID> sessionKey=agent:main:telegram:group:-XXX age=124s queueDepth=1 activeSessionId=<SAME UUID>

Repeated every ~2 minutes for 23+ days in our case (2026-05-16 through 2026-05-23). New messages from allowlisted senders queue indefinitely (queueDepth=1) and never trigger an agent run.

Reproduction

Hard to reproduce on demand, but the precondition appears to be:

1. A run starts on a group session lane
2. The run dies abnormally (child process crash, parent doesn't observe the death cleanly, or run is cancelled but lane state isn't updated)
3. Lane is stuck in processing with an activeSessionId that no longer maps to a live run
4. The stuck_session_state classifier kicks in correctly
5. The active_reply_work check returns true because it reads the lane's own activeSessionId — which is the stale one — and concludes "work is still happening"
6. Recovery permanently skipped; lane never frees

Net effect

Group chat appears dead to the agent. Outside observers (allowlisted senders tagging the bot with @bot) get no response. No user-visible error — the bot is just silent.

Suggested fix

The active_reply_work check should be a liveness probe of the referenced session/run, not a flag-read of the lane's own state. e.g.:

• Verify the activeSessionId resolves to a process/run that's actually progressing (heartbeat, recent message activity, non-zero CPU on the agent worker)
• If not progressing for N minutes, classify as stale and free the lane

Alternatively: a hard timeout on processing state (e.g., 1 hour). If a lane has been processing the same activeSessionId for >1h without forward progress, force-clear regardless.

Workaround

1. openclaw sessions cleanup --fix-missing (removes the stale sessions.json record if its transcript is missing)
2. openclaw gateway restart (clears in-memory lane state)

Environment

• OpenClaw 2026.5.7
• macOS 26.3.1
• node v24.14.0