active memory

[quiet roost]

@tribal citrus Active memory has been timing out more often than not since the update to v2026.4.25. Updating to v2026.4.26 didn't fix it. Here's what my agent has to say:

After the restart:

• Some turns returned empty in ~17–19s.
• This latest turn timed out again:
• status=timeout
• elapsed ~37s
• summaryChars=0

Current diagnosis: Active Memory’s embedded recall run is still intermittently hanging/timing out at the embedded-agent/provider layer.

[sly holly]

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

[quiet roost]

More from my agent:

• Active Memory started at 18:23:39.
• It declared timeout at 18:24:17 after ~37.5s.
• The persisted transcript then shows the embedded memory agent starting after the outer Active Memory timeout had already fired.
• Inside that transcript, both memory_search calls immediately returned:
• Aborted
• Then the sub-agent returned NONE.
• The embedded runtime logged failover because the run had already been aborted/timed out.

So the actual bug looks like:

Active Memory launches an embedded sub-agent, but the embedded run is not reliably getting productive execution time before the plugin timeout expires. By the time the memory agent actually calls tools, its abort signal is already poisoned, so the tools abort instantly.

[tribal citrus]

Wooster, yeah — this looks like a known Active Memory regression, not your config.

The 17–19s empty / ~37s timeout pattern matches #72606 pretty closely: Active Memory’s timeoutMs was getting eaten by embedded-run setup before the recall model even got a fair shot. There’s already a post-2026.4.26 fix on main: “keep recall setup time from consuming the configured model timeout”. 2026.4.26 is still the latest release right now, so you won’t have that fix from normal latest yet. (github.com)

Short-term workaround: in your existing plugins.entries.active-memory.config, try:

{
  queryMode: "message",
  timeoutMs: 45000,
  logging: true
}

Then:

openclaw gateway restart

If you’re using memory-lancedb, there’s a second post-release fix too: Active Memory now allows memory_recall as well as memory_search/memory_get; that also shipped on main after 2026.4.26. (github.com)

Useful checks if it still happens:

openclaw memory status --deep

and grab gateway log lines containing:

active-memory:

embedded run failover decision
memory sync failed

Docs for the relevant knobs: Active Memory uses plugins.entries.active-memory, has config.timeoutMs, /verbose on, /trace on, and openclaw memory status --deep for debugging. (github.com)

Yep — that’s the smoking gun. Your agent’s diagnosis matches the post-2026.4.26 fix on main almost exactly: the Active Memory timeout is being spent before the embedded recall agent gets real execution time, so once it finally reaches memory_search, the abort signal is already tripped.

I checked npm: 2026.4.26 is still latest, so updating again won’t pick this up yet.

There are two relevant fixes already on main after 2026.4.26:

• 891c7d9f1c — fix(active-memory): align recall timeout with hook runner / fixes #72606
• f256eeba43 — lets Active Memory use the bundled memory_recall tool too, not just memory_search/memory_get

For now, I’d use this as mitigation rather than deeper local debugging:

plugins: {
  entries: {
    "active-memory": {
      enabled: true,

      config: {
        // keep your existing fields too
        queryMode: "message",
        timeoutMs: 60000,
        logging: true,
      },
    },
  },
}

Then restart the gateway.

If you can, please add that exact transcript/timeline to the GitHub issue — especially “sub-agent starts after outer timeout; memory_search returns Aborted immediately.” That’s very useful evidence and confirms this isn’t just a slow provider.
https://github.com/openclaw/openclaw/issues/72606