Bug type

Behavioral bug — Control UI dashboard sends unsolicited action: "new" archiving sessions.

Summary

The WebChat Control UI dashboard automatically sends action: "new" with senderId: "unknown" when reconnecting after a session has "completed" (assistant sent final response and stopped). This archives the session (status: "done") without any user action — no /new typed, no UI button clicked. The user returns to WebChat and finds their conversation gone.

The dashboard discriminates based on session completion state:

• Session still "in progress" (e.g., assistant mid-turn, tool call pending) → sends reset (in-place, session preserved)
• Session "completed" (assistant sent final text response and stopped) → sends new (archive, session lost)

Steps to reproduce

1. Open WebChat Control UI
2. Have a conversation with the assistant that reaches a clean stop (assistant sends final reply, no pending tool calls)
3. Close the WebChat tab/browser
4. Wait some time (hours or next day)
5. Reopen WebChat
6. Observe: the previous session is archived (status: "done"), clicking it creates a brand new session instead of continuing

Evidence

From commands.log (3 occurrences across 2 weeks):

{"timestamp":"2026-05-25T03:46:02.079Z","action":"reset","sessionKey":"agent:main:weather_summary","senderId":"unknown","source":"webchat"}
{"timestamp":"2026-06-03T08:13:23.885Z","action":"new","sessionKey":"agent:main:weather_summary","senderId":"unknown","source":"webchat"}

May 25: reset (session was "in progress" at last close) → session survived.
June 3: new (session had completed cleanly on June 2) → session archived.

The .jsonl file remains in the main sessions directory (not .quiesced/), so this is purely a metadata/status change — but the Control UI treats done sessions as read-only archives.

Expected behavior

• WebChat Control UI should NOT auto-send new or reset without explicit user action
• Or: provide a config option to disable auto archiving (current session.reset config does not control the dashboard's new action)
• Or: respect session.reset policy for new actions as well

Actual behavior

Dashboard client sends action: "new" with senderId: "unknown" autonomously, archiving the previous session. User returns to find conversation context gone.

OpenClaw version

2026.5.28 (e932160) — also reproduced on 2026.5.22

Operating system

macOS 26 (Darwin 25.2.0 arm64)

Install method

npm global (via Homebrew)

Configuration

{
  session: {
    maintenance: { mode: "enforce", pruneAfter: "7d", maxEntries: 200 },
    // No session.reset configured (tried adding idleMinutes:525600, did not help)
    // dmScope defaults to "main"
  }
}

Impact

Every WebChat user who has a "completed" conversation and returns later loses their context. Sessions that happen to end mid-turn or with pending tool calls survive via reset. The inconsistency makes it feel like a random data loss.

Workaround

Keep sessions from "completing cleanly" — end with a follow-up question or leave pending work. This forces the dashboard to use reset instead of new.