[Bug]: Discord message body treated as elided after tool call in same turn

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

A Discord message body is available on the first model call but is treated as missing after a tool result resumes the same turn, while the full body remains intact in the SQLite transcript.

Steps to reproduce

1. Run OpenClaw 2026.9.4 on Windows with Discord and MiniMax-M3.
2. Send a short instruction that requires a tool, such as: Use exec to run a command that returns the computer hostname. Report the raw stdout and exit code. Do not answer from memory.
3. Observe that the first model call sees the complete body and invokes exec.
4. Let the tool result resume the same run.
5. On an affected installation, the resumed model call says the active message body is elided, asks the user to resend it, or infers it from older history.

The issue was also reproduced with the one-word message approved: the first call recognized it and launched a tool, while later calls in the same run claimed its body was missing.

Expected behavior

After receiving the tool result, the same run should continue the complete instruction from the latest user-role message and produce the requested final response without reporting message-body loss. A local runtime-context clarification produced this expected behavior in a fresh before/after test.

Actual behavior

The initial model call sees the full Discord body and starts the requested tool. After the tool result, later model calls in the same run receive active-message runtime metadata and repeatedly claim the body is elided, even though the original user-role event still contains the full body in the SQLite transcript. In one reproduced turn this caused multiple replacement exec calls and repeated requests for confirmation.

OpenClaw version

2026.9.4

Operating system

Windows 11

Install method

npm global install; Gateway launched from the OpenClaw Windows gateway command on Node 24.18.0

Model

MiniMax-M3

Provider / routing chain

Discord channel -> OpenClaw Gateway -> MiniMax-M3 via the Anthropic Messages-compatible provider path

Additional provider/model setup details

Gateway bound to local loopback. The failure was reproduced in a Discord channel session. No credentials, machine identifiers, or private message content are included here.

Logs

Observed single-run sequence:
- User event persisted with full body `approved`
- Assistant event explicitly recognized `approved` and issued an exec tool call
- Tool-result event recorded the running command
- Later assistant events in the same run claimed the active message body was elided

This rules out Discord delivery loss and transcript persistence loss.

Screenshots, recordings, and evidence

After a local runtime-context clarification, a fresh test produced this single-run chain:

• Full Discord instruction persisted
• Real exec tool call persisted
• Tool result returned the expected hostname (value redacted)
• Final assistant response reported raw stdout and exit code 0
• No elision warning or resend request

Impact and severity

Affected system/channel: Discord sessions that continue after tool calls, reproduced with MiniMax-M3. Severity: workflow-blocking when the instruction is short or approval-sensitive. Frequency: reproduced repeatedly before the workaround; the exact trigger is an in-turn tool continuation. Consequence: duplicate tool launches, unnecessary resend requests, and failure to complete the user instruction reliably.

Additional information

Suspected area: the retained openclaw.runtime-context carrier used across tool calls. The carrier identifies the active request but does not repeat the body; MiniMax-M3 then interprets the absence from that metadata block as message loss even though the body remains in the latest user-role message.

Relevant built output: runtime-context-prompt-*.mjs (resolveRuntimeContextPromptParts, buildRuntimeContextCustomMessage) and builtin-openclaw-*.mjs (settled tool finalization/transcript-prompt forwarding).

The local change that stopped the reproduction added an explicit statement to the retained carrier that the body remains in the latest user-role message and is intentionally not duplicated in runtime metadata. Two defensive changes preserving transcriptPrompt and retaining the transcript prompt in a differing model prompt did not stop the same-run failure by themselves.

Related: #94549, #72386, #86849.