Summary

A Telegram direct session can remain persisted as status: running after a gateway restart/interruption, even though the gateway has no active task or active run for that session. Once this happens, Telegram polling may be healthy and inbound messages may be recorded, but replies do not complete until the affected session is manually reset.

Environment

• OpenClaw: 2026.6.1 (2e08f0f)
• Install/runtime: npm package, native macOS LaunchAgent
• OS/runtime: macOS 15.7.5 arm64, Node 25.4.0
• Channel: Telegram, polling mode
• Gateway: loopback, LaunchAgent-managed

Observed behavior

After a Telegram direct message triggered a model call, the session stalled and the gateway was restarted while the run was still in progress. After restart:

• openclaw gateway status reported the gateway reachable and running.
• openclaw channels status --probe reported Telegram enabled/configured/running/connected/works.
• openclaw gateway call status showed no active work:
  • tasks.active = 0
  • tasks.byStatus.running = 0
  • tasks.byStatus.queued = 0
• openclaw gateway call sessions.list still showed the Telegram direct session as:
  • key: agent:main:telegram:direct:<redacted-peer-id>
  • status: running
  • hasActiveRun: false

In this state, new Telegram messages were not getting normal replies. A manual RPC reset of the affected session fixed the problem immediately:

openclaw gateway call sessions.reset --params '{"key":"agent:main:telegram:direct:<redacted-peer-id>","reason":"reset"}'

After the reset:

• The same session became status: done, hasActiveRun: false.
• Telegram channel status showed recent inbound activity.
• New Telegram inbound logs appeared.
• Telegram outbound sends resumed successfully.

Relevant redacted log excerpts

The earlier stalled run looked like this:

stalled session: sessionKey=agent:main:telegram:direct:<redacted-peer-id> state=processing reason=active_work_without_progress classification=stalled_agent_run activeWorkKind=model_call

After restart/recovery, the persisted session state was inconsistent:

{
  "key": "agent:main:telegram:direct:<redacted-peer-id>",
  "status": "running",
  "hasActiveRun": false
}

Manual reset fixed it:

{
  "key": "agent:main:telegram:direct:<redacted-peer-id>",
  "status": "done",
  "hasActiveRun": false
}

Expected behavior

On gateway startup or stuck-session recovery, OpenClaw should detect persisted sessions that are marked running but have no corresponding active run/task, then transition them to a terminal/interrupted state or otherwise release the lane automatically.

A session with status: running and hasActiveRun: false should not block future Telegram messages indefinitely.

Actual behavior

The persisted Telegram direct session remained running after restart with no active run. New Telegram messages were affected until sessions.reset was manually called for the affected session key.

Possible fix direction

Add startup/recovery reconciliation for session store entries, for example:

• Scan persisted session entries on gateway startup.
• For any entry with status === "running" but no tracked active run/task after recovery, mark it as interrupted/aborted/done and release the session lane.
• Ensure Telegram direct/slash lanes cannot remain blocked by a stale persisted running entry when hasActiveRun === false.

Notes

There was also a temporary Telegram Bot API polling conflict during debugging caused by an external getUpdates request. That produced the expected Telegram conflict error and polling restart, but it appears separate from the stale session issue. The stale state was specifically visible as status: running with hasActiveRun: false, and it was fixed by sessions.reset.