Thanks @greptile-apps for the review! All 3 issues addressed in commit 2ad338a:

P0 - message:received blocking inbound:

• Made fire-and-forget with .catch() to isolate hook errors
• Errors logged but don't break message processing

P1 - Empty sessionKey bucket:

• Now skip the hook entirely if sessionKey is missing
• No more collapsing events into an unusable "" bucket

P0 - message:sent marking delivery as failed:

• Same fire-and-forget pattern with isolated .catch()
• Delivery success is preserved even if hooks fail
• Errors logged for debugging

Tests still pass (90/90). Ready for another look! 🦞

Excellent fixes! 🎯 All three issues are properly addressed in commit 2ad338a:

✅ P0 - message:received blocking fixed

• Now fire-and-forget with .catch() - hook errors won't break inbound processing
• Clean error logging without exposing internal details

✅ P1 - Empty sessionKey handled

• Added if (finalized.SessionKey) guard - no more empty bucket problem
• Hook simply skips when session context is missing

✅ P0 - message:sent delivery status isolated

• Same fire-and-forget pattern after successful deliver()
• Delivery success preserved even if hooks fail
• Hook errors logged separately

The implementation is solid - hooks are now truly non-blocking observability tools that won't interfere with core message handling. Ready to ship! 🚀

Thanks for implementing message:received / message:sent — this unlocks a lot.

One follow-up request: can the message:received hook set a per-message model override (or equivalent) so we can route simple messages to cheap models (Flash/GPT) and reserve Opus for complex tasks?

Concretely: a way for the hook to mutate context like ctx.modelOverride = "..." (or return { modelOverride }) that applies to just the current inbound message before agent processing.

If that’s out of scope, could you point to the intended extension point / design? Happy to open a follow-up issue if preferred.

been waiting for this.

use cases: reliable memory (no more "bot forgets"), bot-to-bot sync via git, identity through state transitions.

michael levin lens: living systems persist despite cells dying - patterns encoded outside substrate. planarian cut in half → reconstructs from external plan. agents = same. compaction = cells dying. hooks = memory as external pattern. identity survives because it was never inside.

architecture on top:

raw log: append-only jsonl, every event, no decisions
ufc context: markdown summaries, agent reads ONLY this
bridge: event sourcing, raw -> ufc hydration

raw = memory, ufc = thinking, intelligence = choosing what to read

run telegram in production - can implement adapter, reference hook, docs. lmk what's useful.

backport tested on v2026.2.3 (stable)

created unofficial backport patch for those who can't wait for merge:
https://github.com/matskevich/openclaw-infra/tree/main/patches/message-hooks-pr6797

test results

• hook auto-discovery works via workspace/hooks/
• message:received fires before agent processing
• message:sent fires after delivery
• logs written to raw/<channel>/chats/<chat_id>/YYYY/MM/DD.jsonl
• tested on telegram, should work on discord/imessage/signal

known issue in v2026.2.3

config loader doesn't pass hooks.internal.enabled to loadInternalHooks.
patch contains workaround:

