openclaw - 💡(How to fix) Fix Follow-up to #72875: local memory canary on 2026.4.27 triggers broad channel runtime-deps installs and gateway probe timeouts [1 comments, 2 participants]

Follow-up to #72875.

We originally hit the memorySearch.provider = "local" path on 2026.4.23, where the memory runtime failed with Unknown memory embedding provider: local even though the capability embedding path could see and use the local provider.

I moved this same VPS to 2026.4.27 because the recent release notes looked relevant: provider/plugin startup, runtime deps, gateway startup prewarm, Telegram startup fixes, and update hardening. The original Unknown provider: local symptom no longer seems to be the first failure. But when I tried a careful local-memory canary today, enabling memory-core kicked the gateway into a much broader bundled runtime-deps/channel discovery path, and the gateway became hard to reason about again.

This is not a polished repro from a clean VM. It is a production-ish OpenClaw agent VPS, so I am writing it as an operator report with the exact sequence and evidence.

Environment

• OpenClaw: 2026.4.27 (cbc2ba0)
• OS: Ubuntu 24.04 VPS, Linux 6.8.0-110-generic
• Node: 22.22.2
• Install: global npm package under /home/amiro/.npm-global
• Gateway: user systemd service, 127.0.0.1:18789
• Main channel in use: Telegram only
• Local memory model exists: embeddinggemma-300m-qat-Q8_0.gguf
• Memory DB exists: /home/amiro/.openclaw/memory/main.sqlite

Baseline before the canary

The stable posture was intentionally conservative after the .27 update:

• Telegram enabled and usable
• agents.defaults.memorySearch.enabled = false
• plugins.entries.memory-core.enabled = false
• plugins.deny included memory-core
• hooks/browser/side plugins disabled or denied
• no watchdog cron and no openclaw message send smoke tests, because those had previously contributed to session/store locking during update recovery

Canary change

I enabled only the local-memory path and disabled auto-sync to avoid a big indexing run:

{
  "agents": {
    "defaults": {
      "memorySearch": {
        "enabled": true,
        "provider": "local",
        "fallback": "none",
        "sync": {
          "onSessionStart": false,
          "onSearch": false,
          "watch": false,
          "intervalMinutes": 0
        }
      }
    }
  },
  "plugins": {
    "entries": {
      "memory-core": {
        "enabled": true
      }
    }
  }
}

I also removed memory-core from plugins.deny.

openclaw config validate passed.

What happened

The config reload detected the memory/plugin changes and required a gateway restart:

[reload] config change detected; evaluating reload (agents.defaults.memorySearch.enabled, agents.defaults.memorySearch.sync.onSessionStart, agents.defaults.memorySearch.sync.onSearch, agents.defaults.memorySearch.sync.watch, agents.defaults.memorySearch.sync.intervalMinutes, plugins.entries.memory-core.enabled, plugins.entries.memory-core.config, plugins.deny, plugins.slots)
[reload] config change requires gateway restart (plugins.entries.memory-core.enabled, plugins.entries.memory-core.config, plugins.deny, plugins.slots)

After restart, the gateway did load with memory-core present:

[gateway] http server listening (3 plugins: bonjour, memory-core, telegram; 35.0s)
[gateway] ready

But then it became slow/unresponsive from the admin probe side. openclaw gateway status reported the process running and the port bound, but the WebSocket connectivity probe timed out:

Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
  timeout
Runtime: running (... state active ...)

The diagnostic logs showed event-loop trouble during that window:

[diagnostic] liveness warning: reasons=event_loop_delay,event_loop_utilization interval=292s eventLoopDelayP99Ms=91.7 eventLoopDelayMaxMs=52814.7 eventLoopUtilization=0.953 cpuCoreRatio=0.189 active=0 waiting=0 queued=0

At that point I rolled the memory config back to the previous stable posture. Memory was off again, memory-core was disabled again, and memory-core was back in plugins.deny.

The surprising part

Even with memory rolled back, the gateway continued installing bundled runtime deps for channels we do not use.

Examples observed from systemctl --user status / journal:

npm install @grammyjs/runner@^2.0.3 @grammyjs/transformer-throttler@^1.2.1 grammy@^1.42.0 [email protected]
npm install @whiskeysockets/[email protected] jimp@^1.6.1
npm install @azure/[email protected] @microsoft/[email protected] @microsoft/[email protected] [email protected] [email protected] [email protected]

The box only needs Telegram. We are not using Microsoft Teams, WhatsApp/Baileys, Discord, Google Chat, etc.

The gateway would log ready, but openclaw gateway status still timed out while these installs/discovery paths were active.

Interruption makes it worse

Stopping during this path is dangerous. A stop/restart during one of these installs caused systemd to time out and SIGKILL the gateway and an npm install child:

openclaw-gateway.service: State 'stop-sigterm' timed out. Killing.
openclaw-gateway.service: Killing process ... (node) with signal SIGKILL.
openclaw-gateway.service: Killing process ... (npm install @an) with signal SIGKILL.

After that, the .27 plugin runtime deps tree appeared partially inconsistent, and logs showed missing bundled channel files:

[channels] failed to load bundled channel discord: ENOENT: no such file or directory, open '/home/amiro/.openclaw/plugin-runtime-deps/openclaw-2026.4.27-c3c756f1ad50/dist/conversation-binding-context-CPuFBW6N.js'
[channels] failed to load bundled channel googlechat: ENOENT: no such file or directory, open '/home/amiro/.openclaw/plugin-runtime-deps/openclaw-2026.4.27-c3c756f1ad50/dist/register.migrate-u0ymn5qq.js'

I quarantined the .27 runtime-deps tree and let the gateway rebuild it. That did allow progress, but it again entered the broad bundled dependency install path.

Current reading

My current interpretation is:

• The original local-provider registration problem from #72875 may have been improved or moved in 2026.4.27.
• Enabling memory-core now changes plugin topology and triggers a gateway restart.
• That restart/rebuild walks bundled plugin/channel runtime deps much more broadly than the enabled-channel set suggests.
• During that work, the gateway can say ready while the admin WebSocket probe is still timing out.
• If the operator restarts during this install path, the runtime-deps cache can be left inconsistent.

So memory-core may be the trigger, but the failure I am seeing now is more about runtime-deps/channel discovery and readiness semantics than the embedding model itself.

Expected behavior

A few expectations from an operator point of view:

1. Enabling local memory search should not install runtime deps for unused bundled channels.
2. Disabled/unused channels should not block gateway readiness or admin WebSocket responsiveness.
3. ready should mean the gateway can answer the status/admin probe, or status should clearly say something like ready, but runtime deps still warming.
4. Runtime-deps install should be atomic/recoverable if interrupted.
5. There should be a documented/supported way to keep only the needed channel surface active, e.g. Telegram only, without broad bundled channel dependency discovery.

Why this matters

Right now the safest workaround is to keep local memory search disabled on this VPS. That is unfortunate because the local GGUF model and SQLite memory store are already present, and the canary was intentionally configured to avoid auto-indexing.

The thing blocking adoption is not the model cost or hardware. It is that touching memory-core appears to pull the gateway into a wider plugin/channel dependency repair path, and the gateway looks half-ready while that path is still blocking probes.

Happy to run a maintainer-suggested diagnostic command or test a config knob if there is an intended way to restrict bundled channel loading to Telegram only.