Description

After a gateway restart, the main session context is permanently lost. The session restart recovery mechanism times out and silently gives up, creating a new session instead of recovering the old one. Transcript files exist on disk but the old session context is orphaned.

Steps to Reproduce

1. Have an active main session with conversation history
2. Gateway restarts (e.g., after manual upgrade, config change, or system event)
3. Session restart recovery attempts to resume the interrupted main session
4. Recovery times out after 10s
5. Gateway reports recovered=0 failed=1 and creates a fresh session
6. Old session context is permanently lost from the agent's perspective

Actual Behavior

main-session-restart-recovery: failed to resume interrupted main session 
agent:ops:main: Error: gateway timeout after 10000ms
Gateway target: ws://127.0.0.1:18789
main-session restart recovery complete: recovered=0 failed=1 skipped=0

• Old session transcript files still exist on disk (e.g., 6f450225...jsonl, 342KB)
• But the session ID has changed — old context is orphaned
• Agent starts with zero context, user must re-explain everything

Expected Behavior

1. Session recovery should not silently fail on timeout — it should retry or fallback
2. If in-memory recovery fails, the gateway should attempt to reconstruct session context from the transcript JSONL files on disk
3. At minimum, the old session's conversation history should be accessible to the new session (e.g., via a "session history import" mechanism)

Impact

• Complete loss of conversation context including active subagent tasks
• User loses all context from prior conversations
• Subagent analysis results (delivered during the gap) are orphaned in a transitional session

Environment

• OpenClaw version: 2026.4.25 (aa36ee6)
• OS: Windows 10 (x64), Node v24.14.1
• Gateway: local loopback (127.0.0.1:18789)
• Channel: Telegram
• Session persistence: transcript files on disk at ~/.openclaw/agents/main/sessions/

Additional Context

The stuck session log entry appeared at gateway startup:

stuck session: sessionId=unknown sessionKey=*** state=processing age=190s queueDepth=1

This suggests the old session was still in a processing state when the restart happened. The recovery mechanism could not handle this state and timed out.

The documented behavior in background-process.md states: "Sessions are lost on process restart (no disk persistence)." However, this seems to apply to background exec sessions, not the main chat session. The main session should be recoverable from transcript files.