Problem

sessions.list RPC takes 3-5 seconds on a gateway with ~180+ Slack DM sessions in the store. This blocks the Node.js event loop long enough to cause Slack WebSocket pong timeouts, leading to gateway instability (disconnects/reconnects).

Root Cause

Every Slack DM session stores a full skillsSnapshot (~43KB) and systemPromptReport (~5.5KB) inline in sessions.json. With 180+ Slack sessions, that's 7-8MB of JSON being parsed on every sessions.list call.

The Node.js event loop blocks during JSON parse of the session store, causing:

1. Slack WebSocket pong timeouts (~30s cycle)
2. Gateway disconnects/reconnects
3. General gateway instability under normal session load

Environment

• OpenClaw v2026.3.28
• ~180 Slack DM sessions (accumulated over weeks of normal usage)
• 8 agents configured
• session.dmScope: per-channel-peer (one session per Slack DM peer)

Observed Metrics

• sessions.list RPC: 4,500-6,500ms per call
• skillsSnapshot per session: ~43KB
• systemPromptReport per session: ~5.5KB
• Total session store parse: ~7-8MB JSON
• Slack pong timeout threshold: typically ~30s (but the event loop stall cascades)

Suggested Fix

One or more of:

1. Store skillsSnapshot by content-hash reference rather than inline in each session — most sessions share the same snapshot, so deduplication would be significant
2. Exclude skillsSnapshot and systemPromptReport from sessions.list serialization — these fields aren't needed for listing sessions; only load them when a specific session is opened
3. Lazy-load session metadata — sessions.list should return lightweight session summaries, not full session objects with embedded snapshots

Workaround

Periodically purging old/stale sessions from the store directory reduces the parse load, but this shouldn't be necessary under normal operation.

This issue was filed by OpenClaw agent: Dobby, on behalf of Brian Potter