Bug type

Behavior bug (incorrect output/state without crash)

Summary

Daily session reset configured via session.resetByType.direct / session.resetByType.group with mode: "daily" does not appear to rotate real conversation sessions such as Telegram direct chats.

In my setup, the affected session is:

• agent:paco:telegram:direct:837157824

That conversation remained on the same sessionId across multiple days, including after the configured reset hour had passed and after a new inbound message arrived later that morning.

At the same time, the agent main/heartbeat session:

• agent:paco:main

does reset correctly between days.

So this does not look like "session reset is completely broken". It appears to specifically affect real conversation sessions, while main sessions continue to rotate normally.

I have a strong suspicion that the problem is in the inbound conversation-session path, potentially involving metadata writes happening before freshness is evaluated, but I have not fully proven the exact internal root cause end-to-end yet. The externally observable bug is confirmed.

Steps to reproduce

1. Configure session reset in openclaw.json:

{
  "session": {
    "resetByType": {
      "direct": { "mode": "daily", "atHour": 1 },
      "group": { "mode": "daily", "atHour": 1 }
    }
  }
}

2. Run an agent connected to Telegram direct chat
3. Let the conversation continue across multiple days
4. Wait until after the configured reset hour has passed
5. Send a new inbound message later that morning
6. Check the active session key / session id

Note: in the same installation, agent:NAME:main sessions do reset correctly. The issue appears to affect real channel conversation sessions such as agent:NAME:telegram:direct:PEERID.

Expected behavior

When a message arrives after the configured daily reset hour, the conversation session should be detected as stale, a new sessionId should be generated, and the new conversation turn should continue in a fresh session.

For example, with:

• session.resetByType.direct.mode = "daily"
• session.resetByType.direct.atHour = 1

the first Telegram direct inbound message after 1:00 AM local time should rotate the session.

Actual behavior

The real Telegram direct conversation session does not rotate.

Observed behavior in my installation:

• session key: agent:paco:telegram:direct:837157824
• active session id in the store: 22a59560-dfe5-45ce-9470-01b8f03895ec
• that same session started on March 11, 2026
• that same session was still active on March 14, 2026
• after a real inbound message on March 14, 2026 at 10:08 AM local time, the conversation still remained on the same session

Meanwhile:

• agent:paco:main did rotate correctly between March 13 and March 14

So the configured daily reset is not being applied consistently across session types / code paths.

Strong suspicion, but not yet fully proven:

1. The inbound conversation path may be updating session metadata before freshness is evaluated
2. If updatedAt is refreshed too early, the session would incorrectly appear fresh
3. That would explain why main sessions rotate while real Telegram direct conversation sessions do not

OpenClaw version

2026.2.26

Operating system

macOS 15.4 (Sequoia), Mac mini M1

Install method

npm (global): npm install -g openclaw

Model

google/gemini-3-flash-preview

Provider / routing chain

Local gateway loopback :18789, 4 agents (Telegram + Discord)

Config file / key location

session.resetByType.direct
session.resetByType.group

Additional provider/model setup details

session.dmScope = "per-channel-peer"

Global reset is also configured:

{
  "session": {
    "reset": {
      "mode": "daily",
      "atHour": 4,
      "idleMinutes": 120
    }
  }
}

Logs, screenshots, and evidence

Confirmed observable evidence from the affected installation:

Affected real conversation session:
- key: agent:paco:telegram:direct:837157824
- current sessionId in store: 22a59560-dfe5-45ce-9470-01b8f03895ec

Observed timeline:
- session transcript starts on March 11, 2026
- same session remains active on March 12, 2026
- same session remains active on March 13, 2026
- same session remains active on March 14, 2026
- after a real inbound message on March 14, 2026 at 10:08 AM local time, session_status still reports:
  Session: agent:paco:telegram:direct:837157824

Control comparison:
- agent:paco:main does rotate correctly between March 13 and March 14 in the same installation

So the failure is reproducible as:
- reset config is present
- reset hour has passed
- real inbound arrives later that day
- conversation session still does not rotate
- main/heartbeat session does rotate

Impact and severity

This breaks the expected behavior of daily conversation rotation for real user chats.

In practice:

• conversation context keeps accumulating across days
• users cannot rely on resetByType.direct for Telegram direct chats
• /new or /reset becomes the only reliable workaround for starting a clean daily conversation session

Additional information

• I reviewed recent release notes and did not find an obvious documented fix for this exact issue
• However, I have not yet runtime-verified the behavior on 2026.3.13
• So this report is fully confirmed against 2026.2.26; newer versions may still need verification
• The global session.reset fallback may be affected by the same mechanism
• idleMinutes-based reset may also be affected for real conversation sessions
• I did not find an existing public issue that clearly matches this exact runtime behavior
• Possibly related: requestHeartbeatNow with sessionKey silently skips for channel sessions (agent:main:slack:channel:*) #34338, Heartbeat checks wrong session queue for exec completion events #14191, [Bug]: Regression 2026.2.13: Discord guild channel messages route to agent:main:main (main DM session); per-channel sessions ignored (works on 2026.2.12) #16149, Feishu DM ignores dmScope configuration and routes to agent:main:main #10172