Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix Runtime injection tags (`<system-reminder>`, `<previous_response>`) leak verbatim to delivery channels when model is in degraded state [3 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#73595•Fetched 2026-04-29 06:17:45
View on GitHub
Comments
3
Participants
3
Timeline
4
Reactions
0
Author
gabrielexito-stackgabrielexito-stack
Participants
clawsweeper[bot]clawsweeper[bot]gabrielexito-stackgabrielexito-stackmartingarramonmartingarramon
Timeline (top)
commented ×3closed ×1

When an agent session is in a degraded state (after a model timeout, broken parentId chain, or stuck-in-processing recovery), the model's reply may include the runtime injection tags it received in its prompt — <system-reminder>...</system-reminder>, <previous_response>...</previous_response> — verbatim in the output text. These then flow through the delivery layer to user-facing channels (Discord, etc.) without sanitization. Users see raw XML tags posted as if they were intended content.

Root Cause

Hard to repro deterministically because it requires a degraded session state, but the trigger condition is observable:

RAW_BUFFERClick to expand / collapse

Summary

When an agent session is in a degraded state (after a model timeout, broken parentId chain, or stuck-in-processing recovery), the model's reply may include the runtime injection tags it received in its prompt — <system-reminder>...</system-reminder>, <previous_response>...</previous_response> — verbatim in the output text. These then flow through the delivery layer to user-facing channels (Discord, etc.) without sanitization. Users see raw XML tags posted as if they were intended content.

Reproduction

Hard to repro deterministically because it requires a degraded session state, but the trigger condition is observable:

  1. Long-running model call hits an idle/timeout cutoff (e.g. 300s).
  2. Same session is reused for a follow-up turn before transcript repair runs.
  3. Next reply often contains literal <system-reminder>...</system-reminder> and/or <previous_response>null</previous_response> text inside the assistant message body.
  4. OpenClaw's outbound delivery (Discord channel in our case) sends the message body unmodified.

Observed today on 2026.4.24 (pre-update) and confirmed multi-time across at least Sonnet 4.6 and Opus 4.x. The model is leaking its own context-injection scaffolding because it can't distinguish runtime-system tags from user-visible content when its transcript is broken.

Why this is a delivery-layer issue, not (only) a model issue

The model echoing its scaffolding is a known LLM failure mode under degraded context. The bug is that OpenClaw's outbound pipeline has no sanitizer to strip these tags before they hit user channels. They are internal runtime constructs (added by before_prompt_build hooks, sticky-context, conversation reconstruction) — there is no scenario where a user channel benefits from seeing them.

Suggested fix

Add a final-stage sanitizer in the delivery pipeline (between agent reply assembly and channel send) that strips a known allow-list of internal-only tags from the outgoing text. Minimum coverage:

  • <system-reminder>...</system-reminder> (incl. self-closing/empty variants)
  • <previous_response>...</previous_response>
  • Any other tags the runtime injects via hooks (worth enumerating from the hook layer rather than hard-coding).

Suggested implementation point: a hook on the outbound channel-send path, parallel to existing redaction (redactSensitiveText), specifically for runtime-tag stripping. Should run unconditionally — no need to detect "degraded state" since these tags should never reach a channel under any circumstance.

Severity

Medium-high. Cosmetic damage on every leak; user trust hit when scaffolding text is exposed (looks like the agent is broken or the operator is incompetent). Compounding factor: the leak is most likely to occur during recovery from already-degraded sessions, so it tends to appear right when a user is most likely to be already frustrated.

Related

  • Filed alongside #73587 (separate gateway crash on tilde-expansion regression in 2026.4.26).

extent analysis

TL;DR

Add a sanitizer to the delivery pipeline to strip internal runtime tags from outgoing text before it reaches user channels.

Guidance

  • Identify the specific internal tags that need to be stripped, including <system-reminder>, <previous_response>, and any other tags injected via hooks.
  • Implement a hook on the outbound channel-send path to run a sanitizer that removes these tags unconditionally.
  • Ensure the sanitizer covers self-closing and empty variants of the tags.
  • Consider enumerating the tags to be stripped from the hook layer rather than hard-coding them.

Example

def strip_runtime_tags(text):
    # Define the list of tags to be stripped
    tags_to_strip = ['<system-reminder>', '</system-reminder>', '<previous_response>', '</previous_response>']
    
    # Remove the tags from the text
    for tag in tags_to_strip:
        text = text.replace(tag, '')
    
    return text

# Example usage:
outgoing_text = "<system-reminder>Reminder text</system-reminder> Hello, world!"
sanitized_text = strip_runtime_tags(outgoing_text)
print(sanitized_text)  # Output: " Hello, world!"

Notes

The implementation should be careful not to interfere with existing redaction mechanisms, such as redactSensitiveText.

Recommendation

Apply a workaround by adding a sanitizer to the delivery pipeline, as this will prevent internal runtime tags from being exposed to users and mitigate the cosmetic damage and user trust issues associated with this bug.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#agent execution#callback error#memory management#API rate limit#retriever error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING