Issue: Slack: reply_in_thread: false creates isolated session per top-level message + context lost on compression

Labels: bug, slack, session-management Environment: macOS, Hermes gateway ~/.hermes/hermes-agent/, slack-bolt adapter

Bug 1: Top-level Slack messages always spawn a new thread_id, breaking channel-wide sessions when reply_in_thread: false

Current behavior

When a user sends a top-level message in a Slack channel (not inside an existing thread), the Slack adapter treats that message as its own thread root. Even with reply_in_thread: false in config.yaml, every top-level message gets a unique session key, so channel context never accumulates across messages.

Expected behavior

With reply_in_thread: false, all top-level messages in the same channel should share a single session. Only messages explicitly posted inside an existing thread should spawn a thread-scoped session.

Root cause

In gateway/platforms/slack.py, the ingestion code falls back to the message's own ts when no thread_ts is present:

• File: gateway/platforms/slack.py
• Line 1094:

  thread_ts = event.get("thread_ts") or ts

Because event.get("thread_ts") is None for top-level messages, thread_ts becomes the message's own timestamp (ts). This synthetic thread_ts is then passed through to the session manager:

• Line 1247: build_source(thread_id=thread_ts)
• Line 1264–1267: MessageEvent created with reply_to_message_id=None (correctly), but source.thread_id=ts (incorrectly for session purposes).

The session store keys sessions by (platform, channel_id, thread_id). Because every top-level message gets a distinct thread_id == ts, each one creates a brand new session instead of reusing the channel session.

Suggested fix

Change the fallback behavior at the ingestion layer so that thread_id is only set to a real Slack thread_ts (i.e., an existing thread root). For a true top-level message, thread_id should remain None, allowing the session store to group it under a single channel-scoped session.

Specifically, at gateway/platforms/slack.py around line 1247, pass the raw event.get("thread_ts") (not the synthetic ts fallback) into build_source(thread_id=...), so that top-level messages produce thread_id=None.

A separate, smaller fix may also be needed in gateway/platforms/slack.py around line 1094 (and the corresponding thread_meta construction in _send_with_retry) to ensure outbound replies are also not threaded when the message was genuinely top-level.

Bug 2: Session metadata is not persisted, causing total context loss on compression or eviction

Current behavior

When the agent's context window fills up and triggers a compression/split event, the gateway correctly creates a new session and (in theory) links it to the prior session's summary. However, after a gateway restart or cache eviction, the session metadata is lost, and the new session starts without any linkage to the previous context. The result is a total context drop.

Evidence from logs

Context was lost during a real conversation on 2026-04-24:

Log timestamp: At 15:24:34 the gateway performed a session split/compression. After the split, a later gateway restart (or cache eviction) produced the log line:

Agent cache idle-TTL evict: session=agent:main:slack:group:C0AU7N1MMQX:1777065616.184669 (idle=3719s)
Gateway event (load): session=agent:main:slack:group:C0AU7N1MMQX:1777065616.184669

The new session loaded at 15:36 did not carry forward the compressed context from the original session.

Root cause

Session metadata is supposed to be persisted to disk so that the gateway can reconnect a Slack channel/thread to its existing session after restarts or evictions.

• File: ~/.hermes/sessions/sessions.json
• Observed state: Total entries: 0

Despite sessions existing in memory, sessions.json is empty, meaning SessionStore._save() either:

1. Is never called for Slack sessions,
2. Fails to serialize Slack session entries, or
3. Writes to a file that is not being read back on startup.

Because the metadata is lost, the gateway cannot map slack:group:C0AU7N1MMQX:1777065616.184669 (the thread/channel key) back to the prior session ID. Instead it mints a fresh session (20260424_153618_6765bed0), losing all compressed context.

Suggested fix

Investigate gateway/session.py (SessionStore._save() and the Slack-specific session entry creation) to determine why Slack sessions are not being serialized. Verify:

1. Slack session entries are added to the store's internal dict.
2. _save() is triggered on session creation/update.
3. The JSON serialization does not silently drop Slack entries (e.g., due to non-serializable types in the Slack adapter metadata).
4. On startup, the gateway loads sessions.json and correctly resolves a Slack group:* key to the stored session ID.

Additional context / config

# ~/.hermes/config.yaml
slack:
  require_mention: false
  reply_in_thread: false
  channel_prompts: {}

• require_mention: false works correctly.
• reply_in_thread: false is partially respected for outbound reply placement (see _resolve_thread_ts, gateway/platforms/slack.py line 437–442), but the damage is already done because the session key is isolated per message.

Checklist for fix verification

• Send two top-level messages in the same Slack channel with reply_in_thread: false. Confirm they share the same session ID.
• Restart the gateway. Confirm the same session ID is restored and context is retained.
• Start a threaded reply. Confirm it spawns a child session (or thread-scoped session) correctly, without leaking into the main channel session.
• Confirm sessions.json contains a non-zero number of Slack session entries after normal operation.