Expose subagent-control waitForRun timeout as a config knob

Summary

subagent-control-Cf2vV1Sn.js calls waitForAgentRunAndReadUpdatedAssistantReply with a hardcoded timeoutMs: 3e4 (30 seconds). This hardcoded budget is the binding constraint for any subagent call against a slow local model (qwen2.5:7b on Apple Silicon takes 30-60s for narrative-shape prompts), not the configurable agents.defaults.timeoutSeconds or the per-cron payload.timeoutSeconds.

For local-LLM users this is the difference between "dreaming narratives work" and "dreaming narratives uniformly time out."

Versions affected

Tested on:

• [email protected] (a374c3a) — current; still has the hardcoded timeoutMs: 3e4 at line 460
• [email protected] (a185ca2) — reproduced
• [email protected] (50a2481) — reproduced

The hardcoded literal lives in subagent-control-lL9C38ND.js (in 5.22; was subagent-control-Cf2vV1Sn.js in 5.19). Bundle hashes rotate every release — match by symbol waitForAgentRunAndReadUpdatedAssistantReply not by filename. Full path on 5.22: /opt/homebrew/lib/node_modules/openclaw/dist/subagent-control-lL9C38ND.js:

const result = await waitForAgentRunAndReadUpdatedAssistantReply({
  runId,
  sessionKey: targetSessionKey,
  timeoutMs: 3e4,        // ← 30 seconds, hardcoded
  limit: SUBAGENT_REPLY_HISTORY_LIMIT,
  baseline: baselineReply,
  callGateway: subagentControlDeps.callGateway
});
if (result.status === "timeout") return {
  status: "timeout",
  runId
};

Empirical evidence

A local deployment (M4 Max, Ollama running qwen2.5:7b for memory-core dreaming narratives) saw:

• Ollama log: every dreaming-narrative POST /v1/chat/completions aborted at exactly 30.001-30.004s with HTTP 500
• Ollama internal log: aborting completion request due to client closing the connection
• OpenClaw structured log: [plugins] memory-core: narrative generation ended with status=timeout for {phase} phase.
• Pattern: 100% of attempts hit the 30s wall when the inner model_call takes >30s

Setting models.providers.ollama.timeoutSeconds = 180 and agents.defaults.timeoutSeconds = 240 did not help — the 30s subagent-control abort fires first, returns status: "timeout" to memory-core's narrative runner, and propagates up.

Switching the dreaming model to qwen2.5:3b (which completes the same prompts in 1-12s) sidestepped the wall — confirming the 30s is the binding constraint, not the model itself or any provider-layer timeout.

Suggested fix

One of:

1. Make the 30s budget configurable via something like plugins.entries.<plugin-id>.config.subagent.controlTimeoutMs or agents.defaults.subagentControlTimeoutMs. Default stays at 30000.
2. Make it derive from the caller's request budget (e.g., the waitForRun({timeoutMs}) call that wraps this).
3. At minimum, document the constraint in plugins/memory-core/openclaw.plugin.json so operators know the effective dreaming-narrative budget is min(NARRATIVE_TIMEOUT_MS, 30000) = 30000, not the documented NARRATIVE_TIMEOUT_MS = 60000.

Context

This is one of three related items I'm filing from a multi-day investigation of dreaming-narrative failures on a local-LLM deployment. The other two:

• "narrative-no-text" warnings firing even when sessions contain extractable text (race between waitForRun returning and JSONL flush, hypothesized)
• (Martian-Engineering/lossless-claw) [lcm] afterTurn: bootstrap checkpoint refresh failed on ephemeral isolated sessions