Fix issue where some models used incorrect param format for file/directory handling tools #4099
+227
−28
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context
Some models incorrectly use the wrong XML format for their tool usage.
This behavior is very inconsistent and sometimes they do use the correct format.
This is most commonly experience with the dreaded error: "Kilo Code tried to use
<tool>without value for required parameter 'path'"Issues: #2273, #2347, #2855
Implementation
I found that the issue is due to some models using this format:
This is the correct format for the
read_filetool, but for some reason, some models keep trying to use it for other tools as well.To fix this, I added a parser that specifically checks for the
pathparameter inside theargstag.The parser logic was partly taken from the existing implementation of theread_filetool.This would let Kilo Code parse any model's tool usage format no matter if it's correct or not.
Bonus: In case some models use an even further incorrect XML format, I also added handling for the missing<file>tag inside<args>:xml~~ ~~<[tool_name]>~~ ~~ <args>~~ ~~ <path>.</path>~~ ~~ </args>~~ ~~</[tool_name]>~~ ~~To ensure that existing working functionality is not affected, all tool calls use the default
pathparameter first.Only if it doesn't exist, which would normally result in the tool use error, would the parser be called.
const relPath = params.path || parsePathFromArgsParam(params) || ""I updated the implementation to be able to parse any parameter, not just
path.Usage
But to make it work, I had to use regular string parsing to find the relevant tags instead of XML parsing.
Using a proper XML parser fails due to some params, like diff, that have symbols that XML is not happy with (e.g.
<<<,>>>)Note: I made the parser output
undefinedinstead of an empty string ("") when nopathparams are actually found because some tool implementation checks for bothundefinedand"". Instead of trying to change their logic, I just made the parser outputundefinedand just used|| ""for the tools that need an empty string.Affected tools
apply_diffcodebase_searchdelete_fileedit_fileinsert_contentlist_code_definition_nameslist_filesread_filesearch_fileswrite_to_fileScreenshots
How to Test
Due to the inconsistency of LLMs, this might be difficult to test.
But here's a basic test anyway:
To actually test that my implementation worked, I heavily utilized VSCode's breakpoints feature.

This let me actually know with certainty that the LLM used the "wrong" XML format, and that my fix indeed worked.