Bug type

Regression (worked before, now fails)

Summary

The OpenClaw gateway tool router fails to correctly parse tool call IDs when they have inconsistent formats, causing "Tool not found" errors for read, write, and exec tools.

Steps to reproduce

1. Start a session with the Kimi model
2. Make several tool calls (read, write, exec)
3. After some time or after certain operations (memory compaction), subsequent tool calls fail with "Tool not found"

Expected behavior

Tool calls should work consistently regardless of the toolCallId format.

Actual behavior

Tool calls fail with "Tool not found" when the toolCallId has inconsistent formatting.

Observed toolCallId formats and results:

Root Cause

The gateway's tool router cannot handle inconsistent toolCallId formats. It expects a specific format (with . separator and : index) but the Kimi model sometimes generates toolCallIds without the proper separator.

OpenClaw version

2026.3.2

Operating system

Ubuntu 24.04.4 LTS (GNU/Linux 6.8.0-101-generic x86_64)

Install method

Standard shell script

Logs, screenshots, and evidence

{"type":"message","id":"...","message":{"role":"toolResult","toolCallId":"functionsread3","toolName":"unknown","content":[{"type":"text","text":"Tool  not found"}],"isError":true}}

Impact and severity

Affected: all sessions
Severity: High; replies are being blocked
Frequency: 90%
Consequence: agents cannot respond

Additional information

Workaround

Start a new session using /new in chat or openclaw agent --agent main via CLI.

Suggested Fix

Normalize toolCallId parsing in the gateway to handle multiple formats:

• functions.read:0 (Anthropic format)
• functions.read0 (missing colon)
• functionsread0 (missing separator entirely)

Extract the tool name consistently by removing the "functions." prefix regardless of separator.