Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Tool-call arguments occasionally become empty object with kimi-coding/k2p5 [3 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#54442•Fetched 2026-04-08 01:27:24
View on GitHub
Comments
0
Participants
1
Timeline
7
Reactions
0
Author
traceless929traceless929
Participants
traceless929traceless929
Timeline (top)
cross-referenced ×3referenced ×2closed ×1locked ×1

When using kimi-coding/k2p5 (Anthropic Messages API) in OpenClaw, tool calls intermittently arrive with empty arguments ({}), causing validation failures such as:

  • Validation failed for tool \"exec\": command: must have required property 'command'
  • Similar behavior also observed for tools requiring required fields (e.g. web_search.query, gateway.action).

Switching the same agent/session behavior to openai-codex/gpt-5.4 significantly reduces the issue.

Root Cause

When using kimi-coding/k2p5 (Anthropic Messages API) in OpenClaw, tool calls intermittently arrive with empty arguments ({}), causing validation failures such as:

  • Validation failed for tool \"exec\": command: must have required property 'command'
  • Similar behavior also observed for tools requiring required fields (e.g. web_search.query, gateway.action).

Switching the same agent/session behavior to openai-codex/gpt-5.4 significantly reduces the issue.

PR fix notes

PR #54448: fix: preserve Kimi tool call arguments instead of clearing valid JSON

Description (problem / solution / changelog)

Summary

Fixes three related bugs in the Kimi (kimi-coding/k2p5) tool call argument repair pipeline that cause tool calls to fail with empty or undefined arguments:

  • tryParseMalformedToolCallArguments treats valid JSON as unfixable: When accumulated streaming JSON is already valid, JSON.parse(raw) succeeds but the function returns undefined — the same signal as "unrepairable". The caller then clears arguments, wiping correct tool parameters.
  • clearToolCallArgumentsInMessage assigns {} instead of undefined: The empty object pollutes shared references. Downstream validators see a present-but-empty object and report must have required property 'command' instead of recognizing arguments as absent.
  • else branch in wrapStreamRepairMalformedToolCallArguments unconditionally clears arguments: When repair returns undefined, arguments may already be correctly set via content_block_start.input (Kimi's non-incremental streaming path). Clearing here wipes them. The fix lets content_block_stop handle final argument resolution.

Root cause

Kimi k2p5 has two streaming behaviors:

  1. Incremental: content_block_start with input: {}, then input_json_delta events build up arguments
  2. Non-incremental: content_block_start with full input: {path: "..."}, no input_json_delta at all

The repair wrapper assumed path 1 exclusively. In path 2, partialJson stays empty, tryParseMalformedToolCallArguments("") returns undefined, and the else branch wiped the already-correct arguments.

Changes

FileChange
attempt.tstryParseMalformedToolCallArguments: return parsed args when JSON is valid
attempt.tsRemove clearToolCallArgumentsInMessage (no longer called)
attempt.tsRemove clear calls from the else branch in the stream wrapper
attempt.test.tsUpdate existing test + add 2 new tests covering the fix

Reproduction

With kimi-coding/k2p5:

# Before fix:
Validation failed for tool "exec":
  - command: must have required property 'command'
Received arguments: {}

# Or:
read tool called without path: toolCallId=tool_xxx argsType=undefined

Note on remaining pi-ai issues

Two additional Kimi tool call bugs exist in the upstream @mariozechner/pi-ai package (not addressed here):

  • content_block_stop overwrites block.arguments with parseStreamingJson("") → {} even when partialJson is empty
  • A "Kimi API bug workaround" in content_block_start converts input: {} to undefined

These require a separate fix in pi-ai. This PR addresses all bugs within OpenClaw's own codebase.

Test plan

  • All 95 existing tests in attempt.test.ts pass
  • New test: valid JSON arguments are preserved through the repair pipeline
  • New test: arguments set by content_block_start.input survive incomplete delta attempts
  • Updated test: trailing suffix growing too long preserves last valid repair instead of wiping
  • TypeScript type check passes (pnpm tsgo)
  • Full lint/format check passes (pnpm check)
  • Manual verification with kimi-coding/k2p5 on Telegram

Fixes #54442 Fixes #53747 Refs #54366

🤖 Generated with Claude Code

Changed files

  • src/agents/pi-embedded-runner/run/attempt.test.ts (modified, +93/-2)
  • src/agents/pi-embedded-runner/run/attempt.ts (modified, +13/-23)

PR #55153: fix: preserve valid Kimi tool call arguments in malformed-args repair

Description (problem / solution / changelog)

Summary

  • Problem: the Kimi Anthropic-compatible malformed-args repair wrapper can clear already-valid tool-call arguments when a closing } delta completes a valid JSON object.
  • Why it matters: valid Kimi tool calls can arrive downstream as {}, which breaks tool validation and execution.
  • What changed: add a JSON-object validity guard before the destructive clear path and add a regression test for the split-delta completion case.
  • What did NOT change (scope boundary): no provider matching changes, no repair-heuristic widening, and no behavior changes for non-Kimi providers.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #54442
  • Related #54448
  • Related #54491

User-visible / Behavior Changes

Kimi Anthropic-compatible tool calls no longer lose valid arguments on the wrapper's valid-JSON path.

Security Impact (required)

  • New permissions/capabilities? (Yes/No): No
  • Secrets/tokens handling changed? (Yes/No): No
  • New/changed network calls? (Yes/No): No
  • Command/tool execution surface changed? (Yes/No): No
  • Data access scope changed? (Yes/No): No
  • If any Yes, explain risk + mitigation:

Repro + Verification

Environment

  • OS: macOS
  • Runtime/container: Node.js 22, local checkout
  • Model/provider: kimi with anthropic-messages wrapper path
  • Integration/channel (if any): N/A
  • Relevant config (redacted): N/A, unit reproduction in attempt.test.ts

Steps

  1. Stream a Kimi tool call where the JSON object is completed by a later } delta.
  2. Let the malformed-args wrapper evaluate that closing delta.
  3. Observe whether the wrapper preserves the parsed arguments or clears them.

