Managed k3 stream emits corrupted tool names with literal '?' fragments; engine should validate unknown tool names

[sachnelson]

Summary

Since ~Aug 24, tool calls over managed:kimi-code (k3) intermittently arrive with corrupted names streamed in fragments — e.g. mcp__linear__list_issu?list_issues (a literal ?, 0x3F, mid-name). The engine rejects them (Tool "..." not found), the model retries the identical garbage, and the turn stalls.

This is distinct from #3220's parser defect: there, the client dropped name fragments; here, the bytes arriving from the API are themselves malformed — verified by reassembling the stream with a patched parser and hex-dumping the recorded tool call. The corruption is on the wire, not introduced client-side.

Environment

• kimi 0.36.0 (released Aug 13) and a source build of main @ 41f1eae (0.38.0); Windows 11
• Provider managed:kimi-code, model k3, thinking effort high
• MCP: 8 servers, ~130 tools; failures observed on the Linear http server (55 tools, long shared mcp__linear__ prefix)

Evidence

Session wire (~/.kimi-code/sessions/<wd>/<session>/agents/main/wire.jsonl):

{"type":"tool.call","name":"mcp__linear__list_issu?list_issues","args":{}}
{"type":"tool.call","name":"mcp__linear__get_issu?get_issue","args":{}}

• The ? is a literal 0x3F byte, not a rendering artifact (od hex-dump verified).
• The model's reasoning immediately before one retry read: "Typo in tool name. Use mcp__linear__list_issues." — it then emitted the same corrupted name again. The intent is correct; the serialization is broken.
• First occurrence Aug 24 across all sessions; none in months of prior history on the same client version. Tool calls silently degraded: truncated tool names, dropped arguments, and no-op Bash substitutions #3220 (independent reporter, macOS, 0.38.0) was opened the same day — consistent with a serving-side change around Aug 23–24, not a client regression.
• Matches the vLLM K3 deployment note quoted in Tool calls silently degraded: truncated tool names, dropped arguments, and no-op Bash substitutions #3220: K3 occasionally emits a tool-call format its own parser does not expect.

Why this needs a server-side fix

No client parser can reconstruct intent from bytes that are wrong at the source. The model clearly intends mcp__linear__list_issues; the stream delivers mcp__linear__list_issu?list_issues.

What the client could still do (proposal)

Even with a server fix, the engine currently treats these as ordinary tool results (Tool "..." not found) and burns the step budget until the turn dies. Two complementary guards, aligned with #3220's "Suggested handling":

1. Classify an unknown-tool-name call as a retryable step failure so loopControl.maxAttemptsPerStep engages, instead of silently advancing.
2. Optionally, constrained name recovery: when a name is unknown, sanitize it (split on non-[A-Za-z0-9_]) and rewrite to a catalog tool only on a unique match — exact segment, then _-bounded suffix, then prefix, in that priority. Ambiguous or unmatched names keep the current rejection. In local testing this rescued every corrupted call observed (list_issu?list_issues → list_issues, get_issu?get_issue → get_issue) while correctly rejecting ambiguous truncations (list_issu alone matches 3 catalog tools → rejected).

I have both the #3220 parser patch and this recovery guard implemented with unit tests in a local fork (suites green, typecheck/lint clean) and can contribute either under an /approve. Per the contributing guide, behavior changes are maintainer-gated — so treat this as the discussion issue first.

Reproduction

With a large MCP catalog (Linear's 55-tool http server makes it frequent), start a fresh session and ask the agent to list or review Linear issues. Intermittent — but when it triggers, it repeats within the session. Happy to attach a kimi export debug zip if useful.

[fusengine]

Nothing works I plug in my hook system it degrades even more it has become a joke

[sachnelson]

Follow-up with stronger evidence, including an invisible-character injection.

1. Zero-width BOM injected mid-name. From a 0.38.0 session wire (source build of main @ 41f1eae with a fragment-reassembling parser, so what is recorded is what the stream delivered):

"name":"mcp__linear__list_issu\xEF\xBB\xBFes","args":{"limit":50,"project":"nooey"}

Hex dump of the recorded name: ... 6c 69 73 74 5f 69 73 73 75 ef bb bf 65 73 ... — that is list_issu + U+FEFF (zero-width no-break space) + es. In the TUI this call displayed as a perfectly correct list_issues and still returned Tool "mcp__linear__list_issues" not found, because the catalog key has no invisible byte. This rules out any client-side rendering or parsing explanation: the API stream itself contains the injected character.

2. Arguments arrive intact; only the name is corrupt. Same session: 16 failed calls — list_issu ×12, list_iss ×2, list_issue ×2, plus the BOM variant ×1 — every one with complete, valid arguments ({"limit":50,"project":"nooey"}). A transport or framing problem would corrupt args too. This is emission-level: the model's reasoning text repeatedly states the correct full name while the serialized tool-call name is cut or injected.

3. The corruption is name-family specific. In the latest session, get_workspace, list_teams, and list_projects all succeed while every issue-family name fails (list_issues → list_issu, get_issue → get_issu), consistently, across fresh sessions. Whatever in the serving stack serializes tool calls is choking on a specific token pattern, not randomly.

4. Client-side mitigations we have running locally (fork, all tested): fragment-reassembling parser per #3220, unique-match-only name recovery (exact / _-bounded suffix / prefix) which rescues the ?-suffix and zero-width variants, and a no-effect loop guard that warns on the 2nd consecutive identical call and rejects the 3rd. The remaining unrescuable class client-side is the ambiguous pure truncation (list_issu is a prefix of 3 catalog tools — no safe way to guess). Only a server-side fix addresses that, plus strict/structured tool calling per the vLLM note.

Happy to contribute any of the client pieces under an /approve. Debug zip of the BOM session available on request.

[fusengine]

Even the sub-agents I can't launch them

[HelloWorldU]

I think the root cause is in the managed k3 tool-call serialization path, not the Agent Loop; rejecting an unknown tool and returning the error is correct behavior.
The harness, however, exposes a narrower failure mode: repeated attempts to use the same tool arrive with an unknown name and fail. A per-run monitor could track consecutive unknown-tool results and, after too many repetitions, add a note to the observation that the operation has repeatedly failed and retrying it in the same way may not help.
For such a narrow gap, this mechanism should not have broader effects. The only question is whether this situation could ever be expected, which generally does not seem to be the case. If this direction makes sense to the team, I’d be happy to help with the implementation.