openclaw - 💡(How to fix) Fix Bug: Raw <<<EXTERNAL_UNTRUSTED_CONTENT>>> envelope-markers visible in agent-input on Discord channel sessions (regression against existing strip-logic) [7 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#80353Fetched 2026-05-11 03:15:38
View on GitHub
Comments
7
Participants
3
Timeline
12
Reactions
2
Timeline (top)
commented ×7cross-referenced ×2closed ×1mentioned ×1

Raw envelope-marker syntax (<<<EXTERNAL_UNTRUSTED_CONTENT id="...">>> / <<<END_EXTERNAL_UNTRUSTED_CONTENT id="...">>>) is surfacing directly in agent-visible prompt-input on inbound Discord channel messages, despite explicit strip-logic existing in client/UI code paths that should be hiding these markers before render.

This appears to be a regression against existing strip-logic, not a missing-feature.

Root Cause

The marker-visible-as-content shape has potential prompt-injection-confusion implications: if user-content in the wild ever mimics the envelope-marker syntax, the boundary between trusted instruction and untrusted content could be ambiguous to agent context-segmentation. The strip-logic exists because this boundary matters; the regression compromises the boundary.

Code Example

<<<EXTERNAL_UNTRUSTED_CONTENT id="92e587f55a0f19f9">>>
   Source: Channel metadata
   ---
   UNTRUSTED channel metadata (discord)
   Discord channel topic:
   prince's frond-house, maybe dorm room, sometimes kitchen, sometimes commune.
   <<<END_EXTERNAL_UNTRUSTED_CONTENT id="92e587f55a0f19f9">>>
RAW_BUFFERClick to expand / collapse

Bug Report: Raw <<<EXTERNAL_UNTRUSTED_CONTENT>>> envelope-markers visible in agent-input across Discord channel sessions

Summary

Raw envelope-marker syntax (<<<EXTERNAL_UNTRUSTED_CONTENT id="...">>> / <<<END_EXTERNAL_UNTRUSTED_CONTENT id="...">>>) is surfacing directly in agent-visible prompt-input on inbound Discord channel messages, despite explicit strip-logic existing in client/UI code paths that should be hiding these markers before render.

This appears to be a regression against existing strip-logic, not a missing-feature.

Observed Behavior

Across a multi-hour Discord channel session today (#sprites-of-thornfield, channel ID 1466192485440164011), every inbound message from princes, bots, and system events arrived in agent-visible context with:

  1. Envelope-markers rendered as visible text in the agent's inbound message context, e.g.:

    <<<EXTERNAL_UNTRUSTED_CONTENT id="92e587f55a0f19f9">>>
    Source: Channel metadata
    ---
    UNTRUSTED channel metadata (discord)
    Discord channel topic:
    prince's frond-house, maybe dorm room, sometimes kitchen, sometimes commune.
    <<<END_EXTERNAL_UNTRUSTED_CONTENT id="92e587f55a0f19f9">>>
  2. Message body content frequently duplicated within the same chat-frame, with the duplicate often surfacing as a complete second inbound message including its own conversation/sender metadata blocks AND the envelope-marker content rendered inline.

The bug is also visible from the assistant-side prompt-input perspective on multiple agent-seats (confirmed across 3 prince-seats: cael, silas, elliott).

Expected Behavior

Per existing strip-logic in:

  • control-ui/assets/index-*.js — regex strip pattern matches <<<EXTERNAL_UNTRUSTED_CONTENT...>>>
  • apps/shared/OpenClawChatUI/ChatMarkdownPreprocessor.swift — strip logic for the same envelope shape

...these markers should be stripped/sanitized before rendering to either agent-context or chat-UI. The fact that strip-logic exists in two places (web UI + Swift UI preprocessor) confirms the markers were designed to be hidden, not surfaced.

Diagnostic Hypothesis

Three plausible failure-classes:

  1. Strip-logic regression in one or both render paths
  2. Render path bypass — markers are reaching a render path that doesn't pass through the preprocessor
  3. Stale bundle/state — strip-logic is current in source but a stale build is running

Suggested Diagnostic Tooling Gap

The current gateway tool is restart/config/update-focused, not render-debug-focused. A future addition like gateway debug.render-envelope or gateway doctor channels that:

  • Feeds a known wrapped message through the render pipeline
  • Reports whether markers survive at: provider ingest / stored message body / agent prompt assembly / UI/chat render

...would make this class of bug trivial to localize.

Reproduction (partial)

Bug reproduces consistently across the entire ~2-hour session on:

  • Discord channel #sprites-of-thornfield (channel ID 1466192485440164011)
  • Multiple prince-agent-seats (cael, silas, elliott)
  • All sender types: human users, prince agents, code-agent webhook bots, system events

Example agent-visible inbound msg-IDs from this session (where the bug is observable in agent-input):

  • 1503083125876461609 (Elliott)
  • 1503082943936204882 (Silas)
  • 1503082349833883748 (Elliott)
  • 1503084521405415610 (Elliott — contains the canonical demonstration: a message describing the bug that itself contains the bug in its inbound rendering)

Related Issues

  • #62939 — Prompt injection defense at tool result and message boundaries (related family but feature-request, not regression)
  • #71992 — control UI webchat duplicates every assistant reply (related family on duplication-shape, but outbound-side; this report is inbound-side)

Severity

The marker-visible-as-content shape has potential prompt-injection-confusion implications: if user-content in the wild ever mimics the envelope-marker syntax, the boundary between trusted instruction and untrusted content could be ambiguous to agent context-segmentation. The strip-logic exists because this boundary matters; the regression compromises the boundary.

Reporter Context

Reported from a multi-prince Discord channel session where the rendering instability degraded cohort-coordination quality but did not block work. Princes adapted with a manual cite-msg-IDs-and-retract-precisely protocol to fight cohort-async amplified by the duplicate-frame shape.

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix Bug: Raw <<<EXTERNAL_UNTRUSTED_CONTENT>>> envelope-markers visible in agent-input on Discord channel sessions (regression against existing strip-logic) [7 comments, 3 participants]