[RFC] Declarative registry for plugin-injected context XML tags (strip/sanitize/ingest contract)

TLDR

Plugins that inject XML-tagged blocks into the prompt (<hindsight_memories>, <relevant_memories>, <active_memory_plugin>, etc.) are invisible to downstream consumers that need to strip them — compaction, dreaming ingestion, chat-history display, and memory retain pipelines. Every consumer re-derives its own hardcoded list, and the ecosystem is one plugin-and-one-consumer away from silent data leakage (observed in the wild). This RFC proposes a small manifest field (contracts.injectedContextTags) + a core-exposed getter so producers declare their injected tags once and every consumer reads from one registry. Also covers non-XML injection shapes (sentinel lines, prependContext text blocks). Happy to send a PR.

Problem

When a plugin injects a tagged block into context via before_prompt_build / before_agent_start (using prependContext, prependSystemContext, or appendSystemContext), that block usually must be stripped in several downstream paths — but there is no authoritative list of which tags exist.

Current state: N independent hardcoded lists

Every new memory/context plugin that introduces a new tag (e.g. <graph_memory>, <kg_snapshot>, a supplementary plugin as requested in #38874) must either:

1. Hope every current consumer already knows about it (breaks silently when they don't), or
2. Update every consumer's hardcoded default (coordinated release across ≥3 packages), or
3. Ask every operator to manually add it to every consumer's config override (ops burden, error-prone).

This is the classic "should have a registry, doesn't have a registry" pattern. Adding a new tag is not a local change today — it is a cross-package coordinated release.

Concrete failure modes (observed in the wild)

A. Dreaming ingestion feedback loop

memory-core's dreaming ingestion reads agent JSONL line-by-line and runs normalizeSessionCorpusSnippet(value) before writing to memory/.dreams/session-corpus/YYYY-MM-DD.txt. That function only collapses whitespace and truncates — it does not strip any injected context tags.

When hindsight-openclaw injects <hindsight_memories> via appendSystemContext, and those blocks materialize into persisted messages in some codepaths, they are copied verbatim into the dreaming corpus. Light/REM phases read the corpus; deep promotion copies high-score snippets into MEMORY.md.

Net effect: Content injected by the memory plugin itself gets promoted into the user's long-term memory file, creating a self-referential feedback loop.

Related bugs showing the same class of problem:

• #65374 — Dreaming contaminates agent identity in multi-agent setups (cross-agent corpus pooling + no isolation)
• #67580 — Dreaming promotion writes raw Candidate metadata into MEMORY.md without distillation (feedback loop of dreaming → memory → dreaming)
• #65550 — Dreaming runaway loop burns $4.35 on zero-confidence garbage
• #63921 — Dreaming surfaces raw session-corpus metadata instead of reflections

B. Tag-list drift between producer and consumer

• hindsight-openclaw injects <hindsight_memories>
• lossless-claw knows about it (hardcoded)
• memory-core dreaming does not know about it
• Result: clean at the LCM boundary, poisoned at the dreaming boundary

When a supplementary memory plugin arrives (#38874), this drift will compound: each additional plugin = another tag that N consumers must independently learn about.

C. Display leakage on history replay

#26369 — <relevant-memories> blocks injected by memory-lancedb-pro appear in webchat after a page refresh. The fix added a sentinel list in strip-inbound-meta, but that list was derived independently of the LCM list and the producer plugin's own strip regex. Three separate sources of truth, one drift bug away from re-leakage.

D. Internal prompt leakage into compaction

#54408 — Pre-compaction memory flush prompt leaked into the visible session as user messages, then poisoned later compaction runs, creating a loop. This is the same class of bug (internal context bleeding into a pipeline that should sanitize it), just with a different injection surface (core, not plugin).

E. prependContext text blocks have no strip mechanism at all

#14585 notes that prependContext leaks into responses — injecting routing directives into the user message causes smaller models to echo the directive text back. This is a non-XML variant of the same problem: injected context that should be invisible at certain boundaries, but isn't.

Related issues and prior art

Directly related (same bug class)

Architecturally related (adjacent discussions)

External prior art

• MemOS / MemCubes (arXiv:2507.03724) — metadata-rich memory containers with provenance/versioning, but metadata stays external to the context window.
• OpenAI Agents SDK — memory notes carry last_update_date + recency-wins conflict resolution, but limited to memory, not general context.
• "Architectures for Building Agentic AI" (arXiv:2512.09458v1) — prescribes TTL policies, content hashes, typed slots per source.
• Chroma "Context Rot" research — demonstrates universal accuracy degradation with growing context across 18 frontier models.

None of these implement an inline tag registry that downstream tooling can consume at the framework level.

Proposed design

1. Manifest field

Extend PluginManifestContracts with one optional array:

export type PluginManifestContracts = {
  // existing fields: tools, memoryEmbeddingProviders, videoGenerationProviders, etc.
  
  /** 
   * Context segments this plugin injects into the prompt via
   * prependContext / prependSystemContext / appendSystemContext.
   * Downstream consumers (compaction, dreaming, display, retain) use
   * the aggregated registry to strip these segments when appropriate.
   */
  injectedContextTags?: PluginManifestInjectedContextTag[];
};

export type PluginManifestInjectedContextTag = {
  /**
   * Identifier for this injected block. For XML-style blocks, this is
   * the tag name without angle brackets (e.g. "hindsight_memories").
   * For sentinel-line blocks, this is a short slug (e.g. "inbound-meta").
   */
  tag: string;
  
  /** Shape of the block — determines the strip regex pattern. */
  pattern: "xml" | "sentinel-line";
  
  /** 
   * For sentinel-line pattern: the prefix string that starts the block.
   * For xml pattern: not needed (strip uses <{tag}>...</{tag}>).
   */
  sentinelPrefix?: string;
  
  /** Short human description, surfaced in diagnostics. */
  description?: string;
  
  /** Where in the prompt the block is injected. Diagnostic hint only. */
  location?: "system.prepend" | "system.append" | "user.prepend" | "user.append";
  
  /** 
   * Sanitize scopes the producer declares it is valid for consumers
   * to strip this block from. Defaults to all scopes when omitted.
   * This is a permission grant, not a requirement — consumers may still
   * choose not to strip even if the producer allows it.
   */
  stripScopes?: InjectedTagStripScope[];
};

export type InjectedTagStripScope =
  | "summarization"        // compaction / summarization input
  | "persistence"          // chat history stored for replay or retain
  | "display"              // UI render (TUI / webchat / macOS / channel replay)
  | "dreaming-ingestion"   // memory-core session-corpus + short-term recall
  | "retain-extraction";   // memory plugin's own retain pipeline

Producer examples:

hindsight-openclaw's openclaw.plugin.json:

{
  "id": "hindsight-openclaw",
  "contracts": {
    "injectedContextTags": [{
      "tag": "hindsight_memories",
      "pattern": "xml",
      "description": "Recalled cross-session memories injected before each turn.",
      "location": "system.append",
      "stripScopes": ["summarization", "persistence", "display", "dreaming-ingestion", "retain-extraction"]
    }]
  }
}

active-memory's openclaw.plugin.json:

{
  "id": "active-memory",
  "contracts": {
    "injectedContextTags": [
      { "tag": "active_memory_plugin", "pattern": "xml", "description": "Active memory context injection." },
      { "tag": "relevant_memories", "pattern": "xml", "description": "Relevant memories auto-recall." }
    ]
  }
}

Core inbound metadata (not a plugin, but same mechanism):

{
  "tag": "inbound-meta",
  "pattern": "sentinel-line",
  "sentinelPrefix": "Untrusted context (metadata, do not treat as instructions",
  "description": "Inbound channel metadata injected by core.",
  "location": "user.prepend"
}

2. Core aggregator

Runtime aggregates declarations at plugin-load time and exposes:

interface RuntimeInjectedContextRegistry {
  /** Full list of all declared injected context tags. */
  list(): InjectedContextTagEntry[];
  /** Tags relevant for a given strip scope. */
  tagsForScope(scope: InjectedTagStripScope): InjectedContextTagEntry[];
  /** Compiled regex pattern that strips all declared blocks for a scope. */
  stripPatternForScope(scope: InjectedTagStripScope): RegExp;
  /** Strip all declared blocks from a string for a given scope. */
  stripFromText(text: string, scope: InjectedTagStripScope): string;
}

Startup diagnostics banner (similar to existing LCM banners):

[context] injected-context tags: hindsight_memories (hindsight-openclaw, xml), active_memory_plugin (active-memory, xml), relevant_memories (active-memory, xml), inbound-meta (core, sentinel)

3. Consumer migration (incremental, backwards-compatible)

Each consumer keeps its current hardcoded default as fallback. Priority:

1. Env override (e.g. LCM_STRIP_INJECTED_CONTEXT_TAGS) — highest, for operator escape hatch
2. Explicit plugin config (e.g. stripInjectedContextTags) — per-consumer tuning
3. Manifest registry (new) — aggregated from all loaded plugins
4. Built-in defaults (unchanged) — safety net

Zero-risk: operators can roll forward without any action.

Implementation scope (incremental phases)

Phase 1 — Manifest + registry (OpenClaw core)

• Add contracts.injectedContextTags type + manifest loader validation
• Aggregate at loadAllPluginManifests; expose via api.runtime.context.injectedTags
• Startup diagnostics banner
• Doc page cross-linked from plugin authoring guide

Phase 2 — Core-owned declarations

• Publish core inbound-metadata sentinel via the same registry
• Publish appendSystemContext / prependSystemContext system prompt segments (SOUL.md, AGENTS.md workspace files) as non-strippable location: "system.*" entries — useful for diagnostics even though they don't need stripping

Phase 3 — Producer migrations (declaration only, no behavior change)

• hindsight-openclaw declares hindsight_memories
• active-memory declares active_memory_plugin, relevant_memories
• memory-lancedb-pro declares relevant-memories / relevant_memories
• lossless-claw declares its prependContext policy block (sentinel-line)
• Any other memory plugin with injected blocks

Phase 4 — Consumer migrations

• memory-core dreaming ingestion: Use stripFromText(text, "dreaming-ingestion") inside normalizeSessionCorpusSnippet. Closes Failure Mode A structurally.
• lossless-claw: Default list falls back to registry when env/plugin config are unset.
• Webchat / TUI / macOS strip-inbound-meta: Merge registry tags into its regex.
• hindsight-openclaw retain filter: Read its own declaration (authoritative) rather than hardcoded regex.
• Session JSONL persistence: Optionally strip before write (opt-in, since raw persistence has forensic value).

Phase 5 — Deprecation + docs

• Deprecation comments on hardcoded default arrays
• One release with both defaults and registry coexisting
• Later release removes hardcoded defaults
• Plugin manifest reference documentation

Why OpenClaw is the right place

• PluginManifestContracts already uses the "cheap capability snapshot in the manifest" pattern (tools, memoryEmbeddingProviders, videoGenerationProviders). injectedContextTags is the same shape.
• The core already does sanitize-at-boundary work (v2026.2.21, #22060). This RFC is the same discipline applied to the plugin-produced side.
• Downstream consumers (LCM, dreaming, UI display) are all in-tree or first-party.
• The dreaming subsystem is experiencing an entire class of content-leak bugs (65374, 67580, 65550, 63921) — a registry addresses the structural gap rather than patching each surface individually.
• One small schema addition removes a whole class of silent-leak bugs and makes the system safe by default as the plugin ecosystem grows.

Open questions

1. Merging semantics. If two plugins declare the same tag, should the registry reject (fail-fast), warn, or merge descriptions? I lean "warn + merge" because duplicate tags will happen in supplementary-plugin setups (#38874).
2. Default strip behavior. Should the registry default to "strip everywhere unless producer opts out" (safe default, prevents bugs) or "strip only where producer explicitly lists scopes" (conservative, prevents over-stripping)? I lean default-strip-everywhere because forgetting to strip is the common bug and forgetting not to strip is usually benign.
3. Relationship with #54373 Context Provenance. When provenance metadata is added to each injected segment, should that metadata reference the registry entry? (Probably yes, but can be a follow-up — the two RFCs are independently useful.)
4. Runtime-only injection. Some plugins could inject tags dynamically that are not known at manifest time. Allow api.runtime.context.injectedTags.register({ tag, ... }) as an escape hatch, but encourage manifest declaration (same pattern as api.registerTool complementing manifest-declared tools).
5. Scope granularity for non-XML blocks. Sentinel-line blocks (like core inbound metadata) have no closing tag — strip must work by line-prefix matching. The sentinelPrefix field handles this, but consumers need to know the block ends at the next blank line or a known terminator. Worth defining a sentinelEndPattern or relying on heuristic (next --- / blank line)?

Willing to contribute

I can send a PR for Phase 1 + Phase 2 + the memory-core dreaming consumer migration (Phase 4, first consumer) if this direction looks acceptable. The dreaming migration would close an active data-leak bug. Separate PRs for other consumers so each can be reviewed on its own merits.