Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Critical: All tools with required parameters receive empty {} arguments - Gateway parameter parsing failure [4 pull requests, 1 comments, 2 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#54975•Fetched 2026-04-08 01:33:59
View on GitHub
Comments
1
Participants
2
Timeline
13
Reactions
1
Author
sonjulavsonjulav
Participants
sonjulavsonjulavyuanaichiyuanaichi
Timeline (top)
cross-referenced ×4referenced ×4labeled ×2closed ×1

All OpenClaw tools with required parameters are failing validation because they receive empty {} arguments instead of the correctly passed parameters. The Gateway appears to be failing to parse parameters before they reach the tool implementation. Example: Sending {"command": "echo test"} to exec tool results in error: Validation failed: command: must have required property 'command'. Received arguments: {}

Error Message

Example: Sending {"command": "echo test"} to exec tool results in error: Validation failed: command: must have required property 'command'. Received arguments: {} 4. All tools fail with "must have required property" error despite correct parameter syntax | Tool | Error Message |

Root Cause

All OpenClaw tools with required parameters are failing validation because they receive empty {} arguments instead of the correctly passed parameters. The Gateway appears to be failing to parse parameters before they reach the tool implementation. Example: Sending {"command": "echo test"} to exec tool results in error: Validation failed: command: must have required property 'command'. Received arguments: {}

Fix Action

Fix / Workaround

Additional context Attempted fixes: Upgrade to 2026.3.24: Partial fix initially (exec worked ~30%), now completely broken Downgrade to 2026.3.22: Same issue persists Multiple gateway restarts: No effect Environment variable fixes: No effect Working tools: Only subagents (read-only) appears functional. Related issues: Possibly related to #47317, #44203, #34810 based on similar parameter validation reports.

PR fix notes

PR #54491: fix(kimi): preserve valid Anthropic-compatible toolCall arguments in malformed-args repair path

Description (problem / solution / changelog)

Summary

  • Problem: When using Kimi in Anthropic-compatible (anthropic-messages) mode, the malformed toolCall-arguments repair logic could fail to preserve otherwise-valid JSON arguments (resulting in missing/empty tool arguments).
  • Why it matters: Tool execution depends on correct toolCall.arguments; losing valid arguments can cause wrong tool behavior, failures, or unexpected “empty args” executions.
  • What changed: Adjusted the Kimi/Anthropic toolCall-argument repair path to keep valid, complete JSON arguments intact and only apply “balanced-prefix + short trailing junk” repair when the arguments are actually malformed.
  • What did NOT change (scope boundary): No changes to tool dispatch logic, tool allowlists, transcript storage, or 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

Root Cause / Regression History (if applicable)

  • Root cause: The malformed-args repair wrapper for Kimi/Anthropic streams treated some valid toolCall argument payloads as candidates for repair, and under certain stream delta patterns it could clear/override arguments instead of preserving the complete JSON object.
  • Missing detection / guardrail: Unit coverage focused on “valid JSON + short trailing junk” but didn’t adequately lock in “valid JSON must remain unchanged” across all relevant stream delta/event sequences.
  • Prior context (git blame, prior PR, issue, or refactor if known): Unknown.
  • Why this regressed now: Likely triggered by Kimi’s Anthropic-compatible streaming behavior (toolcall deltas containing } early / nested JSON / event chunking), which increased the chance the heuristic attempted repair at the wrong time.
  • If unknown, what was ruled out: Not an auth/key issue and not a tool registry/dispatch mismatch; reproduces at the stream parsing/repair layer.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: src/agents/pi-embedded-runner/run/attempt.test.ts (malformed toolCall args repair tests)
  • Scenario the test should lock in: When toolCall arguments are already valid JSON (including nested objects), the repair path must not alter or clear them; when valid JSON is followed by 1–3 trailing junk characters, it should repair to the valid object.
  • Why this is the smallest reliable guardrail: This bug is purely in the stream repair/parsing layer; unit tests can deterministically simulate deltas/events without requiring a live model.
  • Existing test that already covers this (if any): The suite includes a test for “trailing junk follows valid JSON”; this PR strengthens/extends coverage to ensure valid JSON remains intact.
  • If no new test is added, why not: N/A