Expected

  • Valid JSON arguments stay intact.

Actual

  • Before this change, the wrapper could clear arguments to {} because "valid JSON" and "unrepairable" both took the same branch.

Evidence

Attach at least one:

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios: pnpm test -- src/agents/pi-embedded-runner/run/attempt.test.ts on the rebased branch (94 tests passed), and pnpm build on the same branch.
  • Edge cases checked: existing malformed trailing-junk repair coverage in attempt.test.ts still passes alongside the new valid-JSON regression.
  • What you did not verify: a live Kimi session against the provider.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

  • Backward compatible? (Yes/No): Yes
  • Config/env changes? (Yes/No): No
  • Migration needed? (Yes/No): No
  • If yes, exact upgrade steps:

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly: revert this commit.
  • Files/config to restore: src/agents/pi-embedded-runner/run/attempt.ts, src/agents/pi-embedded-runner/run/attempt.test.ts
  • Known bad symptoms reviewers should watch for: valid Kimi tool calls regressing back to empty {} arguments.

Risks and Mitigations

  • Risk: malformed-but-unrepairable payloads could still be misunderstood if a future provider changes the wrapper contract.
    • Mitigation: this change only skips the clear path when the accumulated payload is already a valid JSON object; existing malformed-payload behavior is otherwise unchanged, and the regression test locks in the closing-delta case.

Changed files

  • src/agents/pi-embedded-runner/run/attempt.test.ts (modified, +51/-0)
  • src/agents/pi-embedded-runner/run/attempt.ts (modified, +11/-1)

PR #59440: fix: normalize Kimi anthropic tool payloads

Description (problem / solution / changelog)

Summary

  • mark Kimi and Kimi Coding as OpenAI-function-style Anthropic tool payload providers
  • align the bundled plugin capability metadata with the fallback capability registry
  • add regression coverage for Kimi payload normalization on the Anthropic Messages path

Fixes #59327 Fixes #54442 Fixes #58817 Fixes #53747 Fixes #56916

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • extensions/kimi-coding/index.ts (modified, +2/-0)
  • src/agents/pi-embedded-runner-extraparams.test.ts (modified, +71/-8)
  • src/agents/provider-capabilities.test.ts (modified, +13/-6)
  • src/agents/provider-capabilities.ts (modified, +2/-0)

Code Example

Validation failed for tool "exec":
  - command: must have required property 'command'

Received arguments:
{}
RAW_BUFFERClick to expand / collapse

Summary

When using kimi-coding/k2p5 (Anthropic Messages API) in OpenClaw, tool calls intermittently arrive with empty arguments ({}), causing validation failures such as:

  • Validation failed for tool \"exec\": command: must have required property 'command'
  • Similar behavior also observed for tools requiring required fields (e.g. web_search.query, gateway.action).