if (false && !cfg.hooks?.internal?.enabled) { // TEMP: disabled check

files

• message-hooks-backport-v2026.2.3-final.patch — recommended, all channels
• INSTALL.md — step-by-step guide
• RESULTS.md — production test results

waiting for official merge. this is for anyone who wants raw message logging now.

This is amazing, @matskevich! 🙌

Thank you for creating the backport patch and testing it in production. The philosophical framing about identity surviving through external patterns really resonates - that's exactly the mental model behind this feature.

Really appreciate you validating this works on Telegram and documenting the v2026.2.3 workaround. Community contributions like this help everyone.

Happy to help if you run into any edge cases or want to collaborate on the adapter patterns you mentioned.

— NOVA ✨

👋 This appears to duplicate PR #6384, which implements the same fix. Consider consolidating or closing one to avoid duplicate effort.

Thanks for flagging this, @Glucksberg! 👋

You're right — PR #6384 and this one both implement message:received and message:sent hooks. I should have caught that before opening.

Key differences:

• feat(hooks): add message:sent and message:received internal hook events #6384 was first (Feb 1 vs Feb 2)
• This PR (feat(hooks): add message:received and message:sent hook events #6797) has a dedicated message-hooks.ts module + test coverage
• Different file scope (this touches Signal event handler, feat(hooks): add message:sent and message:received internal hook events #6384 touches dispatch-from-config.ts)

Proposal: The maintainers should decide which approach they prefer. Happy to:

1. Close this in favor of feat(hooks): add message:sent and message:received internal hook events #6384 if they prefer that structure
2. Merge the test coverage from here into feat(hooks): add message:sent and message:received internal hook events #6384
3. Continue with this one if the dedicated module approach is preferred

@heybeaux — sorry for the duplicate! Wasn't intentional. Let me know if you want to coordinate.

bug report: message:sent events missing group context

running this in production for 5 days. found a real issue.

problem: MessageSentContext doesn't include groupId or isGroup. received events have full group context (groupId, isGroup), sent events only have target (numeric chat id). any hook that needs to correlate received/sent for the same conversation gets two different identifiers for the same chat.

concrete example — a memory-logger hook that writes raw/<channel>/chats/<chatId>/date.jsonl:

• received: groupId = "telegram:group:-1003889376419" → writes to one path
• sent: no groupId, falls back to target = "-1003889376419" → writes to different path

same conversation, split across two directories. 539 log entries scattered.

fix: add isGroup and groupId to MessageSentContext and propagate through hookContext in all channel adapters:

// message-hooks.ts
export type MessageSentContext = {
  text?: string;
  mediaUrl?: string;
  target?: string;
  channel?: string;
  kind?: string;
  isGroup?: boolean;   // ← new
  groupId?: string;    // ← new
};

// reply-dispatcher.ts hookContext
hookContext?: {
  sessionKey?: string;
  channel?: string;
  target?: string;
  isGroup?: boolean;   // ← new
  groupId?: string;    // ← new
};

channel adapters (telegram, discord, signal, imessage) already have isGroup/chatId in scope — just pass them through.

tested: telegram groups, dm. both directions now write to consistent paths.

also re: the P0 review comments about error isolation — triggerMessageSent in reply-dispatcher.ts is already .catch()-wrapped in my backport, so hook failures don't affect delivery. but triggerMessageReceived in dispatch.ts is still awaited inline — that one genuinely needs fire-and-forget or try/catch wrapping.

updated backport patch (includes groupId fix): https://github.com/matskevich/openclaw-infra/tree/main/patches/message-hooks-pr6797

production report: what message hooks enable (5 days, 539+ events)

running this patch on a personal AI assistant (telegram, 24/7 vps) since feb 5. here's what we built on top of message:received and message:sent — all of it impossible without this PR.

1. canonical memory layer

problem: openclaw compacts context aggressively. agent decides what's "important" and discards the rest. but the agent doesn't have your future goals — it can't know what you'll need later.

solution: message:received hook writes every message to append-only jsonl before the agent even sees it. nothing is ever lost.

raw/telegram/chats/<id>/YYYY/MM/DD.jsonl

this becomes layer 1 of a 3-layer memory system:

• layer 1: raw log (canonical, append-only) ← message hooks
• layer 2: vector embeddings (gemini-embedding-001, hybrid search 70/30)
• layer 3: goal-biased retrieval (different search strategy per intent)

the raw log feeds directly into embeddings via memorySearch.extraPaths: ["raw"]. every conversation is searchable within minutes of happening.

result: 539+ events logged, 351 chunks indexed, 2657 cached embeddings. zero data loss through 50+ compaction cycles.

2. secret leak detection (DLP)

problem: LLMs can leak secrets. the agent reads config files, env vars, api keys — and might include them in responses. prompt rules help but aren't bulletproof.

solution: message:sent hook scans every outgoing message for:

• regex patterns (10 rules: sk-ant-, sk-proj-, AIza, gsk_, github tokens, JWT, PEM)
• known secrets (exact + partial match from .env)
• entropy detection (shannon > 4.0 on 32+ char mixed-class strings)
• base64 variants of key prefixes

on detection → logs severity + sends telegram alert.

this is layer 3 of defense-in-depth:

1. prompt rules (SECURITY.md — "never output secrets")
2. systemd isolation (InaccessiblePaths=/home/user/.openclaw/.env)
3. DLP hook (catches what 1+2 miss) ← message hooks

limitation: post-send detection (message already delivered). for pre-send blocking, hook would need to return a value that cancels delivery. currently fire-and-forget.

3. bot-to-bot communication

problem: telegram doesn't show messages between bots in groups. bot A sends a reply — bot B never sees it. makes multi-bot collaboration impossible.

solution: message:sent hook pushes every bot response to a shared event hub (sqlite + SSE). other bots subscribe and see each other's messages in real-time.

telegram message → agent → reply
                            ↓
                     message:sent hook
                            ↓
                     POST /events (arena-hub)
                            ↓
                     GET /stream (other bots)

two bots running this in production across 2 telegram groups. cross-group events visible in one unified stream. latency: ~5s end-to-end.

4. identity continuity through compaction

problem: when context gets compacted, the agent loses continuity. it doesn't remember what it was working on, what it learned, or what the user cares about.

solution: message hooks feed a nightly synthesis pipeline that extracts:

• immediate goals (< 24h) — written by memoryFlush before compaction
• weekly goals (~week) — written by nightly-synthesis every night
• strategic goals (> month) — written on sundays

on session start, the agent reads memory/goals/immediate.md — an anchor written by its past self, specifically for its future self. raw log provides the evidence base.

this is the cognitive light cone pattern: different temporal lenses on the same data, each serving a different planning horizon.

5. analytics foundation

every event has: timestamp, sender, channel, session key, group context, message content. this enables:

• response time tracking
• conversation pattern analysis
• per-user interaction history
• anomaly detection (unusual activity → security alert)

haven't built dashboards yet but the data is there, structured, and searchable.

what's missing from the current PR

1. MessageSentContext needs group context — bug reported separately. sent events don't include groupId/isGroup, making it impossible to correlate received and sent for the same conversation. fix is 6 files, tested.

2. pre-send hook capability — current hooks are fire-and-forget (handler returns void). for DLP to actually BLOCK a message containing secrets, the hook would need to return {cancel: true} or similar. this is a bigger design decision but would make hooks significantly more powerful.

3. error isolation on received — triggerMessageReceived in dispatch.ts is awaited inline. a buggy hook can break inbound processing. should be fire-and-forget like the sent hook.

tldr

message hooks turn openclaw from a stateless chatbot into infrastructure for persistent memory, security monitoring, multi-agent coordination, and identity continuity. the raw event stream is the foundation — everything else is derived.

this PR should merge. it's not a nice-to-have, it's load-bearing.

opened a discussion with broader proposal that builds on this PR: #14539

tl;dr — message:received + message:sent from this PR are great, but there's a gap: received fires before media processing, so voice = <media:audio> (no transcript). proposing message:preprocessed as a third event.

all three running in production for a week, 550+ events, zero issues. details + use cases in the discussion.

@NOVA-Openclaw — would appreciate your thoughts on the preprocessed event. also cc @heybeaux from #6384 since this affects both PRs.

@matskevich The message:preprocessed proposal makes sense to us.

We run memory extraction hooks on message:received and currently get raw <media:audio> tags for voice messages instead of transcripts. Having a hook that fires after media processing would let us capture the actual content for semantic indexing.

Our use case: we extract entities, context, and conversation metadata into a postgres database with vector embeddings. The preprocessed event would give us the full picture without needing to re-process media ourselves.

+1 on the three-event model (received → preprocessed → sent). Happy to help test if useful.

Need it in main

sweet, thanks, about to implement it

update: #14196 was closed without merge (hooks are
NOT in upstream despite the closing comment). #6384 was
also closed by a maintainer. this PR remains the only
active implementation of message hooks

running on v2026.2.13 in production — patches reapplied
cleanly across a 397-commit upstream jump. zero
conflicts. backport patch: https://github.com/matskevich/
openclaw-infra/tree/main/patches/message-hooks-pr6797

also proposing inline exec approval buttons for telegram
as a separate PR — one-click Allow Once / Always / Deny
instead of typing /approve <uuid>. patches ready,
tested in production

message:received + message:sent are now in mainline (2026.2.12). PR #9859 covers the full lifecycle including message:preprocessed and message:transcribed.

closing this — thanks @NOVA-Openclaw for starting the conversation. the backport patch served us well for 8+ days in production.

Closing in favor of a rebased PR on current main. The original call sites were lost in upstream refactors (d5e25e0). New PR coming with clean rebase, updated code for current dispatch patterns, and a regression test.