openclaw - 💡(How to fix) Fix feat(agents): treat openclaw.runtime-context custom_message as system turn, not user [1 comments, 2 participants]

Problem

When a user message arrives while the agent is actively running (mid-turn, e.g. during a tool call), the OpenClaw runtime injects a custom_message entry with customType: "openclaw.runtime-context" into the session JSONL. This entry is inserted between the previous user message and the next user message in the transcript.

Symptom: conversation flow fragmentation

In a live session, consecutive user messages get interleaved with metadata blocks:

Line 14: role=user "现有的6个公司的readme先不要改造"
Line 15: type=custom_message customType=openclaw.runtime-context  ← injected mid-turn
Line 16: role=user "我是让你思考下方案！"

52 such custom_message runtime-context blocks were found in a single 407-entry session (1299 KB). The pattern is consistent: every time a user message arrives while a turn is active, a runtime-context block is injected, breaking the user↔user adjacency.

Symptom: context loss / wrong behavior

When the agent processes these fragmented transcripts (especially after compaction), it cannot correctly understand the conversation state. In one case, the user asked to "write a log" and the agent wrote to the wrong directory, then replied NO_REPLY — indicating it lost track of the conversation context.

Expected behavior

The openclaw.runtime-context metadata should be injected as a system turn (with role: "system" or equivalent), not as an orphaned custom_message that:

• has no role field (making it ambiguous to the model)
• breaks user↔user adjacency in the transcript
• confuses compaction logic

Session metadata

• Session: 660ef52a-acff-4c1c-96d4-8a8554094328.jsonl
• Agent: main (麦当劳)
• Runtime: embedded (Feishu DM)
• Session size: 1299 KB, 414 entries, 52 runtime-context blocks

Technical detail

The custom_message entries have this shape:

{
  "type": "custom_message",
  "customType": "openclaw.runtime-context",
  "content": "System: [timestamp] Feishu[main] DM | ..."
}

They lack a message.role field, which means the compaction and transcript-reading logic may treat them as user messages (since they appear between user messages), causing the fragmentation described above.