Summary

The active-memory plugin registers before_prompt_build with { timeoutMs: config.timeoutMs + setupGraceTimeoutMs }, where setupGraceTimeoutMs defaults to 30000. With the typical config.timeoutMs: 15000, this caps the hook at 45s instead of the gateway default 15s — so when the embedded recall sub-agent's prep stages exceed the 15s budget, the hook blocks the main command lane for a full 45s.

Reproduction

• extensions.active-memory.config.timeoutMs: 15000 (default)
• Any prompt where the recall sub-agent's prep stages (model-resolution, auth, bootstrap-context, system-prompt, session-resource-loader, stream-setup) exceed 15s — observed ~24–25s in our gateway.

Symptoms

• [plugins] [hooks] before_prompt_build handler from active-memory failed: timed out after 45000ms
• [diagnostic] lane task error: lane=main durationMs=45xxx error="CommandLaneTaskTimeoutError: Command lane \"main\" task timed out after 45000ms"
• eventLoopUtilization=1, p99 7s–42s
• New WS handshakes drop as closed before connect while the lane is wedged.

Root cause

• dist/extensions/active-memory/index.js line 31: const DEFAULT_SETUP_GRACE_TIMEOUT_MS = 3e4
• Used at line 1463: const beforePromptBuildTimeoutMs = config.timeoutMs + setupGraceTimeoutMs (passed as the hook registration's timeoutMs)
• And at line 1262 inside maybeResolveActiveRecall: watchdogTimeoutMs = config.timeoutMs + setupGraceTimeoutMs

The plugin's hook returns undefined cleanly on timeout (catch at line 1545), so the only thing keeping the lane held is the inflated cap.

Proposed fix

Change DEFAULT_SETUP_GRACE_TIMEOUT_MS to 0 (or document/expose it as config). The 30s grace defeats the configured timeoutMs budget without operator visibility.

Workaround applied locally

One-line patch on the installed dist/extensions/active-memory/index.js:

-const DEFAULT_SETUP_GRACE_TIMEOUT_MS = 3e4;
+const DEFAULT_SETUP_GRACE_TIMEOUT_MS = 0;

Wiped on next package upgrade — hence this issue.

Environment

• openclaw 2026.4.29
• macOS 26.4.1 arm64, node 25.9.0