Hi OpenViking team,

We are seeing an intermittent auto-capture issue with the OpenClaw plugin, where injected recall context appears to be treated as capturable turn text.

Environment

• OpenClaw version: 2026.3.13
• OpenViking core version: 0.2.9
• OpenClaw OpenViking plugin version: @openclaw/openviking 2026.2.6-3
• Plugin mode: local OpenViking server
• OpenViking is currently registered as context-engine
• Slot config in our environment:
  • memory = memory-core
  • contextEngine = openviking

Symptom

During afterTurn auto-capture, the plugin repeatedly logs capture candidates that begin with injected recall wrapper content such as:

• <relevant-memories> ... </relevant-memories>

In many cases, this is followed by:

• auto-capture failed: AbortError: This operation was aborted

In some other cases, capture does not abort, but the captured text still appears to contain injected memory wrapper content, which suggests system-injected context may be entering the capture/extract path.

Expected behavior

Auto-capture should only capture real user/assistant conversational content.

Injected system/context blocks such as:

• <relevant-memories> ... </relevant-memories>

should be fully excluded from capture input and should never be treated as candidate memory text.

Observed behavior

The plugin logs repeatedly show:

1. capture-check preview begins with injected wrapper content
2. capture decision is still shouldCapture=true
3. then either:
   • request aborts with AbortError
   • or capture succeeds but extracts memories from polluted input

Sanitized logs

2026-03-23T17:58:48.319+08:00 [gateway] openviking: local server started (http://127.0.0.1:1933, config: /home/.../.openviking/ov.conf)

2026-03-23T18:04:38.457+08:00 [plugins] openviking: capture-check shouldCapture=true reason=semantic_candidate_after_sanitize newMsgCount=3 text="[user]: <relevant-memories>
The following OpenViking memories may be relevant:
-..."

2026-03-23T18:04:53.951+08:00 [plugins] openviking: auto-capture failed: AbortError: This operation was aborted

Another repeated occurrence:

2026-03-23T18:09:29.571+08:00 [plugins] openviking: capture-check shouldCapture=true reason=semantic_candidate_after_sanitize newMsgCount=2 text="[user]: <relevant-memories>
The following OpenViking memories may be relevant:
-..."

2026-03-23T18:09:44.617+08:00 [plugins] openviking: auto-capture failed: AbortError: This operation was aborted

We also observed cases where capture does not abort, but polluted input still seems to be captured:

2026-03-23T18:08:13.879+08:00 [plugins] openviking: capture-check shouldCapture=true reason=semantic_candidate_after_sanitize newMsgCount=2 text="[user]: <relevant-memories>
The following OpenViking memories may be relevant:
-..."

2026-03-23T18:08:21.254+08:00 [plugins] openviking: auto-captured 2 new messages, extracted 2 memories
2026-03-23T18:08:21.271+08:00 [plugins] openviking: capture-detail {"capturedCount":2,"captured":["[user]: <relevant-memories>\nThe following OpenViking memories may be relevant:\n- ..."],"extractedCount":2}

What we checked

We compared our local plugin logic with the current main branch plugin files and did not find an obvious local divergence in the relevant capture/sanitize path.

In particular, the current flow appears to be roughly:

• extractNewTurnTexts() wraps turn text as [user]: ... / [assistant]: ...
• getCaptureDecision() calls sanitizeUserTextForCapture()
• but capture may still proceed with semantic_candidate_after_sanitize

This makes us suspect either:

1. current sanitize coverage is incomplete for injected/system wrapper content in this path, or
2. sanitized residual text is still incorrectly considered valid semantic capture input

Question

Is this a known issue in the OpenClaw plugin capture boundary?

If not, would you like a more targeted follow-up with:

• sanitized normalizedText samples after sanitizeUserTextForCapture()
• exact config fragment for capture-related options
• a minimal reproduction pattern

Thanks.