* Improve read_file tool description with examples
- Add explicit JSON structure documentation
- Include three concrete examples (single file, with line ranges, multiple files)
- Clarify that 'path' is required and 'line_ranges' is optional
- Better explain line range format (1-based inclusive)
This addresses agent confusion by providing clear examples similar to the XML tool definition.
* Make read_file tool dynamic based on partialReadsEnabled setting
- Convert read_file from static export to createReadFileTool() factory function
- Add getNativeTools() function that accepts partialReadsEnabled parameter
- Create buildNativeToolsArray() helper to encapsulate tool building logic
- Update Task.ts to build native tools dynamically using maxReadFileLine setting
- When partialReadsEnabled is false, line_ranges parameter is excluded from schema
- Examples and descriptions adjust based on whether line ranges are supported
This matches the behavior of the XML tool definition which dynamically adjusts
its documentation based on settings, reducing confusion for agents.
* Add a RCC credit balance display
* Replace the provider docs with the balance when logged in
* PR feedback
---------
Co-authored-by: Matt Rubens <mrubens@users.noreply.github.com>
* fix: Include nativeArgs in tool repetition detection
Fixes false positive 'stuck in a loop' error for native protocol tools
like read_file that store parameters in nativeArgs instead of params.
Previously, the ToolRepetitionDetector only compared the params object,
which was empty for native protocol tools. This caused all read_file
calls to appear identical, triggering false loop detection even when
reading different files.
Changes:
- Updated serializeToolUse() to include nativeArgs in comparison
- Added comprehensive tests for native protocol scenarios
- Maintains backward compatibility with XML protocol tools
Closes: Issue reported in Discord about read_file loop detection
* Try to use safe-stable-stringify in the tool repetition detector
---------
Co-authored-by: Matt Rubens <mrubens@users.noreply.github.com>
* Add native tool calling support to OpenAI-compatible
* Fix OpenAI strict mode schema validation by adding converter methods to BaseProvider
- Add convertToolsForOpenAI() and convertToolSchemaForOpenAI() methods to BaseProvider
- These methods ensure all properties are in required array and convert nullable types
- Remove line_ranges from required array in read_file tool (converter handles it)
- Update OpenAiHandler and BaseOpenAiCompatibleProvider to use helper methods
- Eliminates code duplication across multiple tool usage sites
- Fixes: OpenAI completion error: 400 Invalid schema for function 'read_file'
---------
Co-authored-by: daniel-lxs <ricciodaniel98@gmail.com>
* fix: format tool responses for native protocol
- Add toolResultFormatting utilities for protocol detection
- ReadFileTool now builds both XML and native formats
- Native format returns clean, readable text without XML tags
- Legacy conversation history conversion is protocol-aware
- All tests passing (55 total)
* refactor: use isNativeProtocol from @roo-code/types
Remove duplicate implementation and import from types package instead
* refactor: centralize toolProtocol configuration checks
- Created src/utils/toolProtocol.ts with getToolProtocolFromSettings() utility
- Replaced all direct vscode.workspace.getConfiguration() calls with centralized utility
- Updated 6 files to use the new utility function
- All tests pass and TypeScript compilation succeeds
* refactor: use isNativeProtocol function from types package
When read_file encountered errors (e.g., file not found), it would call
handleError() which internally calls pushToolResult(), then continue to
call pushToolResult() again with the final XML. In native protocol mode,
this created two tool_result blocks with the same tool_call_id, causing
400 errors on subsequent API calls.
This fix replaces handleError() with task.say() for error notifications.
The agent still receives error details through the XML in the single
final pushToolResult() call.
This change works for both protocols:
- Native: Only one tool_result per tool_call_id (fixes duplicate issue)
- XML: Only one text block with complete XML (cleaner than before)
Agent visibility preserved: Errors are included in the XML response
sent to the agent via pushToolResult().
Tests: All 44 tests passing. Updated test to verify say() is called.
The OpenAI tool schema required both 'path' and 'line_ranges' in FileEntry,
but the TypeScript type definition marks lineRanges as optional. This caused
the AI to fail when trying to read files without specifying line_ranges.
Changes:
- Updated read_file tool schema to only require 'path' parameter
- line_ranges remains available but optional, matching TypeScript types
- Aligns with implementation which treats lineRanges as optional throughout
Fixes issue where read_file tool kept failing with missing parameters.