openclaw - 💡(How to fix) Fix before_prompt_build hook timeout hardcoded to 15s in 2026.4.27 — active-memory plugin's timeoutMs setting silently ineffective [1 comments, 2 participants]

Summary

In OpenClaw 2026.4.27, the before_prompt_build modifying-hook timeout is hardcoded to 15 seconds and not exposed through any openclaw.json field. As a result, the active-memory plugin's documented timeoutMs config (which we have set to 20000) is silently ineffective — the outer hook layer aborts the pre-compute at 15s regardless of what the plugin is configured for. This is a regression vs 2026.4.12 where the plugin-level timeout was authoritative.

Environment

• OpenClaw 2026.4.27 (cbc2ba0) — installed via pnpm add -g openclaw@latest
• Linux x64, Node v24.13.1
• Plugins enabled: memory-core, active-memory, memory-wiki (bridge mode), lossless-claw, telegram
• 4 gateway profiles, same active-memory config across all (per 2026-04-18 parity pass)

Source-level evidence

dist/hook-runner-global-BmRBtwY4.js:104:

const DEFAULT_MODIFYING_HOOK_TIMEOUT_MS_BY_HOOK = { before_prompt_build: 15e3 };

createHookRunner accepts a modifyingHookTimeoutMsByHook override option (line ~125), but initializeGlobalHookRunner (line 788) does not pass it:

state.hookRunner = createHookRunner(registry, {
    logger: { ... },
    catchErrors: true,
    failurePolicyByHook: { before_tool_call: "fail-closed" }
    // no modifyingHookTimeoutMsByHook here
});

So the override mechanism exists in the hook-runner but is unreachable from gateway config.

Symptom

Gateway log on a heavy-workspace profile (5+ agents, larger memory_search scope):

[plugins] active-memory: agent=main session=agent:main:main start timeoutMs=20000 queryChars=736
[plugins] [hooks] before_prompt_build handler from active-memory failed: timed out after 15000ms
[plugins] active-memory: agent=main done status=timeout elapsedMs=21097 summaryChars=0
[agent/embedded] embedded run failover decision: stage=assistant decision=surface_error reason=timeout from=anthropic/claude-haiku-4-5

Plugin's own timer reports elapsedMs=21097 (under its 20000ms budget plus startup overhead). But the hook layer fired at 15000ms and aborted.

Persisted-transcript inspection of the active-memory haiku sub-agent confirms: the haiku invokes memory_search once, the call is interrupted with Aborted (isError: true), the haiku then returns NONE. No actual memory summary produced.

This affects every profile whose memory_search latency exceeds 15s — particularly profiles with multiple workspaces where the haiku has more content to scan, and profiles falling back to the builtin memory backend (when optional native packages like chokidar/sqlite-vec aren't installed, which is the default state of the runtime-deps install).

Reproduction

1. Configure plugins.entries["active-memory"].config.timeoutMs = 20000 (per current docs, expecting 20s budget for the pre-compute).
2. Run on a profile with multiple agents (we have 5+ agent workspaces) and reasonable memory accumulation (~10+ daily memory files per workspace).
3. Send a content-rich question that triggers AM (queryMode: "recent").
4. Observe before_prompt_build handler from active-memory failed: timed out after 15000ms in gateway log, regardless of timeoutMs setting.

Expected behavior

The hook timeout should be configurable from openclaw.json — either via:

• A top-level gateway.hookTimeoutsMs.before_prompt_build field, or
• A plugins.hookTimeoutsMs.before_prompt_build field, or
• The plugin-level timeoutMs in plugins.entries["active-memory"].config should be authoritative (and the hook layer should respect it as the upper bound, not its own 15s).

Suggested fix

Thread the existing modifyingHookTimeoutMsByHook / voidHookTimeoutMsByHook overrides through initializeGlobalHookRunner from gateway config:

state.hookRunner = createHookRunner(registry, {
    logger: { ... },
    catchErrors: true,
    failurePolicyByHook: { before_tool_call: "fail-closed" },
    modifyingHookTimeoutMsByHook: cfg.gateway?.hookTimeoutsMs?.modifying ?? {},
    voidHookTimeoutMsByHook:      cfg.gateway?.hookTimeoutsMs?.void ?? {}
});

Or simpler: respect the active-memory plugin's timeoutMs field as the effective ceiling for before_prompt_build runs originating from that plugin.

Related

• #66925 — registerMemoryCapability overwrite bug, fixed in 2026.4.23. After upgrading past that fix, this hook-timeout constraint emerged as the next blocker.
• #72615 — open PR routing wiki bridge CLI through Gateway RPC. Same general theme: gateway-internal state not exposed/honored consistently.