openclaw - 💡(How to fix) Fix [Bug]:Observation: bootstrap-context content can appear verbatim in streamed responses when SIGTERM hits an in-flight generation

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Two consecutive assistant responses contained verbatim blocks of recent bootstrap context (MEMORY.md content) at unrelated semantic positions, following a SIGTERM received by the gateway during an active in-flight generation.

Steps to reproduce

NOT_ENOUGH_INFO

Expected behavior

The assistant response should contain only freshly generated content relevant to the in-progress conversational thread. In all prior sessions and in normal operation, assistant responses have never contained verbatim bootstrap context content. The expected behavior is that SIGTERM during an active generation either completes the generation cleanly or produces no assistant message — not a response containing verbatim system-prompt material.

Actual behavior

Two consecutive assistant responses contained verbatim blocks of the same MEMORY.md entry (a closure SITREP from two days prior) embedded inline as if freshly authored content. No error wrapper, no transcript-repair placeholder, no structural marker of any kind distinguished the verbatim blocks from the rest of the response. The same block appeared in both responses — consistent-target pattern, not random content. The incident occurred immediately following a SIGTERM received by the gateway during an active in-flight generation. Gateway logs confirmed SIGTERM at 13:38:44 EDT, drain window of approximately 6 seconds, clean restart at 13:38:53 EDT. Source reading of dist/session-transcript-repair-D9T_omS-.js confirmed the transcript-repair layer was not the source — it produces only structured makeMissingToolResult placeholders with a fixed string, never assistant-text content.

OpenClaw version

2026.4.26 (be8c246)

Operating system

macOS 25.5.0 arm64 (Apple Silicon)

Install method

Homebrew (brew install openclaw)

Model

anthropic/claude-opus-4-7

Provider / routing chain

Anthropic API → OpenClaw embedded run path (agent-runner.runtime) → block-streaming chunker (block-streaming-R2sIrq3b.js) → Telegram channel delivery

Additional provider/model setup details

Single-agent setup. One persistent agent (Hope) running on a Mac mini (Sovereign-Alpha) as a long-running launchd-managed gateway service. The agent's system prompt includes a substantial MEMORY.md bootstrap file (~83K characters at incident time, recently trimmed approximately 2.5 hours before the incident). The trim cycle rebuilt the bootstrap from a trimmed file — if OpenClaw caches the system prompt, the cache would have been invalidated earlier in the same session. No proxy, no model router, no per-agent model override. Direct Anthropic API via OpenClaw's standard provider integration.

Logs, screenshots, and evidence

Gateway log entries around the incident window (13:38 EDT, 2026-05-30):

signal SIGTERM received
draining 2 active task(s), 1 active embedded run(s)
[~6 second drain window]
gateway restarted clean at 13:38:53 EDT

Source reading findings:

dist/session-transcript-repair-D9T_omS-.js — confirmed the transcript-repair layer produces only structured makeMissingToolResult placeholders with the fixed string "missing tool result in session history; inserted synthetic error result for transcript repair." No code path reads MEMORY.md or bootstrap context. No fallback assistant-text content path exists.

dist/runs-CCsjme9h.js line ~268 — abortActiveReplyRuns({ mode: "compacting" }) only matches operations in preflight_compacting or memory_flushing phase. Normal running phase operations are skipped and allowed to drain naturally.

dist/gateway-cli-l4SoRD2p.js line ~505 — if (activeRuns > 0) abortEmbeddedPiRun(void 0, { mode: "compacting" }) confirmed the drain logic initiates compacting-mode abort before waiting for active tasks.

Broader dist tree grep on fallback assistant, defaultAssistant, synthetic.*assistant, placeholder.*assistant, persistPartial, savePartial, streamedSoFar, accumulatedContent — zero relevant hits.

No API keys, tokens, or passwords are included. MEMORY.md content referenced in this report has been described structurally only, not reproduced.

Impact and severity

Affected users/systems/channels: Single operator deployment observed. Telegram channel delivery. One persistent agent (Hope) running as a long-running gateway service on a Mac mini. Cannot confirm whether other operators or channels are affected — this is a single-incident observation.

Severity: Data risk. The verbatim content surfaced was from the agent's bootstrap context (MEMORY.md), which contains operational doctrine, session history, and strategic information intended to be internal to the agent's system prompt. A client operator or end user receiving this content in a conversational response would see internal system-prompt material without any indication that it was not freshly authored response content. No error, no wrapper, no marker of any kind.

Frequency: Edge case. Observed twice in the same session under a specific trigger condition (SIGTERM received by the gateway during an active in-flight generation, caused by a self-undermining exec call). Has not recurred since the trigger condition was eliminated on our side. Cannot confirm frequency for other operators or trigger paths.

Consequence: Internal bootstrap context (system prompt material) surfaced verbatim in client-visible responses with no structural distinction from freshly authored content. For a production deployment serving paying clients, this would constitute an unexpected disclosure of internal agent configuration material and would likely erode client trust in the system's reliability and integrity.

Additional information

This is not a confirmed regression — we have no prior version to compare against as this is our first observation of this behavior. Last known good behavior: all prior sessions across multiple days of operation produced no verbatim bootstrap content in any assistant response. First known bad: 2026-05-30, session running OpenClaw 2026.4.26.

Additional context that may aid triage:

The session was unusually long at the time of the incident — approximately 8 hours of continuous operation with a high volume of tool calls, subagent spawns, and large context operations including a MEMORY.md trim cycle approximately 2.5 hours before the incident.

The consistent-target pattern — the same MEMORY.md block appearing verbatim in both affected responses — may be diagnostically useful. The block in question was the most prominent recent SITREP-shaped section in the post-trim bootstrap, located near the front of the system prompt after the trim cycle rebuilt it. If OpenClaw maintains any bootstrap attention weighting or caching that could amplify recently loaded content, this detail may be relevant.

The behavioral fix on our side (never invoking gateway lifecycle commands through the gateway's own exec channel) prevents recurrence under operator control. We are not able to confirm whether other SIGTERM sources — system shutdown, OOM kill, operator-side process termination — would produce the same pattern.

We are happy to provide additional context if useful to the maintainers.