Switching the same agent/session behavior to openai-codex/gpt-5.4 significantly reduces the issue.

Environment

  • OpenClaw: 2026.3.23-2
  • OS: Linux 5.15.0-100-generic
  • Node: 22.22.1
  • Model with issue: kimi-coding/k2p5 (api: anthropic-messages)
  • Comparison model: openai-codex/gpt-5.4 (issue much less frequent)

Representative logs

From session transcript:

Validation failed for tool "exec":
  - command: must have required property 'command'

Received arguments:
{}

There are multiple consecutive occurrences in a single session where the assistant emits toolCall for exec with arguments: {}.

Repro pattern (not 100% deterministic)

  1. Use kimi-coding/k2p5 as agent model.
  2. Run in a long-context conversation (memory-heavy/system-heavy prompt).
  3. Ask for short imperative actions (e.g., "execute", "check status", etc.).
  4. Observe occasional tool calls emitted without required arguments.

Expected behavior

If model tool-call output is missing required fields, OpenClaw should ideally:

  • optionally auto-repair/retry once with strict schema reminder, or
  • fail gracefully with a model-side fallback strategy.

Actual behavior

OpenClaw correctly rejects invalid calls, but repeated {} tool calls can loop/flood errors in a session.

Request

Could maintainers confirm whether this is a known compatibility issue for specific model providers, and whether OpenClaw should add a resilience layer (auto-retry / required-field guardrail) for malformed tool arguments?

extent analysis

Fix Plan

To address the issue of intermittent empty arguments ({}) in tool calls, we will implement a resilience layer in OpenClaw. This layer will include an auto-retry mechanism with a strict schema reminder and a required-field guardrail for malformed tool arguments.

Step-by-Step Solution

  1. Implement auto-retry with schema reminder:

    • Catch validation errors for tool calls.
    • If a validation error occurs due to missing required fields, retry the tool call once with a strict schema reminder.

  2. Add required-field guardrail:

    • Before processing tool calls, check if all required fields are present.
    • If a required field is missing, either auto-repair the call by adding a default value (if applicable) or fail gracefully with a model-side fallback strategy.

Example Code Snippet

// Assuming a function `processToolCall` that handles tool calls
function processToolCall(toolCall) {
  try {
    // Validate tool call arguments
    validateToolCallArguments(toolCall);
    
    // Process the tool call
    // ...
  } catch (validationError) {
    // Check if the error is due to missing required fields
    if (isMissingRequiredFieldsError(validationError)) {
      // Retry the tool call with a strict schema reminder
      retryToolCallWithSchemaReminder(toolCall);
    } else {
      // Handle other types of errors
      // ...
    }
  }
}

// Function to validate tool call arguments
function validateToolCallArguments(toolCall) {
  const requiredFields = getRequiredFieldsForTool(toolCall.tool);
  requiredFields.forEach((field) => {
    if (!toolCall.arguments[field]) {
      throw new Error(`Missing required field: ${field}`);
    }
  });
}

// Function to retry a tool call with a strict schema reminder
function retryToolCallWithSchemaReminder(toolCall) {
  // Add a strict schema reminder to the tool call
  toolCall.schemaReminder = true;
  
  // Retry the tool call
  processToolCall(toolCall);
}

// Function to check if an error is due to missing required fields
function isMissingRequiredFieldsError(error) {
  // Implement logic to check if the error is due to missing required fields
  // ...
}

Verification

To verify that the fix worked, test the OpenClaw system with the kimi-coding/k2p5 model and a long-context conversation. Ask for short imperative actions and observe if the tool calls are emitted with required arguments. Check the logs for any validation errors and verify that the auto-retry mechanism and required-field guardrail are working as expected.

Extra Tips

  • Make sure to handle the case where the auto-retry mechanism fails to resolve the issue, to prevent infinite loops.
  • Consider adding logging and monitoring to track the frequency of validation errors and the effectiveness of the auto-retry mechanism

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

If model tool-call output is missing required fields, OpenClaw should ideally:

  • optionally auto-repair/retry once with strict schema reminder, or
  • fail gracefully with a model-side fallback strategy.
#api#installation#tensor shape#autograd error#model save/load

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix Tool-call arguments occasionally become empty object with kimi-coding/k2p5 [3 pull requests, 1 participants]