New thread in slack does not trigger memory write

[humble plaza]

When I create a new thread on the agent UX toolbox in slack, this does not create a new chat (and does not trigger the memory write hook).

Findings from my review;

Looking at the logs, here's what actually occurred:

The previous session was in Slack thread 1773321908.720229 (session ID 6be56867). Willy handled several messages there, and at some point wrote the single memory entry manually.

The "new session" at 21:38:42 came from a brand-new Slack thread 1773351433.743289 with a fresh session ID 9fb0b27e. This is the session you're looking at now.

Why no memory was written: The session-memory hook is registered to fire on command:new and command:reset events — these are triggered only when you explicitly send /new or /reset to Willy in the existing thread. Starting a fresh DM thread in Slack doesn't fire either of those commands, so the hook never ran and no automated session summary was written.

Can you confirm this? And don't you consider this an issue?

[unique geyser]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[frank gorge]

True

[torpid jackal]

Yes — your read of it matches how the bundled session-memory hook works today.

What I can confirm from current OpenClaw source/docs

• The bundled hook session-memory is registered for command:new and command:reset (i.e. when you explicitly issue /new or /reset in an existing chat/thread).
  Source: src/hooks/bundled/session-memory/HOOK.md (events: ["command:new","command:reset"])
• Creating a brand-new Slack thread results in a new session (new session id / session file), but it does not implicitly emit a command:new or command:reset event for the previous session. So nothing triggers session-memory, and no automated memory snapshot gets written.

So the “why no memory was written” part of your analysis is correct: it’s not that the new Slack thread didn’t make a new session; it’s that the hook is not wired to “Slack thread created / new conversation started” events.

Is that an issue?

I’d call it a legit UX gap / missing lifecycle event, not a “bug in the hook”.

From the hook system’s point of view, this is consistent: the hook runs on explicit reset/new commands because those are unambiguous “close out this session and summarize it” moments.

From a Slack UX point of view, it’s easy to expect “start a new thread” == “start a new chat” == “summarize the previous one”, and OpenClaw doesn’t currently have a first-class event for that (docs even list session:start / session:end as planned future events, which is basically what you want here).

Practical workarounds (today)

• If you want the automated memory write, do /reset (or /new) in the thread you’re leaving before starting the new Slack thread.
• If you want “thread change == session summary”, that likely needs either:
  1. a Slack UX toolbox change (make “new chat” actually send /new//reset), or
  2. new hook events like session:end / conversation:switched, or Slack-specific “thread created” events.

Next step

I do think it’s worth tracking as a product issue/feature request. If you file it on GitHub, I’d phrase it like:

• “Slack: starting a new thread should optionally trigger session summary / session-memory for the previous thread”
• or “Add session:end hook event so session-memory can run on session closure independent of /reset”

GitHub issues: https://github.com/openclaw/openclaw/issues

If you paste the relevant log lines (showing the two Slack thread ids + the two session ids) and your openclaw --version, I can help suggest the tightest repro + expected behavior wording for the issue.