Summary

• Problem: When a user message is passed to the LLM, the metadata blocks (sender info, conversation info, etc.) and the actual user message content are joined with only double newlines. This causes the LLM to sometimes misinterpret the message structure, treating the metadata as the entire message and ignoring the actual user content ("message is empty" replies).
• Why it matters: Users intermittently get incorrect "message is empty" responses even though their message was correctly stored in session history.
• What changed:
  • runtime-context-prompt.ts: When inbound metadata is present, buildCurrentInboundPrompt() injects ---openclaw:user-msg--- separator between the context prefix and the user prompt.
  • strip-inbound-meta.ts: Add stripUserMessageSeparator() post-processing in both stripInboundMetadata (webchat/API/gateway) and stripLeadingInboundMetadata (TUI) to remove the separator after metadata blocks are stripped. Gated on didStripMetadata flag for defense-in-depth.
  • strip-inbound-meta.test.ts: 7 new tests covering separator stripping and legacy preservation.
• What did NOT change (scope boundary): No API changes, no new types, no changes to buildInboundUserContextPrefix, no metadata format changes.

Why ---openclaw:user-msg--- instead of ---\n**User Message:**

The separator is a program-generated marker that cannot exist in any legacy stored message or user-typed content. This eliminates the need for complex detection logic (_sep markers, seenUserContent flags, structural JSON parsing) and makes legacy message compatibility trivial: the stripper only removes ---openclaw:user-msg---, which legacy data never contains.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• None

User-visible / Behavior Changes

• LLM now receives a clear ---openclaw:user-msg--- separator between metadata and user content, reducing "message is empty" false positives.
• The separator is stripped in all user-facing surfaces (TUI, webchat, gateway API, session cost logs).
• Legacy messages (pre-upgrade) are completely unaffected — the unique marker cannot appear in historical data.

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification

Environment

• OS: Linux (Ubuntu 24.04)
• Runtime: Node v24.15.0, pnpm 10.23.0

Steps

1. Send a message to the LLM through any channel with metadata (group chat, sender info, etc.)
2. Observe the prompt construction in buildCurrentInboundPrompt()
3. Verify the separator appears between metadata and user content
4. Verify stripInboundMetadata / stripLeadingInboundMetadata removes the separator in user-facing views

Expected

• LLM correctly distinguishes metadata from user message content
• No separator visible in TUI/webchat/gateway/session logs

Actual

• Confirmed working as expected in unit tests and live CLI verification (see Real behavior proof below)

Evidence

• Passing tests: 39 strip-inbound-meta tests pass (7 new separator-specific tests)
• New tests cover: separator after single/multiple metadata blocks, no-metadata preservation, non-separator --- preservation, sentinel-without-metadata-block edge case, legacy message preservation

Real behavior proof

Live CLI verification on the rebased branch (b69cb795):

Behavior or issue addressed: Metadata and user message content are joined with only double newlines, causing the LLM to misinterpret the message structure and ignore actual user content.

Real environment tested: Local OpenClaw development setup on Ubuntu 24.04 with Node v24.15.0.

Exact steps or command run after this patch:

1. npx tsx proof-test.mjs - Live CLI verification of separator injection and stripping
2. pnpm test strip-inbound-meta - Unit tests for the new separator logic

Evidence after fix:

=== Real Behavior Proof: User Message Separator ===

1. buildCurrentInboundPrompt WITH metadata:
---
Conversation info (untrusted metadata):
```json
{"channel": "#general", "sender": "Alice"}

---openclaw:user-msg---
Hello, how are you?

✅ Separator ---openclaw:user-msg--- is present between metadata and user message

2. buildCurrentInboundPrompt WITHOUT metadata:

Hello, how are you?

✅ No separator injected when metadata is absent

3. stripInboundMetadata (metadata + separator):
   Input: (metadata + separator + user message)
   Output: Hello, how are you?
   ✅ Metadata and separator both removed

4. stripLeadingInboundMetadata (metadata + separator):
   Input: (metadata + separator + user message)
   Output: Hello, how are you?
   ✅ Metadata and separator both removed in leading-only strip mode

5. Legacy message (no metadata, user has --- in content):
   Input: Hello\n\n---\nSome user markdown
   Output: Hello\n\n---\nSome user markdown (preserved intact)
   ✅ Legacy user content preserved, no false stripping

=== All checks passed ===

All tests (39 total) pass.

**Observed result after fix:** The separator is correctly injected when metadata is present and correctly stripped in all user-facing surfaces. Legacy messages without metadata are completely unaffected.

**What was not tested:** Live end-to-end with real LLM provider (simulated in unit tests).

## Human Verification (required)

- Verified scenarios: metadata with separator injection, separator stripping after single/multiple metadata blocks, preservation when no metadata present, preservation of `---` in non-separator context
- Edge cases checked: legacy messages with `---\n**User Message:**` user content (preserved intact), sentinel text without metadata fences, user content starting with generic `---`
- What you did **not** verify: Live end-to-end with real LLM provider

## Review Conversations

- [x] I replied to or resolved every bot review conversation I addressed in this PR.
- [x] I left unresolved only the conversations that still need reviewer or maintainer judgment.

## Compatibility / Migration

- Backward compatible? `Yes` — legacy messages are unaffected; the unique marker cannot appear in pre-upgrade data
- Config/env changes? `No`
- Migration needed? `No`

## Failure Recovery (if this breaks)

- How to disable/revert this change quickly: Revert the single commit
- Files/config to restore: `runtime-context-prompt.ts`, `strip-inbound-meta.ts`
- Known bad symptoms: `---openclaw:user-msg---` appearing in TUI/webchat/session history

## Risks and Mitigations

- Risk: LLM treats `---openclaw:user-msg---` as confusing noise
  - Mitigation: The marker reads like a boundary tag; LLMs routinely handle similar delimiters in system/user prompts. It's a single line and less disruptive than the metadata blocks themselves.