Reasonix写代码的时候工具污染了有没有大佬看看怎么解决

[chengci582]

Reasonix 工具框架的 XML 参数解析器 有 bug：

症状：
每次调用工具（run_command、read_file、list_directory 等），最后一个参数的值末尾会被拼上 这个标签字符串。

例如：

run_command("echo hello")
→ 实际传给 shell 的是 "echo hello"

read_file("file.txt")
→ 实际打开的是 "file.txt"
唯一不受影响的是 glob — 说明它的参数解析路径不一样。

原因推测：
解析工具调用的 XML 时，遍历参数节点拼装参数值，处理最后一个节点时没有正确截断 </关闭标签>，把标签文本也当成了参数值的一部分。

[esengine]

Tried to reproduce this against current main and can't — the DSML parser uses a lazy capture ([\s\S]*?) that stops at the first </｜DSML｜parameter>, so the close tag never leaks into the value. I ran a probe test with the exact run_command("echo hello") shape from your report and got args.cmd === "echo hello" cleanly, no </parameter> suffix.

Also grepped the whole codebase: Reasonix only has the DSML scavenger (full-width <｜DSML｜parameter> markers) — there is no plain <parameter> parser anywhere. Runtime tool dispatch goes through the standard OpenAI tool_calls JSON field; the DSML scavenge is only a fallback for when the model emits markup into reasoning_content instead of using tool_calls.

So what you're seeing is most likely one of:

1. Model-side bug: the model literally put </parameter> inside the JSON string of tool_calls[].function.arguments. Reasonix passes that through verbatim by design — the fix would be on the model / provider side.
2. Different build: a fork or older release that had its own buggy XML parser.

To narrow it down, could you share:

• reasonix --version (or desktop version)
• Which model / provider
• A raw --transcript chunk showing one of the polluted tool calls — specifically the tool_calls array as it came back from the API (not the rendered CLI output)

That'll let me confirm whether the close tag is coming from the model's response or from somewhere in our path.

[chengci582]

0.52.0，我复查了一下应该是我这边的问题，但是我确定不了问题到底出在哪，他是说工具框架坏了给污染了，还在排查到底是哪出的问题，但是可以用colaude来当他的手。