Environment

• OpenClaw 2026.6.1 (commit 2e08f0f)
• Node 24.14.1
• Linux 6.8.0-124-generic x86_64 (Ubuntu 24.04.4 LTS)
• Plugin: active-memory (bundled), enabled: true, sub-agent model anthropic/claude-sonnet-4-6

Symptom

The active-memory plugin's before_prompt_build hook calls a sub-agent to fetch relevant memory context. With a verbose-tendency model (Sonnet) as sub-agent, the hook fails with:

[plugins] active-memory: ... activeProvider=anthropic activeModel=claude-sonnet-4-6 done status=unavailable elapsedMs=2970 summaryChars=0
[agent/embedded] embedded run failover decision: ... stage=assistant decision=surface_error reason=none from=anthropic/claude-sonnet-4-6

reason=none makes diagnosis hard - looks like a provider/cooldown problem, but isn't.

What actually happened

Checked Anthropic Console: all sub-agent requests did complete with HTTP 200 + ~110 output tokens. The provider delivered. OC's plugin layer discarded the response.

Token-count correlation was the decisive hint:

The plugin parser appears to expect a strict/short response format. Verbose model outputs (even though valid Markdown / text) get discarded as "unavailable" instead of being used as memory summary.

Reproduction

1. Configure active-memory with a verbose-tendency model and balanced prompt style:

"plugins": {"entries": {"active-memory": {"enabled": true, "config": {"enabled": true, "agents": ["main"], "model": "anthropic/claude-sonnet-4-6", "thinking": "minimal", "timeoutMs": 5000, "promptStyle": "balanced", "queryMode": "message", "maxSummaryChars": 300, "logging": true}}}}

2. Ensure memory has indexed content (openclaw memory status --deep shows Vector store: ready).
3. Trigger via a Discord/DM channel message that semantically matches indexed memory.
4. Observe gateway logs - plugin starts, ends with status=unavailable, surface_error reason=none.
5. Cross-check the provider console - request did complete with 100+ output tokens.

Expected

Plugin should either accept verbose responses and truncate to maxSummaryChars, or log a clear parser error indicating the format constraint that failed.

Actual

• surface_error reason=none masks the real cause.
• Plugin appears broken on every reply with non-empty memory match.
• Operators waste time on provider diagnostics that are dead ends.

Mitigation tried

• promptStyle: "precision-heavy" works only as long as memory has no relevant hits (sub-agent returns 5-token no_relevant_memory). Once memory hits exist, verbose response triggers parser fail.
• Switching to openai/gpt-5.5 failed with hard 15-s timeout (too heavy for short tool-call workflow).

Workaround

Plugin enabled: false. Main agent calls memory_search/memory_get tools directly - same outcome, no plugin layer, no parser problem.

Likely cause

Parser likely expects a specific status-line format or JSON envelope. Should fall through to "accept as plaintext summary, truncate to maxSummaryChars" instead of discarding with unavailable.