openclaw - 💡(How to fix) Fix [Bug] v2026.4.25-beta.4: new runtime-context message text echoed verbatim by model into visible reply [1 comments, 2 participants]

Summary

v2026.4.25-beta.4 regression vs v2026.4.24. A new openclaw.runtime-context custom message is injected into the model's conversation history on every Telegram inbound. The injected message starts with the literal preface:

OpenClaw runtime context for the immediately preceding user message.
This context is runtime-generated, not user-authored. Keep internal details private.

Smaller / weaker open-weight models do not honor the "Keep internal details private" instruction and echo the preface verbatim into the user-visible reply. Every Charlotte response on beta.4 quoted the preface back, producing visibly broken replies.

Reverted to ghcr.io/openclaw/openclaw:latest (v2026.4.24) — leak goes away. v2026.4.24 did not have this mechanism.

Reproduction

• Image: ghcr.io/openclaw/openclaw:2026.4.25-beta.4
• Channel: Telegram (DM)
• Agent model: vllm3/Qwen3.6-35B (local vLLM, openai-completions API)
• Send any DM to the configured bot
• Reply text contains the literal "OpenClaw runtime context for the immediately preceding user message..." block

Source

/app/dist/selection-DanmaPKt.js:

function buildRuntimeContextMessageContent(params) {
  return [
    params.kind === "runtime-event"
      ? "OpenClaw runtime event."
      : "OpenClaw runtime context for the immediately preceding user message.",
    "This context is runtime-generated, not user-authored. Keep internal details private.",
    "",
    params.runtimeContext
  ].join("\n");
}

const OPENCLAW_RUNTIME_CONTEXT_CUSTOM_TYPE = "openclaw.runtime-context";

async function queueRuntimeContextForNextTurn(params) {
  // ...
  await params.session.sendCustomMessage({
    customType: OPENCLAW_RUNTIME_CONTEXT_CUSTOM_TYPE,
    content: buildRuntimeContextMessageContent({ runtimeContext, kind: "next-turn" }),
    display: false,
    details: { source: "openclaw-runtime-context" }
  }, { deliverAs: "nextTurn" });
}

display: false correctly hides the message from the UI surface, but the model still receives the full content (including the human-readable preface) in its conversation history. Any model that doesn't perfectly follow the "Keep internal details private" line will echo it.

The trigger condition is transcriptPrompt !== effectivePrompt in resolveRuntimeContextPromptParts — for Telegram that's true on every turn because the channel envelope (Conversation info / Sender JSON) is in the effective prompt but not in the transcript.

Why this is fragile

The current design mixes machine-readable runtime data with human-readable framing text inside a single custom-type message. The framing text is content the model MUST learn to ignore. That's an open-ended instruction-following ask of the model, not an architectural separation.

Suggested fixes (any one would help)

1. Separate the framing from the payload. Send the runtime context as a structured custom-message with no human-readable preface; let the harness/template wrap it for the model with provider-aware instructions.
2. Make the preface text feature-flagged. Add OPENCLAW_RUNTIME_CONTEXT_INLINE_FRAMING=0 or a config option that emits the runtime-context as a system-role hint instead of an inline message body.
3. Use a system role / non-user-visible channel for the preface so even leaky models can't echo it. Currently it goes through the same conversational message path the model is allowed to read and respond to.
4. Whitelist provider/model classes known to honor the privacy instruction; for others, fall back to the v2026.4.24 in-message-body envelope behavior.

Workaround for affected operators

Roll back to ghcr.io/openclaw/openclaw:latest (currently v2026.4.24). All other beta.4 improvements are lost in the rollback.

Adjacent context

I have separately reported beta.4 cold-path improvements (200s → 71s on the same setup) at #63357. Beta.4 is a clear net win on bootstrap latency — please don't lose those gains. The fix here is purely about the framing of the new runtime-context custom message.