Gateway restart causes session state loss, requiring manual intervention to resume autonomous tasks

Description

When OpenClaw executes autonomous tasks (e.g., subagent-driven workflows, long-running tool chains), the Gateway may restart at certain stages (e.g., after configuration changes, plugin updates, or internal operations). After the restart, the agent session cannot continue from the pre-restart state automatically, requiring manual intervention to resume the task.

This breaks the autonomy of long-running tasks and defeats the purpose of automated workflows.

Environment

• OpenClaw Version: 2026.4.5 (3e72c03)
• Node.js: v22.22.1
• OS: Linux 6.8.0-106-generic (x64)
• Gateway Mode: local, bind: loopback
• Channel: Feishu (direct messages)

Reproduction Steps

1. Start an autonomous task in an agent session (e.g., /omoc atlas to activate a persona-driven workflow)
2. Trigger a Gateway restart during task execution (e.g., via openclaw gateway restart or configuration changes that require restart)
3. Observe the task state after Gateway restart

Expected Behavior

After Gateway restart:

• Agent sessions should automatically resume from the last known state
• Subagents should reconnect and continue their assigned tasks
• Conversation context should be preserved across restart
• No manual intervention should be required for autonomous tasks to continue

Actual Behavior

After Gateway restart:

• Agent sessions lose their execution context
• Subagents become orphaned (no longer connected to the session)
• Conversation binding is lost
• Task execution halts until a human manually resumes the session

Evidence from Logs

2026-04-07T10:45:38.663Z info gateway/reload {"subsystem":"gateway/reload"} config change detected; evaluating reload (meta.lastTouchedVersion, meta.lastTouchedAt, plugins.entries.oh-my-openclaw.enabled)
2026-04-07T10:45:38.852Z warn gateway/reload {"subsystem":"gateway/reload"} config change requires gateway restart (plugins.entries.oh-my-openclaw.enabled) — deferring until 2 operation(s), 1 reply(ies), 1 embedded run(s) complete

The Gateway defers restart until pending operations complete, but after restart:

• Session state is not persisted/restored
• Subagent sessions are not reattached
• Conversation bindings are lost

Impact

• Severity: High
• Use Case Affected: Autonomous task execution, subagent-driven workflows, long-running automation
• Workaround: Manual intervention required after each Gateway restart (defeats automation purpose)

Root Cause Analysis (Preliminary)

Based on investigation:

1. Session state appears to be stored in-memory rather than persisted to disk
2. Subagent sessions are not serialized before restart
3. Conversation bindings (sessionKey, sessionId) are not restored after restart
4. No mechanism exists to replay pending operations after restart

Proposed Solutions

Option 1: Session State Persistence

• Persist session state (including subagent assignments, conversation bindings, pending operations) to disk before restart
• Restore session state automatically after Gateway restart
• Resume subagent sessions from persisted state

Option 2: Graceful Restart with State Handoff

• Before restart, serialize active session state
• Pass state to new Gateway instance via IPC or shared storage
• New Gateway instance restores sessions and resumes operations

Option 3: External State Store

• Use external state store (e.g., Redis, database) for session persistence
• Gateway restart becomes stateless - sessions restored from external store
• Subagents reconnect to restored sessions automatically

Additional Context

This issue was discovered during plugin development debugging, where frequent Gateway restarts are required to load code changes. The inability to resume sessions automatically significantly slows down development and testing workflows.

The issue also affects production autonomous tasks (e.g., scheduled cron jobs, background task execution) where manual intervention is not feasible.

Related Issues

• None found (searched GitHub issues for "restart", "session", "state", "subagent")

Checklist

• I have searched existing issues for duplicates
• I have provided version information
• I have provided reproduction steps
• I have provided log evidence
• I have proposed potential solutions