openclaw - 💡(How to fix) Fix [Enhancement]: Increase or make configurable the Active Memory timeoutMs hard cap (currently 120000ms ceiling)

Problem

The active-memory plugin normalizes config.timeoutMs with a hard-coded upper ceiling of 120 000 ms (see normalizePluginConfig() in extensions/active-memory/index.ts). Even though the outer hook-runner timeout was made configurable (via #74908), the plugin-internal cap remains fixed at 120 seconds.

For local vLLM setups serving larger models (27B+ parameters, FP8 quantized), 120 seconds is not always sufficient for the Active Memory embedded sub-agent to complete its recall cycle. This affects the recall model latency itself — the embedded sub-agent typically performs semantic search + one or two recall LLM calls, each of which can take 15–40+ seconds on local ARM64 hardware depending on model size and current load.

Setting timeoutMs above 120000 in config is rejected at gateway startup, so operators have no way to tune this budget to match their hardware.

Current situation

• timeoutMs: 120000 is the maximum accepted value
• normalizePluginConfig() clamps values to this ceiling
• #68410 raised the cap from 60 000 to 120 000 (closed, implemented)
• #74908 made the outer hook-runner configurable (closed, implemented)
• But the plugin-internal 120s cap remains hard-coded

Proposed solution

Either:

1. Raise the hard cap to a more reasonable value (e.g. 300 000 ms / 5 minutes)
2. Or expose the cap as a config field (similar to how the outer hook-runner was addressed)

Local operators should be able to match their timeout to their hardware's actual performance characteristics.

Environment

• Host: ARM64 (DGX Spark, NVIDIA GB10)
• Model: vLLM serving Qwen3.6-27B-FP8
• Active Memory model: qwen3.6-fp8-fast
• OpenClaw: 2026.5.22-beta.1

Related issues

• #68410 — timeoutMs normalization bug (closed)
• #74908 — outer hook-runner timeout made configurable (closed)
• #85826 — agent stall detector hard-coded 120s threshold (open)