Send your assistant a photo. Watch its memory disappear.

What happens

Send a photo to your OpenClaw bot on Telegram. Any photo. A sunset, your cat, a screenshot of the bug you're about to report. The gateway processes the image, your assistant responds, and everything looks fine.

Except it's not fine. Your memory plugin just died. Your context engine just died. Your guardrails just died. Every plugin loaded via plugins.load.paths has been silently wiped from the hook runner, and they're never coming back. Not until you restart the gateway. And you won't know to restart, because there's no error. No crash. No warning you'd notice unless you're actively watching logs for an info-level message about an empty allowlist.

Your assistant is now running without memory. Every conversation after that photo is a first conversation. And it'll keep happening after every restart, the next time someone sends media.

How we found it

We run a home gateway with openclaw-mem0 and lossless-claw (LCM context engine) loaded via plugins.load.paths. We noticed memories stopped being captured after a few hours of normal use. No errors. Same PID. Restarting fixed it, but it kept coming back.

We spent a while chasing memory leaks, hook dispatch races, and plugin re-registration bugs before landing on the real pattern: it broke every time someone sent a photo in a group chat. Not sometimes. Every time.

We added a stack trace diagnostic to the warnWhenAllowlistIsOpen path, sent a photo, and got our answer in one shot.

Root cause

When a media message arrives, the pipeline calls applyMediaUnderstanding() to process attachments. This function calls buildProviderRegistry(params.providers), passing provider overrides but forgetting to pass cfg (the gateway config). One function deeper, buildMediaUnderstandingRegistry falls back to:

loadOpenClawPlugins({ config: cfg }) // cfg is undefined here

Because activate defaults to true, this:

1. Builds a fresh plugin registry from config: undefined (no plugins.allow, no plugins.load.paths)
2. Discovers only extension-dir plugins
3. Replaces the global active registry via setActivePluginRegistry()
4. Replaces the global hook runner via initializeGlobalHookRunner()

The new hook runner has zero hooks from your path-loaded plugins. agent_end, before_agent_start, before_tool_call: all gone. The gateway keeps running, messages keep flowing, but everything that made your assistant yours is dead.

The irony: params.cfg is right there on the params object. It just never gets passed down.

The call chain

dispatchInboundMessage
  → withReplyDispatcher
    → dispatchReplyFromConfig
      → getReplyFromConfig
        → applyMediaUnderstandingIfNeeded
          → applyMediaUnderstanding (src/media-understanding/apply.ts)
            → buildProviderRegistry(params.providers)     ← cfg not passed
              → buildMediaUnderstandingRegistry(overrides, undefined)
                → loadOpenClawPlugins({ config: undefined })
                  → activatePluginRegistry()              ← replaces hook runner
                    → initializeGlobalHookRunner(emptyRegistry)

What you'll see in logs

If you know to look:

• [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load fires right after the first photo
• [tools] agents.*.tools.allow allowlist contains unknown entries (memory_forget, lcm_describe, ...) because the plugin tools vanished with their plugins
• Zero agent_end or before_agent_start hook activity from path-loaded plugins after the trigger
• No crash. Same PID. No restart. Just silence where your plugins used to be.

Reproduction

1. Set up a gateway with any plugin using agent_end or before_agent_start hooks, loaded via plugins.load.paths
2. Start the gateway, confirm hooks fire on text messages
3. Send a photo to the bot (any channel with media support)
4. Hooks stop firing. Check logs for the plugins.allow is empty warning.
5. Restart gateway. Hooks work again. Send another photo. They're gone again.

Who this affects

Anyone who:

• Loads plugins via plugins.load.paths (not bundled or in the extensions directory)
• Receives media messages (photos, stickers, audio, video) on any channel
• Relies on plugin hooks for anything (memory, analytics, guardrails, logging)

That's probably most people running custom plugins. This is a silent data-loss bug for memory plugins, a silent security regression for guardrail plugins, and a silent feature regression for everything else.

Fix

Five changes across five source files. Change 1 fixes the root cause. Changes 2-5 are defense-in-depth so this class of bug can't recur through other code paths.

Change 1 (root cause): src/media-understanding/apply.ts

Pass cfg to buildProviderRegistry:

- const providerRegistry = buildProviderRegistry(params.providers);
+ const providerRegistry = buildProviderRegistry(params.providers, params.cfg);

Change 2: src/media-understanding/provider-registry.ts

buildMediaUnderstandingRegistry only needs to read provider entries. It should never activate the registry:

- const pluginRegistry = (...) > 0 ? active : loadOpenClawPlugins({ config: cfg });
+ const pluginRegistry = (...) > 0 ? active : loadOpenClawPlugins({ config: cfg, activate: false, cache: false });

Change 3: src/tts/provider-registry.ts

Same pattern in resolveSpeechProviderPluginEntries:

- loadOpenClawPlugins({ config: cfg })
+ loadOpenClawPlugins({ config: cfg, activate: false, cache: false })

Change 4: src/media-understanding/runner.ts

resolveAutoImageModel has the same missing-cfg pattern:

- const providerRegistry = buildProviderRegistry();
+ const providerRegistry = buildProviderRegistry(undefined, params.cfg);

Change 5: src/media-understanding/audio-transcription-runner.ts

runAudioTranscription, same thing:

- const providerRegistry = buildProviderRegistry(params.providers);
+ const providerRegistry = buildProviderRegistry(params.providers, params.cfg);

Testing

All five changes verified on a live OpenClaw 2026.3.24 gateway running 7 agents, openclaw-mem0, and lossless-claw. Multiple JPEG photos sent across multiple gateway restarts. Before fix: every single photo triggered the registry wipe. After fix: zero occurrences across all tests.

Related issues

• #47625: Same root cause class. loadOpenClawPlugins secondary call overwrites the active plugin registry. Fix in PR #47902 addressed HTTP route registry via pinning but didn't cover hook runner replacement.
• #30674: Identical trigger (Telegram stops working after receiving image). Closed with a message-thread-ID fix that likely didn't address the underlying registry wipe.
• #40929: Gateway unresponsive after plugin install. Same cascade.
• #5513: Plugin hooks never invoked. Hooks register but hasHooks() returns false, consistent with hook runner replacement.
• #23452: Vision/image recognition broken across channels. Same buildMediaUnderstandingRegistry code path.

A note on the broader pattern

The real issue is that loadOpenClawPlugins defaults to activate: true. That makes sense for bootstrap, but it's a footgun for every secondary caller that just needs to peek at provider lists. Five of the nine call sites in the codebase exist only to read plugin data, not to set up the runtime. They shouldn't be able to nuke the hook runner as a side effect.

Some options worth considering:

1. Flip the default to activate: false (breaking change, needs an audit of all callers)
2. Separate "load plugins" from "activate registry" into distinct functions
3. Add a runtime assertion that activate: true is only called during startup

Disclosure

This investigation was AI-assisted (Claude Opus 4.6 for diagnosis and stack tracing, Claude Code for source mapping). Fully tested on our live gateway. We understand what the code does and have been living with the consequences of this bug for weeks.

Version: OpenClaw 2026.3.24 (also present in 2026.3.28) Platform: Ubuntu 24.04, Node v24.14.0 Channel: Telegram (but the bug is channel-agnostic; any media-capable channel triggers it)