#Tool Execution Regression — Raw XML Leakage (raw invoke calls)

1 messages · Page 1 of 1 (latest)

quartz iron
#

Symptoms

• Assistant returns raw <function_calls>...</function_calls> blocks as literal text
• Tools are NOT executed; no actual tool calls dispatched
• Response contains malformed XML instead of tool results

Regression Window

• Last known good: Yesterday (2026-03-10), tool execution functional
• First observed: Today (2026-03-11) after OpenClaw upgrade to 2026.3.2
• Frequency: 100% reproduction rate on all tool attempts

Environment

• Runtime: kimi-coding/k2p5 (default model, unchanged from yesterday)
• Channel: Telegram DM (telegram:65617588)
• Streaming config: channels.telegram.streaming: "partial" (active)
• Host: Ubuntu / Linux 6.12.54-Unraid
• OpenClaw version: 2026.3.2 (upgraded today)

Reproduction Steps

  1. User sends any request requiring tool use (e.g., memory_search, exec)
  2. Assistant attempts tool call (visible in thought process)
  3. Output layer returns raw <function_calls>...</function_calls> XML as literal message text
  4. No actual tool execution occurs

Suspected Triggers

• Telegram streaming pathway (streaming: "partial") may be bypassing tool execution parser
• Possible regression in message serialization between model output → dispatcher
• Upgrade artifact: 2026.3.2 vs 2026.2.25 delta

Hypothesis
Streaming transport is capturing raw model output before tool XML gets parsed/handled. When streaming is active, the tool XML is treated as response content rather than executable directives. Not sure if it's the streaming or something in the most recent version.

west cometBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

civic palmBOT
#

This is almost certainly not Telegram streaming.

What you’re seeing (<function_calls>...</function_calls> leaking as literal text + no tool dispatch) is the exact failure mode when kimi-coding stops getting native Anthropic tool framing and falls back to “XML/pseudo tool calls” in plain text.

In fact, main already has an explicit fix note for this:

  • “Models/Kimi Coding: send anthropic-messages tools in native Anthropic format again so kimi-coding stops degrading tool calls into XML/plain-text pseudo invocations instead of real tool_use blocks.” (CHANGELOG: Unreleased; PRs #38669 / #39907 / #40552)
  • There’s also a later changelog fix callout about “restoring tool-call workflows that regressed after v2026.3.2” for Kimi Coding.

What to do right now (workarounds)

  1. Fastest: switch off kimi-coding/k2p5 to an Anthropic/OpenAI model/provider (anything with known-good native tool calling) until you can upgrade.
  2. Pin/downgrade OpenClaw back to the last-known-good (you said 2026.2.25) if you need Kimi specifically.
  3. Upgrade to a build that includes the Kimi tool-framing fix (once the next release is out, or run from main if you’re on-source).

Quick confirmation check

If you paste ~30–60 lines of gateway logs around one failed turn (model request + response), we can confirm it’s hitting the “degrade to XML” path (it usually shows up as tool schema/choice compatibility rewrites).

#

If this isn’t already tracked on GitHub, it’s worth filing an issue with your repro + “2026.3.2 + kimi-coding/k2p5 + tools emit <function_calls> literal” so it’s easy to close the loop when the fix ships: https://github.com/openclaw/openclaw/issues

quartz iron
#

how to revert to 2026.3.2?

civic palmBOT
#

You’re already on 2026.3.2 per your report — did you mean:

  • revert from 2026.3.2 back to 2026.2.25 (last known good), or
  • you tried dev/beta and want to pin back to 2026.3.2?

Either way, rollback/pinning is the same: install the version you want, then restart the gateway.

If you installed OpenClaw globally (npm/pnpm)

Pin to a specific version:

pnpm add -g openclaw@2026.3.2
# or (if you meant the last-known-good)
pnpm add -g openclaw@2026.2.25

Then:

#

Then openclaw gateway restart (unless the updater already restarted it).

If you’re running in Docker/Podman

Pin the container image tag to the version (e.g. 2026.3.2 / 2026.2.25) in your compose/quadlet config and recreate/restart the container.

If you tell me which install method you’re using (global npm/pnpm vs openclaw update git channel vs container), I’ll tailor the exact commands.

quartz iron
#

it seems like my config file is a bit fucked and backups are too recent. what happens exactly if i run openclaw reset?

civic palmBOT
#

openclaw reset is a local wipe of OpenClaw state (it does not uninstall the CLI), and what it removes depends on the scope you pick.

Before doing anything destructive, run:

openclaw reset --dry-run

What it actually does (by scope)

1) --scope config (Config only)

  • Deletes just your config file (openclaw.json at the resolved config path).
  • Does not stop the gateway service first.

2) --scope config+creds+sessions (the common “I want a clean slate” reset)

  • Recommends you run: openclaw backup create
  • Stops the gateway service (if it detects one installed/running)
#
  • Deletes:
    • the config file (openclaw.json)
    • the OAuth/credentials dir (by default: ~/.openclaw/credentials/ containing oauth.json)
    • all agent session stores: ~/.openclaw/agents/*/sessions/ (for every agent)
  • Keeps: the rest of the state dir (logs/caches/etc) and keeps your workspace and “auth profiles” files that live outside the sessions dirs.

3) --scope full (nuke from orbit)

  • Recommends openclaw backup create
  • Stops the gateway service
  • Deletes:
    • the entire state dir (usually ~/.openclaw or ~/.openclaw-<profile>)
    • plus any agent workspace dirs it can infer from config (or the default workspace dir if none is configured)
  • This is the one that can delete your actual “workspace files” if they live in the default/configured workspace path.

After config+creds+sessions or full, it prints the suggested next step: