Summary

Kimi Coding via the official Kimi Code Anthropic-compatible endpoint started producing malformed tool calls after upgrading OpenClaw. The most visible failure is repeated read calls with no path / file_path.

This looks like a fresh regression on current builds, not the old Moonshot Direct / OpenAI-compatible issue from #15809.

Current Environment

• OpenClaw: 2026.3.23-1
• Runtime seen in logs: Node 25.8.1
• Provider: kimi-coding
• Model configured in OpenClaw: k2p5
• API mode: anthropic-messages
• Base URL: https://api.kimi.com/coding/
• Host OS: Linux

Important distinction

This is not using the old api.moonshot.ai OpenAI-compatible route.
It is using the official Kimi Code endpoint documented here:
Use in Third-Party Coding Agents

In my OpenClaw config the provider is configured roughly as:

{
  "baseUrl": "https://api.kimi.com/coding/",
  "api": "anthropic-messages",
  "models": [{ "id": "k2p5" }]
}

Symptoms

OpenClaw logs repeatedly show malformed read tool calls:

[agent/embedded] read tool called without path: toolCallId=... argsType=object
[tools] read failed: Missing required parameter: path (path or file_path). Supply correct parameters before retrying.

This happens many times on current builds.

What I verified outside OpenClaw

Using the same Kimi Coding API key against the same official Anthropic-compatible endpoint, direct API calls succeed:

• POST https://api.kimi.com/coding/v1/messages
• headers: x-api-key, anthropic-version: 2023-06-01
• model: k2p5

Direct minimal tests produce valid tool payloads:

• exec returns valid {"command":"pwd"} / {"command":"ls -la"}
• read returns valid {"path":"package.json"} or {"file_path":"package.json"}

So this does not look like a Kimi endpoint incompatibility by itself.
It looks like a regression in OpenClaw's runtime integration / prompting / tool orchestration for Kimi Coding on newer builds.

What I found in real OpenClaw logs

Case 1: exec succeeds, then later read loses path

Run ID:

acp_agent:main:main_1773151117097

Sequence from logs:

embedded run start ... provider=kimi-coding model=k2p5
embedded run tool start ... tool=exec
embedded run tool end ... tool=exec
embedded run tool start ... tool=exec
embedded run tool end ... tool=exec
read tool called without path ... argsType=object
embedded run tool start ... tool=read

So in this run, exec itself is fine, but the next read tool call is malformed.

Case 2: malformed read happens even before exec

Run ID:

acp_agent:main:main_1773225025043

Sequence from logs:

embedded run start ... provider=kimi-coding model=k2p5
read tool called without path ...
embedded run tool start ... tool=read
...
embedded run tool start ... tool=exec
embedded run tool end ... tool=exec

So exec is not the root cause. It only often appears in failing sessions because the agent is doing multi-step tool planning.

Regression signal

From my archived logs:

• older runtime signatures (22.22.0) show only a small number of read tool called without path events
• newer runtime signatures (25.8.1) show a much larger number of these events

This strongly suggests the issue became materially worse after upgrading OpenClaw.

Why I think this is an OpenClaw regression

• Same Kimi Coding key + same endpoint works fine in direct Anthropic-compatible API tests
• exec tool arguments are valid in direct tests
• read tool arguments are also valid in direct tests
• Failures are occurring inside OpenClaw's real runtime during multi-tool execution
• The bad payload is specifically the tool-call input object OpenClaw receives from the model during runtime

Expected behavior

On current OpenClaw builds, Kimi Coding (k2p5) via https://api.kimi.com/coding/ should preserve valid tool-call arguments the same way it does in direct API tests.

Actual behavior

On current OpenClaw builds, Kimi Coding sessions intermittently emit malformed read tool calls without path, causing file operations to fail and derailing the run.

Related issue

This seems related in symptom family to closed stale issue #15809, but that one was about Moonshot Direct / OpenAI-compatible routing. This new report is for the official Kimi Code Anthropic-compatible endpoint on current OpenClaw builds.

Request

Please test Kimi Coding (k2p5) on current OpenClaw builds using the official Anthropic-compatible endpoint and multi-step tool workflows that involve exec followed by file reads. My current evidence suggests the regression is in OpenClaw's Kimi integration rather than the provider endpoint itself.