Description

When the TUI client reconnects to the gateway (e.g., after a network interruption or terminal restart), it creates a brand new session instead of resuming the previous session. This silently resets the conversation context. The user's ongoing conversation history becomes invisible to the new session, even though the old session's transcript is preserved as a .reset file on disk.

This is particularly disruptive when a conversation has been going on for a while and the user expects continuity.

Steps to Reproduce

1. Start a conversation in the TUI (openclaw tui)
2. Chat for an extended period (the issue seems more likely with longer sessions)
3. Disconnect the TUI (e.g., close terminal, network interruption, or Ctrl+C)
4. Reconnect by running openclaw tui again
5. Send a message

Expected Behavior

The TUI should resume the previous session, maintaining full conversation continuity. If a new session must be created for technical reasons, the old session's context should be carried over or at least the user should be explicitly warned that they're starting fresh.

Actual Behavior

The TUI creates a new session with a new session key (e.g., agent:main:tui-<new-uuid> instead of continuing under the previous key like agent:main:main). The old session is silently reset — its transcript is archived as <id>.jsonl.reset.<timestamp> but the new session has zero context from the previous conversation.

The user only notices something is wrong when the assistant can't recall anything discussed moments ago.

Environment

• OpenClaw version: 2026.4.25 (aa36ee6)
• OS: Linux 6.6.87 (WSL2)
• Channel: TUI (webchat)

Additional Context

I observed this with two sessions being reset within ~14 minutes during a TUI reconnection:

1. A cron run session (daily-journal-auto) was reset when a new cron run started — this is expected behavior.
2. The main TUI conversation session was reset when the TUI reconnected — this is the problematic case. The session key changed from agent:main:main to agent:main:tui-<uuid>, creating a completely new session with no conversation history.

The old session's full transcript was preserved in a .reset file and could be recovered by manually reading the file, but the assistant in the new session had no way to access it through normal tools (sessions_history, memory_search, etc. don't expose reset session transcripts).

Suggested Fix

1. When TUI reconnects, it should attempt to resume the most recent session under the same or equivalent session key, preserving conversation context.
2. If a new session must be created, surface a clear warning to the user.
3. Consider providing a /resume command or mechanism to carry over context from a recently reset session.