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
- Upgrade OpenClaw to 2026.3.7 on macOS.
- Open the Control UI chat (
agent:main:main).
- Switch the current session model to
kimi-coding/k2p5.
- Ask for a simple filesystem action, for example:
make a folder named test_folder2 in my Downloads.
- 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.
- In the same install, switch the session model to
google/gemini-3-flash-preview and repeat the same request.
- 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 textgoogle/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.
Bug type
Regression (worked before, now fails)
Summary
After upgrading to OpenClaw 2026.3.7,
kimi-coding/k2p5in 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 printsexec({...})into the chat.Steps to reproduce
agent:main:main).kimi-coding/k2p5.make a folder named test_folder2 in my Downloads.Done...or literalexec({"command": ...})in the chat instead of producing a realExectool card/event.google/gemini-3-flash-previewand repeat the same request.Execcard and the folder is actually created.Expected behavior
kimi-coding/k2p5should emit a structured tool call that OpenClaw executes, with the Control UI showing a realExectool 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
Impact and severity
Affected: users relying on
kimi-coding/k2p5for 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 fakeexec({...})text or plain completion textgoogle/gemini-3-flash-preview: produces a realExectool card and actually runs the command on the same machineThe 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.