- Added processedContent flag to track if content was yielded from candidates
- Only fallback to chunk.text when no content was processed from candidates
- Added comprehensive test cases to verify the fix
- Fixes issue #9822 where responses were being duplicated when both candidates and text properties were present
When tools are called in parallel (e.g., update_todo_list + new_task),
the tool results accumulate in userMessageContent but aren't saved to
API history until all tools complete. When new_task triggers delegation,
the parent is disposed before these pending results are saved, causing
400 errors when the parent resumes (missing tool_result for tool_use).
This fix:
- Adds flushPendingToolResultsToHistory() method in Task.ts that saves
pending userMessageContent to API history
- Calls this method in delegateParentAndOpenChild() before disposing the
parent task
- Safe for both native/XML protocols and sequential/parallel execution
(returns early if there's nothing to flush)
- Import resolveToolProtocol and TOOL_PROTOCOL from @roo-code/types
- Add tools and tool_choice to completion params when native protocol is enabled
- Handle tool_call_partial chunks in streaming response
- Add comprehensive tests for native tool support
* feat: add model-specific tool customization via excludedTools and includedTools
- Add excludedTools and includedTools to ModelInfo schema
- Implement applyModelToolCustomization helper to filter tools based on model config
- Integrate model tool filtering into filterNativeToolsForMode for native protocol
- Add comprehensive tests for tool customization functionality
- Wire up modelInfo through buildNativeToolsArray and Task.ts
This allows providers to override which native tools are available on a per-model basis via MODEL_DEFAULTS, enabling better control over tool selection for models with specific needs.
* feat: add customTools for opt-in only tools
- Add customTools array to ToolGroupConfig for defining opt-in only tools
- Update getToolsForMode() to exclude customTools from default tool set
- Modify applyModelToolCustomization() to include customTools only via includedTools
- Add tests for customTools functionality
- Add comprehensive documentation with usage examples
customTools allows defining tools that are NOT available by default,
even when a mode includes their group. These tools are only available
when explicitly included via a model's includedTools configuration.
This enables:
- Gradual rollout of experimental tools
- Model-specific specialized capabilities
- Safe experimentation without affecting default tool sets
* Add assertions for customTools tests per review feedback
* test: add tests for including customTools via includedTools
* Update src/core/prompts/tools/__tests__/filter-tools-for-mode.spec.ts
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
---------
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
