InputValidationError: long unicode-escaped tool arguments fail JSON parse (AskUserQuestion) — retry with shorter input succeeds

Note: This report separates what was directly observed in one session from a broader hypothesis based on recurring user experience. They may or may not be the same underlying defect.

---

Part 1 — Directly observed (reproduced this session)

AskUserQuestion was called with a long Korean question whose arguments serialized into many \uXXXX unicode escapes. The call failed with:

InputValidationError: AskUserQuestion was called with input that could not be parsed as JSON.
Common causes: unescaped backslashes ..., unescaped control characters, or truncated output.

A shorter, single retry of the same logical call succeeded. Same intent, shorter/cleaner serialization -> passed.

What is certain from this: the model sometimes emits malformed JSON in the tool-call arguments for long / heavily unicode-escaped inputs, causing a parse/validation failure. This part is reproduced and logged.

What is NOT certain: whether the failure is in argument serialization specifically, vs. the tool-call start token / framing. I cannot distinguish these from the surface error alone.

Part 2 — Hypothesis (recurring across sessions, NOT reproduced here)

Across multiple prior sessions (anecdotal, user-reported), a related-looking failure has been observed where the tool-call start token is emitted as plain text (fragments resembling ordinary words), breaking parsing — and where the error appears to repeat across consecutive turns as if the model imitates its own previous malformed output.

This pattern was NOT reproduced in the current session. It is included only as context in case it correlates with Part 1. Treat it as a hypothesis, not evidence.

Suspected amplifying conditions (correlational, not proven)

• Multiple tool calls in a single message (parallel)
• Long arguments, especially long non-ASCII / unicode-escaped text
• High effort level (xhigh) producing longer outputs
• Large persistent context (large CLAUDE.md, many MCP tools loaded)

Workarounds that empirically reduce frequency

• One tool call per message (serial)
• After a failure, retry once with a shorter/cleaner call (worked in Part 1)
• Lower effort level (xhigh -> high)
• Reduce tool surface area (remove unused MCP connectors)

Environment

• Claude Code: 2.1.181 (WinGet install)
• Model: Opus 4.8 (claude-opus-4-8)
• OS: Windows 11 (10.0.26200)
• Shell: Git Bash (POSIX) + PowerShell 5.1

Ask

Could maintainers confirm whether long unicode-escaped tool arguments are a known cause of InputValidationError JSON parse failures, and whether that is related to the broader start-token framing issue described in Part 2? Happy to capture a fuller transcript next time Part 2 reproduces.