User-visible / Behavior Changes

None (except improved reliability of tool execution for Kimi Anthropic-compatible runs).

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: N/A

Repro + Verification

Environment

  • OS: macOS
  • Runtime/container: Node.js (local)
  • Model/provider: kimi-coding/k2p5
  • Integration/channel (if any): N/A
  • Relevant config (redacted): Provider set to kimi, model API anthropic-messages

Steps

  1. Configure provider kimi with Anthropic-compatible API (anthropic-messages).
  2. Trigger a tool call where arguments are a valid nested JSON object (e.g. {"path":{"a":"/tmp/report.txt"}}) and/or where streaming deltas include early } tokens.
  3. Observe tool call arguments during/after stream assembly.

Expected

  • Valid JSON arguments are preserved exactly and passed to tool execution unchanged.

Actual

  • Arguments could be cleared/overwritten in the repair path, resulting in incomplete or empty arguments passed to tools.

Evidence

Attach at least one:

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

Human Verification (required)

  • Verified scenarios: Ran the unit tests for the malformed toolCall-arguments repair and confirmed that the final assembled message preserves valid arguments; also confirmed that the “short trailing junk” repair still works. Before the fix, with Kimi in Anthropic-messages streaming mode, multiple consecutive tool_call invocations could carry empty arguments; after the fix, empty-argument tool calls no longer occur.
  • Edge cases checked: -
  • What you did not verify: -

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: N/A

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly: Revert this commit; alternatively disable the Kimi/Anthropic malformed-args repair wrapper if maintainers prefer.
  • Files/config to restore: src/agents/pi-embedded-runner/run/attempt.ts
  • Known bad symptoms reviewers should watch for: Tool calls executed with {}/missing required parameters; intermittent tool failures only on Kimi Anthropic-compatible runs.

Risks and Mitigations

  • Risk: Repair logic might still be triggered too aggressively for some unusual streaming chunk patterns.
    • Mitigation: Keep repair gated to Kimi + anthropic-messages, retain strict trailing-suffix limits, and add/extend unit coverage for representative delta sequences.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/agents/pi-embedded-runner/run/attempt.test.ts (modified, +86/-0)
  • src/agents/pi-embedded-runner/run/attempt.tool-call-argument-repair.ts (modified, +18/-6)

PR #202: 🦅 Scout: Critical Inherited Defect Report - 2026-03-24

Description (problem / solution / changelog)

🦅 Scout: Critical Inherited Defect Report - 2026-03-24

Scanned the upstream OpenClaw repository and identified 3 defect patterns representing critical/high-impact regressions introduced in the recent v2026.3.24 release that are present in our local codebase:

Upstream Issue #54931: BUG: Discord health-monitor triggers uncaught exception crash loop

  • Location in our code: src/discord/monitor/provider.lifecycle.ts
  • Observed Behavior: The Discord health-monitor handles aborts by setting gateway.options.reconnect = { maxAttempts: 0 } and calling gateway.disconnect(). When the WebSocket close handler immediately fires, it checks reconnectAttempts(0) >= maxAttempts(0), evaluating to true, which emits a new Error that goes uncaught, crashing the entire Node.js process and disrupting all subagent sessions.
  • Expected Behavior: Health-monitor should gracefully restart the Discord channel without crashing the gateway process. The forced disconnection path shouldn't invoke the unexpected connection-retry limits error logic, or if it does, the error should be correctly caught instead of bringing down the gateway process.
  • Impact Severity: High — Gateway crashes periodically (every ~35 mins) if Discord goes stale. All running subagent sessions are disrupted or killed.

Upstream Issue #54936: BUG: Subagent runTimeoutSeconds default fallback resolves to infinite timeout instead of configured default

  • Location in our code: src/agents/subagent-registry.ts
  • Observed Behavior: When a subagent is spawned via sessions_spawn without explicitly passing a runTimeoutSeconds parameter, the parameter initializer mistakenly falls back to 0. The downstream timeout resolver interprets 0 as an explicit "disable timeout" instruction, causing the subagent to run indefinitely rather than falling back to the configured default (agents.defaults.subagents.runTimeoutSeconds).
  • Expected Behavior: Subagents should be killed after the configured default runtime timeout when no explicit timeout is passed during the spawn call.
  • Impact Severity: Medium — Subagents spawned without explicit timeouts will run indefinitely, potentially creating zombie processes that stall and exhaust system resources.

Upstream Issue #54975: BUG: All tools with required parameters receive empty {} arguments - Gateway parameter parsing failure

  • Location in our code: Provider integrations (Anthropic/OpenAI compat)
  • Observed Behavior: Third-party providers fail to correctly serialize/send tool parameters, causing validation failures where the agent's intent is lost. Tools receive empty {} arguments instead of the correctly passed parameters.
  • Expected Behavior: Tools should receive the correctly passed parameters and execute successfully.
  • Impact Severity: High — Complete automation blockage when using specific models.

The .jules/scout.md journal has been updated with these patterns for future tracking.

PR created automatically by Jules for task 2111446781902950035 started by @MillionthOdin16

<!-- This is an auto-generated comment: release notes by coderabbit.ai -->

Summary by CodeRabbit

  • Documentation
    • Added documentation for known defect patterns and tracked issues.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Changed files

  • .jules/scout.md (added, +14/-0)
  • report.txt (added, +13/-0)

PR #55287: fix(gateway): add debug logging for empty tool args (#54975)

Description (problem / solution / changelog)

Fixes #54975

Problem

All tools with required parameters receive empty {} arguments.

Solution

Add warning logs to diagnose where params are lost.

Changed files

  • src/gateway/tools-invoke-http.ts (modified, +9/-0)

PR #57716: Agents/tools: fix empty required array bug in tool schema alias handling

Description (problem / solution / changelog)

AI-Assisted

  • This PR was created with assistance from Claude
  • Testing: Unit tests updated and passing (25/26), scoped tests validate the fix
  • I understand the code changes and have verified they work correctly

Summary

Fixes #44203, #37645, #57551, #55528, #54975, #54366

This PR fixes a critical bug where tool schema required arrays were being incorrectly emptied when a dding parameter aliases (e.g., file_path as alias for path). The addClaudeParamAliasesToSchema f unction was removing original parameter names from required without preserving them, causing LLMs to receive schemas with no required parameters.

Changelog Entry

  • Agents/tools: fix empty required array bug in tool schema alias handling. Fixes #44203, #37645.

Problem

The addClaudeParamAliasesToSchema function was removing original parameter names (like path, oldT ext, newText) from the required array but not adding their aliases (like file_path, old_string , new_string). This caused:

  1. LLMs received schemas with empty or incomplete required arrays
  2. Models didn't know which parameters were actually required
  3. Tool calls failed validation with "Missing required parameters" errors
  4. Users experienced 100% failure rate for edit tool and other file operations

Related Issues

This bug has been reported multiple times with various symptoms:

  • #44203 - Original bug report: Edit tool fails with "Missing required parameters"
  • #37645 - Root cause analysis: patchToolSchemaForClaudeCompatibility empties required[] with ex act fix suggestion
  • #57551 - Kimi infinite retry loop consuming tokens due to repeated validation failures
  • #55528 - Write tool content parameter validation failure
  • #54975 - All tools receive empty {} arguments (closed but same root cause)
  • #54366 - kimi-coding/k2p5 model tool parameters empty object

Error Messages Users See

[tools] edit failed: Missing required parameters: path alias, oldText alias, newText alias. Supply cor rect parameters before retrying. [tools] read failed: Missing required parameter: path alias. Supply c orrect parameters before retrying.

Solution

  1. Preserve canonical keys in required array: The addClaudeParamAliasesToSchema function no lo nger modifies the required array. Original parameter names (e.g., path) remain in required, whil e aliases (e.g., file_path) are only added to properties.

  2. Add optional flag to RequiredParamGroup: Allows marking parameter groups as optional for ru ntime validation, supporting edit tool's dual-mode operation (single replacement vs. multi-replacement ).

  3. Cross-field validation for edit tool: Added explicit validation to ensure edit tool receives ei ther edits array or both oldText and newText.

