Problem

When the gateway restarts, the session context survives (conversation history is persisted, the agent can resume), but the active client connection drops and the user must manually re-prompt to pick the thread back up.

This creates a disruptive experience for operators using webchat, TUI, or any persistent client:

1. Agent is mid-conversation (e.g., testing a model config change that requires restart)
2. openclaw gateway restart runs
3. Gateway comes back, client WebSocket reconnects automatically
4. But the agent sits silent — the conversation thread is abandoned
5. User must send a new message like "you good?" to re-engage
6. Agent has full context but has lost the "active turn" — it doesn't know it was mid-task

This is especially painful when the restart itself was triggered by the agent (e.g., to reload a config change), since the agent caused the interruption but can't automatically resume.

Proposed Solution: Post-Restart Thread Resume

When a client reconnects after a gateway restart, the gateway should detect that the session had an active turn in progress and either:

Option A: Automatic resume signal

• Gateway detects the session had an incomplete agent turn at shutdown time
• On client reconnect, gateway injects a system message: "Gateway restarted. Resuming previous context."
• Agent sees this and can acknowledge/continue naturally
• Minimal change — just a synthetic reconnect event

Option B: Client-side reconnect prompt

• On WebSocket reconnect, the client (TUI/webchat) detects the session was active pre-restart
• Client automatically sends a resume prompt: "Gateway reconnected. Continue where you left off."
• Agent picks up naturally

Option C: Decouple session state from gateway process (longer term)

• Session turn state written to disk/shared memory before shutdown
• On restart, gateway reads pending turn state and resumes delivery
• Most robust but highest complexity
• Could leverage gracefulShutdown drain phase from Graceful gateway shutdown: drain active sessions before restart #32961

Why This Matters

The gateway restart is the single most common workflow disruption for power users. Common triggers:

• Config changes (model additions, security settings, cron edits)
• OpenClaw updates
• System restarts

The conversation history already persists — the missing piece is the active thread handoff. The agent has full context post-restart; it just doesn't know it should keep going.

Related Issues

• Graceful gateway shutdown: drain active sessions before restart #32961 — Graceful gateway shutdown: drain active sessions before restart (pre-restart)
• Resume interrupted agent sessions and cron runs after gateway restart #30043 — Resume interrupted agent sessions and cron runs after gateway restart
• feat: persist and recover ACP sessions across gateway restarts #29870 — Persist and recover ACP sessions across gateway restarts
• Feature request: Native gateway restart with deferred message delivery #26986 — Native gateway restart with deferred message delivery
• [Bug]: gateway restart command loses result in exec tool (timeout issue) #32933 — gateway restart command loses result in exec tool

Environment

• OpenClaw 2026.3.2
• macOS (Darwin arm64)
• Affected clients: webchat (TUI), likely also Telegram/Discord for in-flight messages

Practical Example

User: "Test this new model config for me"
Agent: [adds model to config, runs gateway restart]
  -- connection drops --
  -- gateway restarts in 5-10s --
  -- webchat reconnects --
  -- silence --
User: "...you there?"
Agent: "Yeah I'm good! Where were we?"

The agent had full context the entire time. The gap is purely in the connection handoff.