OpenClaw 4.15 Active Memory Timeout: What's Happening and How to Fix It

April 21, 2026 · ClawReady Team

If you upgraded to OpenClaw 2026.4.15 and your agent suddenly hangs on every reply, you're not alone. GitHub issue #68825 (filed 2 days ago) documents a confirmed regression: enabling the Active Memory plugin on 4.15 causes every blocking sub-agent call to time out at 120 seconds, flooding your gateway log with:

[memory] qmd update failed (Error: qmd update timed out after 120000ms)

The kicker — the qmd CLI itself is perfectly healthy. Running qmd status or qmd collection add directly works instantly. The timeout is specific to the runtime path Active Memory uses to invoke qmd inside the 4.15 gateway process.

Who's affected

• Anyone on 2026.4.15 (npm or Docker) with Active Memory enabled
• Affects Signal, Telegram, Discord — any direct-chat session type
• Tested with Anthropic Claude Haiku 4.5 and Google Gemini 2.5 Flash Lite — identical behavior, so it's not your model provider
• Upgrading from 3.24 or 4.14 both trigger this — it's the 4.15 gateway, not a partial-upgrade artifact

What you'll see

• Every agent reply takes 8–12 seconds regardless of task
• Active Memory queries return summaryChars=0 (no context injected)
• User-facing chat shows: ⚠️ Gateway: exec failed
• Gateway log fills with repeated qmd update failed errors — 12+ per minute under normal load
• qmd invoked directly from terminal: instant

Current workarounds

Option 1: Roll back to 4.14 (cleanest fix)

npm install -g --prefix /data/.npm-global openclaw@2026.4.14

Restart your gateway after install. Active Memory works correctly on 4.14.

Option 2: Disable Active Memory on 4.15

If you need to stay on 4.15 for another fix it brought, turn off Active Memory in openclaw.json:

"plugins": {
  "active-memory": {
    "enabled": false
  }
}

You lose context injection but the agent stays responsive.

Option 3: Bump the timeout (partial mitigation only)

Setting timeoutMs: 120000 in your active-memory config doesn't solve the root hang — it just extends how long each turn waits before surfacing an error. Not recommended unless you're debugging.

Is this fixed?

As of April 21, 2026: no official fix yet. The issue is open (no "fixed" label, no linked PR). Petronella's OpenClaw 2026 guide notes that 4.15 "was still resolving plugin runtime and CLI hash race conditions as of mid-April 2026" — this is consistent with a runtime subprocess spawning regression.

Watch #68825 on GitHub for updates. A 4.15.1 patch or 4.16 is likely the fix path.

Why this matters for ClawReady setups

Active Memory is one of the highest-value features in OpenClaw — it's what lets your agent remember context across sessions without manual memory files. A silent timeout that produces summaryChars=0 is particularly dangerous because your agent silently loses all context injection while still appearing to work.

If you're running a production OpenClaw setup (customer-facing, business workflows, 24/7 operations), stay on 4.14 until a fix lands. The new 4.15 features (Gemini TTS, cloud LanceDB, Copilot embeddings) are compelling — but not worth a broken memory layer.

Need help rolling back or diagnosing your setup?

ClawReady can audit your configuration, confirm whether you're hitting this bug, and roll you back cleanly — including verifying Active Memory is functional post-rollback. See our audit and setup options.