Changes

  • src/agents/pi-tools.params.ts:

    • Add optional field to RequiredParamGroup type
    • Mark oldText/newText as optional in CLAUDE_PARAM_GROUPS.edit
    • Stop modifying required array in addClaudeParamAliasesToSchema
    • Update assertRequiredParams to skip optional groups
    • Add cross-field validation for edit tool

  • src/agents/pi-tools.create-openclaw-coding-tools.adds-claude-style-aliases-schemas-without-dropping .test.ts:

    • Update test assertion to verify path remains in required

Changed files

  • src/agents/pi-tools.create-openclaw-coding-tools.adds-claude-style-aliases-schemas-without-dropping.test.ts (modified, +3/-1)
  • src/agents/pi-tools.params.ts (modified, +45/-8)
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Summary

All OpenClaw tools with required parameters are failing validation because they receive empty {} arguments instead of the correctly passed parameters. The Gateway appears to be failing to parse parameters before they reach the tool implementation. Example: Sending {"command": "echo test"} to exec tool results in error: Validation failed: command: must have required property 'command'. Received arguments: {}

Steps to reproduce

Steps to reproduce the behavior:

  1. Install OpenClaw: npm install -g [email protected]
  2. Restart gateway: openclaw gateway restart
  3. Attempt to use any tool with required parameters (exec, read, write, sessions_spawn, etc.)
  4. All tools fail with "must have required property" error despite correct parameter syntax

Expected behavior

Tools should receive the correctly passed parameters and execute successfully. For example, exec with {"command": "echo test"} should execute the command.

Actual behavior

All tools receive empty {} arguments, causing validation failures:

ToolError Message
execValidation failed: command: must have required property 'command'. Received arguments: {}
readMissing required parameter: path alias
writeValidation failed: content: must have required property 'content'. Received arguments: {}
editMissing required parameters: path alias, oldText alias, newText alias
sessions_spawnValidation failed: task: must have required property 'task'. Received arguments: {}
web_fetchValidation failed: url: must have required property 'url'. Received arguments: {}
processValidation failed: action: must have required property 'action'. Received arguments: {}

Environment OpenClaw Version: 2026.3.24 (also tested 2026.3.22) OS: Windows 10 Node.js: v24.14.0 Shell: PowerShell Install Method: npm install -g [email protected]

OpenClaw version

2026.3.24

Operating system

Windows 10

Install method

npm install

Model

Kimi code

Provider / routing chain

openclaw -> local-gateway (port 18789) -> kimi-api (anthropic-messages) -> kimi-code

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

Impact: Complete automation blockage - cannot spawn agents, read/write files, execute commands, or fetch web data.

Additional information

Additional context Attempted fixes: Upgrade to 2026.3.24: Partial fix initially (exec worked ~30%), now completely broken Downgrade to 2026.3.22: Same issue persists Multiple gateway restarts: No effect Environment variable fixes: No effect Working tools: Only subagents (read-only) appears functional. Related issues: Possibly related to #47317, #44203, #34810 based on similar parameter validation reports.

extent analysis

Fix Plan

To resolve the issue of OpenClaw tools receiving empty arguments, we need to modify the gateway to correctly parse parameters before they reach the tool implementation.

Here are the steps:

  • Update the openclaw package to the latest version using npm install -g openclaw@latest.
  • Modify the gateway.js file to correctly parse the parameters.
    • Find the line where the parameters are being parsed and update it to use JSON.parse to parse the parameters correctly.
    • Example:

// Before const params = {};

// After const params = JSON.parse(req.body);

* Restart the gateway using `openclaw gateway restart`.
* Test the tools again to see if they are receiving the correct parameters.

### Verification
To verify that the fix worked, try running the `exec` tool with the command `{"command": "echo test"}`. If the fix was successful, the command should execute correctly and print "test" to the console.

### Extra Tips
* Make sure to update the `openclaw` package to the latest version to ensure you have the latest fixes and features.
* If you are still experiencing issues, try checking the `gateway.js` file for any other potential parsing issues.
* You can also try logging the `req.body` to see what is being received by the gateway to help with debugging. 
```javascript
console.log(req.body);

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

Tools should receive the correctly passed parameters and execute successfully. For example, exec with {"command": "echo test"} should execute the command.

#api#vector store#embedding generation#cache error#environment variable

Still need to ship something?

×6

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

Back to top recommendations

TRENDING