openclaw - 💡(How to fix) Fix Beta blocker: boot-md startup hook can persist BOOT.md synthetic prompts into active main session

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

Yes

Summary

The bundled boot-md startup hook can persist synthetic BOOT.md prompts into the canonical user session transcript and Lossless/LCM conversation, causing repeated hidden context growth across gateway restarts.

Steps to reproduce

Observed on an installed OpenClaw gateway:

1. Run OpenClaw 2026.5.19 with the bundled internal hooks enabled.
2. Configure/use a main agent lane where the user-facing conversation is the canonical main session, e.g. agent:main:main.
3. Have a BOOT.md present so the bundled boot-md hook runs on gateway startup.
4. Restart the gateway repeatedly.
5. Inspect the active session transcript and LCM messages for synthetic user turns beginning with:

You are running a boot check. Follow BOOT.md instructions exactly.

Expected behavior

Startup boot checks should not persist full synthetic BOOT.md prompts into the canonical user-facing conversation history or LCM active context.

Acceptable implementation shapes:

• run boot-md in an isolated/ephemeral boot session,
• make the boot-check prompt non-persistent by default,
• store it as internal audit metadata excluded from active prompt/context-engine assembly,
• or require explicit opt-in before writing it into the canonical user session.

Actual behavior

The startup hook wrote repeated synthetic boot-check prompts into the active user transcript and LCM message history.

In the observed install:

• the active transcript contained 15 full boot-check user prompts,
• each prompt body was about 3,208 characters,
• LCM token accounting counted each boot user message at about 802 tokens,
• repeated restarts appended more synthetic turns,
• several synthetic turns were followed by NO_REPLY or failed assistant turns,
• the transcript fell from 137 lines / 188,446 bytes to 92 lines / 114,063 bytes after removing only the synthetic boot material,
• startup logs changed from loaded 5 internal hook handlers plus a synthetic-prompt lane to loaded 4 internal hook handlers and no synthetic lane after disabling only boot-md.

This is distinct from #84936 / #84954. That issue/PR addresses Telegram per-peer runtime-policy keys leaking into context-engine/LCM selection. This issue is about a bundled startup hook mutating the canonical session even without a user message.

OpenClaw version

2026.5.19

Operating system

macOS / Darwin arm64

Install method

Global OpenClaw gateway managed by launchd (ai.openclaw.gateway)

Model

gpt-5.5

Provider / routing chain

OpenClaw gateway -> embedded agent / Codex app-server -> Lossless context engine -> OpenAI provider

Additional provider/model setup details

The observed model/provider path is not believed to be the cause. The prompt persistence happened at gateway startup before a normal user turn.

The local mitigation was to disable only the bundled boot-md hook while leaving internal hooks enabled:

{
  "hooks": {
    "internal": {
      "enabled": true,
      "entries": {
        "boot-md": {
          "enabled": false
        }
      }
    }
  }
}

Logs, screenshots, and evidence

Relevant installed build paths:

/opt/homebrew/lib/node_modules/openclaw/dist/bundled/boot-md/HOOK.md
/opt/homebrew/lib/node_modules/openclaw/dist/bundled/boot-md/handler.js

Observed log pattern before mitigation:

[hooks] loaded 5 internal hook handlers
[plugins] cortex: skipping recall injection for lane=synthetic-prompt
[agent/embedded] [context-engine] deferred turn maintenance queued ... sessionKey=agent:main:main lane=context-engine-turn-maintenance:agent:main:main

Observed log pattern after disabling only boot-md:

[gateway] agent model: openai/gpt-5.5 (thinking=high, fast=off)
[gateway] http server listening (...)
[hooks] loaded 4 internal hook handlers
[gateway] ready
[telegram] [default] starting provider (...)

No synthetic-prompt lane was observed after the restart with boot-md disabled.

Local transcript/LCM evidence, redacted:

before cleanup:
  active transcript lines: 137
  active transcript bytes: 188446
  boot-check prompts in active transcript: 15
  per boot prompt size: ~3208 chars
  LCM token_count for each boot prompt: ~802

after pruning only synthetic boot material:
  active transcript lines: 92
  active transcript bytes: 114063
  boot-check prompts in active transcript: 0

Flow:

flowchart TD
  A["Gateway startup"] --> B["Bundled boot-md hook runs"]
  B --> C["Synthetic prompt: Follow BOOT.md exactly"]
  C --> D["Prompt appended to canonical session transcript"]
  D --> E["Lossless/LCM indexes prompt under active conversation"]
  E --> F["Future user turns carry repeated BOOT.md history"]
  F --> G["Context bloat, stale token metadata, possible compaction/failure behavior"]

  classDef bad fill:#ffd6d6,stroke:#cc3333,color:#111;
  class C,D,E,F,G bad;

Impact and severity

Affected: users with bundled internal hooks enabled and BOOT.md present where the active conversation should remain a human/user-facing session.

Severity: High for long-lived local agents and beta/stability testing.

Frequency: every gateway restart while the hook remains enabled, based on the observed startup logs and transcript growth.

Consequence:

• hidden token/context growth unrelated to user messages,
• confusing "context full" or unexpectedly high token usage,
• synthetic boot instructions mixed into real conversation history,
• LCM active context polluted with operational startup prompts,
• possible duplicate/error behavior when combined with other session-key or stale-history bugs.

Additional information

Suggested fix shape:

1. Keep boot-md useful, but do not persist its full prompt into the canonical user session by default.
2. Introduce an isolated boot lane/session key for startup checks.
3. Mark generated boot-check messages as internal/synthetic and exclude them from active user prompt assembly and LCM active context.
4. Add a regression that restarts the gateway with BOOT.md present and asserts the canonical agent:main:main transcript and context-engine history do not grow from the boot check.
5. Consider a one-time migration/doctor warning for existing transcripts that contain repeated You are running a boot check... entries.

This report does not argue that boot-md should be removed. The bug is the persistence target: a startup self-check should not repeatedly mutate the main user-facing conversation unless explicitly configured to do so.