`Read` tool rejects an integer `line_offset` with "must be integer" validation error

[KevinShen620]

What version of Kimi Code is running?

0.29.0

Which open platform/subscription were you using?

Kimi Code (OAuth)

Which model were you using?

Qwen3.8 Max Preview

What platform is your computer?

Linux 6.18.33.2-microsoft-standard-WSL2 x86_64 x86_64

What issue are you seeing?

 The `Read` tool rejects a valid integer `line_offset` argument. The agent called `Read` with `{"path": "main.go", "line_offset": 3}` and got:

 Invalid args for tool "Read": /line_offset must be integer; /line_offset must be integer; /line_offset must match a schema in anyOf

What steps can reproduce the bug?

1. Start a Kimi Code CLI session on Linux with the model set to Qwen3.8 Max Preview.
2. Ask the agent: "read *** starting from line 3".
3. The agent issues a Read tool call with arguments: {"path": "main.go", "line_offset": 3}
4. The call is rejected by argument validation before execution.

What is the expected behavior?

line_offset: 3 is a JSON integer and matches the tool schema (anyOf two integer branches: 1..2^53-1 and -1000..-1), so the call should be accepted and return the file content starting from line 3.

Additional information

 - Model: Qwen3.8 Max Preview
 - Kimi Code CLI version:  0.29.0
 - OS: Linux
 - The duplicated "must be integer" messages suggest the value fails both anyOf branches — possibly the value reaches the validator as a non-integer (e.g. string "3" or float 3.0) even though the model emitted an integer literal, or the anyOf

branch errors are reported misleadingly.
- Possibly related to the known issue where Qwen3.8 Max Preview serializes numeric tool parameters as strings.
- Workaround: use Bash tail -n +3 <file> instead of Read.

[HaTin]

Adding some features, such as automatically sending the correct usage parameters to the model after an error, can help the model understand how to use the tool and solve the problem?
添加一些比如报错后，自动向模型发送正确的使用参数，这样有帮助让模型理解工具的使用方法，应该能够解决问题？

[he-yufeng]

Read through the validation path on this one. The tool-call arguments go through a faithful JSON.parse (toolExecutorService.ts parseToolCallArguments, no coercion either way), and then an Ajv check against the tool's input schema, where line_offset is a union of z.number().int().min(1) and the negative tail branch. Ajv's "must be integer" on both branches fires only when the value on the wire is not a JSON number at all, which in practice means the model emitted "line_offset": "3" as a string. That matches the model named in the report: some third party models stringify numeric tool args.

So the validator is behaving correctly here; the tool call really did arrive malformed. The two things that could improve the experience are product decisions rather than a bug fix: coerce numeric strings to numbers for integer typed schema fields (lenient mode for non Kimi models), or surface the raw offending value in the error so users can see the model sent a string. Happy to help with either if the maintainers want one.

[HelloWorldU]

The root cause is on Qwen's side: it sends line_offset as a string, not a number as the schema requires. But since Kimi Code supports third-party models, it should handle this kind of non-conforming output robustly.
A proper patch does two things at the tool-call parse boundary (not in the schema): (1) a downstream normalization layer that safely coerces values that clearly match the schema, and (2) a warning that keeps the upstream schema violation visible instead of silently absorbing it.