Bug type

Regression (worked before, now fails)

Summary

After upgrading to OpenClaw 2026.3.7, kimi-coding/k2p5 in the Control UI no longer reliably invokes tools. Instead of producing a real Exec tool event/card, it sometimes replies with plain assistant text claiming completion or literally prints exec({...}) into the chat.

Steps to reproduce

1. Upgrade OpenClaw to 2026.3.7 on macOS.
2. Open the Control UI chat (agent:main:main).
3. Switch the current session model to kimi-coding/k2p5.
4. Ask for a simple filesystem action, for example: make a folder named test_folder2 in my Downloads.
5. Observe that Kimi may output plain text such as Done... or literal exec({"command": ...}) in the chat instead of producing a real Exec tool card/event.
6. In the same install, switch the session model to google/gemini-3-flash-preview and repeat the same request.
7. Observe that Gemini produces a real Exec card and the folder is actually created.

Expected behavior

kimi-coding/k2p5 should emit a structured tool call that OpenClaw executes, with the Control UI showing a real Exec tool card just like the working Gemini path.

Actual behavior

Kimi sometimes emits plain assistant text or literal fake tool-call text such as exec({"command":"mkdir -p ~/Downloads/test_folder2"}) into the chat. No real tool event/card is produced for those failed turns.

OpenClaw version

2026.3.7

Operating system

macOS 26.2 (arm64) · Node 25.2.1

Install method

npm/Homebrew-style global install with LaunchAgent gateway + node services

Logs, screenshots, and evidence

Local evidence from the affected machine:
- Gateway log captured a Kimi reply containing literal fake tool-call text at `2026-03-08 21:11:29 +08:00`.
- The same install successfully executed the equivalent folder-creation request with `google/gemini-3-flash-preview`, showing a real `Exec` card in the Control UI.
- OpenClaw package metadata reports version `2026.3.7`.
- The installed 2026.3.7 changelog already mentions Kimi tool-call compatibility changes, so this looks regression-adjacent.

Impact and severity

Affected: users relying on kimi-coding/k2p5 for real tool execution in Control UI sessions.
Severity: High for Kimi users because command execution becomes unreliable/untrustworthy.
Frequency: Intermittent but reproducible enough to block confidence in tool use.
Consequence: The assistant may claim actions completed when no real tool event was emitted, making filesystem/browser automation unsafe to trust.

Additional information

This appears specific to the Kimi integration path rather than the generic executor path.

Important comparison:

• kimi-coding/k2p5: sometimes prints fake exec({...}) text or plain completion text
• google/gemini-3-flash-preview: produces a real Exec tool card and actually runs the command on the same machine

The local install also shows Kimi configured via anthropic-messages, and the 2026.3.7 runtime contains a Kimi-specific tool-payload normalization wrapper. That suggests the regression may be in the Kimi compatibility layer (request shaping and/or response parsing), not in the gateway/node executor itself.

Last known good: before upgrading to 2026.3.7, Kimi tool execution worked normally for this setup.
First known bad: immediately after upgrading/reconfiguring to 2026.3.7 on 2026-03-08.