Summary
Expose the outer plugin hook-runner timeout for modifying hooks (especially before_prompt_build) as configuration instead of keeping it hardcoded at 15s.
Problem
active-memory has its own timeoutMs config, but in current installed builds there is also an outer hook-runner deadline for modifying hooks. For before_prompt_build, that deadline is hardcoded to ~15s. In practice this means a plugin can configure a longer model/recall timeout, but the hook still gets aborted by the outer hook cap first.
This is especially visible with Active Memory recall models that sometimes complete in ~10-12s but occasionally need slightly longer. The plugin-level config gives the impression that the budget is tunable, but the actual foreground hook budget is capped elsewhere.
Example local behavior:
active-memory ... activeModel=qwen3.6-active-memory:latest done status=ok elapsedMs=9967 summaryChars=114
active-memory ... activeModel=qwen3.6-active-memory:latest done status=ok elapsedMs=10449 summaryChars=115
active-memory ... activeModel=qwen3.6-active-memory:latest done status=timeout elapsedMs=15189 summaryChars=0
active-memory ... activeModel=qwen3.6-active-memory:latest done status=timeout elapsedMs=15492 summaryChars=0
The plugin config was set to timeoutMs: 15000; raising it would not solve the real limit if the hook runner still enforces a hard 15s before_prompt_build modifying-hook deadline.
Proposed solution
Add a documented config path for the modifying-hook runner timeout, ideally with per-hook and/or per-plugin override support.
Possible shape:
{
"plugins": {
"hookTimeouts": {
"before_prompt_build": 30000
},
"entries": {
"active-memory": {
"hooks": {
"before_prompt_build": {
"timeoutMs": 30000,
"onTimeout": "skip" // fail open for recall/context plugins
}
}
}
}
}
}Exact schema is not important; the important part is that operators can tune the outer hook cap without patching OpenClaw's bundled JS.
Desired behavior
before_prompt_build modifying-hook timeout is configurable.- Defaults remain safe and responsive for normal users.
- Context/recall plugins such as Active Memory should fail open on timeout unless explicitly configured otherwise.
- Logs should identify whether timeout came from plugin-level
timeoutMs or the outer hook-runner cap.
- Documentation should clarify the relationship between Active Memory
timeoutMs and hook-runner timeout.
Why this matters
Active Memory is useful in direct chat, but model latency varies. A hardcoded outer 15s cap forces users to choose only models that reliably finish under 15s, even if they are willing to trade a slightly longer foreground budget for better recall quality. Making the cap configurable avoids local code patches and makes the behavior explicit.
Related issues
Summary
Expose the outer plugin hook-runner timeout for modifying hooks (especially
before_prompt_build) as configuration instead of keeping it hardcoded at 15s.Problem
active-memoryhas its owntimeoutMsconfig, but in current installed builds there is also an outer hook-runner deadline for modifying hooks. Forbefore_prompt_build, that deadline is hardcoded to ~15s. In practice this means a plugin can configure a longer model/recall timeout, but the hook still gets aborted by the outer hook cap first.This is especially visible with Active Memory recall models that sometimes complete in ~10-12s but occasionally need slightly longer. The plugin-level config gives the impression that the budget is tunable, but the actual foreground hook budget is capped elsewhere.
Example local behavior:
The plugin config was set to
timeoutMs: 15000; raising it would not solve the real limit if the hook runner still enforces a hard 15sbefore_prompt_buildmodifying-hook deadline.Proposed solution
Add a documented config path for the modifying-hook runner timeout, ideally with per-hook and/or per-plugin override support.
Possible shape:
Exact schema is not important; the important part is that operators can tune the outer hook cap without patching OpenClaw's bundled JS.
Desired behavior
before_prompt_buildmodifying-hook timeout is configurable.timeoutMsor the outer hook-runner cap.timeoutMsand hook-runner timeout.Why this matters
Active Memory is useful in direct chat, but model latency varies. A hardcoded outer 15s cap forces users to choose only models that reliably finish under 15s, even if they are willing to trade a slightly longer foreground budget for better recall quality. Making the cap configurable avoids local code patches and makes the behavior explicit.
Related issues