Add read_files Tool for Batch File Reading

[teddante]

What problem does this proposed feature solve?

This proposed feature solves the inefficiency and complexity of reading multiple files in AI workflows. Currently, the AI must call read_file repeatedly, which increases tool call overhead, slows down batch operations, and complicates error handling. By introducing a read_files tool, the AI can request multiple files in a single call, improving performance, reducing latency, and simplifying code. This is especially valuable for tasks that require context from many files, such as code analysis, refactoring, or documentation generation.

Describe the proposed solution in detail

Proposed Solution:

Introduce a new read_files tool that enables the AI to read multiple files in a single request, with the following design:

• Input:
  An array of file descriptors, each containing:

  • path (required): Relative path to the file.
  • start_line (optional): 1-based start line for partial reads.
  • end_line (optional): 1-based end line for partial reads.

• Functionality:

  • For each file descriptor, the tool will:
    • Validate access (respecting .rooignore).
    • Support full or partial reads (using start_line/end_line).
    • Truncate large files as per the current read_file logic.
    • Return line-numbered content, notices, and errors in XML format.
    • Handle binary files and errors gracefully.
  • Files are processed in parallel with a concurrency limit for efficiency and safety.
  • The output is a list of <file> XML blocks, one per file, matching the existing read_file output structure.
  • If some files fail, errors are included for those files, but results for other files are still returned.

• Example Usage:

  <read_files>
    <file>
      <path>src/foo.ts</path>
      <start_line>1</start_line>
      <end_line>10</end_line>
    </file>
    <file>
      <path>src/bar.ts</path>
    </file>
  </read_files>

• Integration:

  • The tool will reuse the existing readFileTool logic for consistency and maintainability.
  • It will be registered in the tool registry with clear documentation and usage examples.
  • Unit and integration tests will be added for batch reads, error handling, and edge cases.

This solution is efficient, DRY, and fits naturally into the Roo Code tool architecture.

Technical considerations or implementation details (optional)

Technical considerations and implementation details:

• Reuse Existing Logic:
  Internally invoke the current readFileTool for each file descriptor to ensure consistent handling of truncation, line numbering, .rooignore checks, and error reporting.

• Concurrency:
  Use a concurrency limit (e.g., 5-10 files at a time) to avoid resource exhaustion when reading many files in parallel.

• Input Validation:
  Validate each file descriptor for required fields and check for duplicate paths to prevent redundant reads.

• Error Handling:
  Catch and report errors per file, but do not fail the entire batch if some files are inaccessible or invalid.

• Output Structure:
  Aggregate results as a list of <file> XML blocks, preserving the order of input descriptors.

• Testing:
  Add unit and integration tests for:

  • Batch reads (small and large sets)
  • Partial reads and truncation
  • .rooignore restrictions
  • Error scenarios (missing files, permission denied, binary files)

• Documentation:
  Update tool documentation and usage examples to reflect the new batch capability.

This approach ensures maintainability, performance, and a seamless developer experience.

Describe alternatives considered (if any)

Alternatives considered:

1. Repeatedly calling read_file for each file:
   The AI could issue multiple read_file tool calls in sequence or parallel.

   • Drawbacks: Increases tool call overhead, slows down batch operations, complicates error handling, and makes the workflow less efficient and harder to maintain.

2. Extending read_file to accept multiple paths:
   The existing tool could be modified to accept an array of paths.

   • Drawbacks: Would complicate the interface and break backward compatibility for existing single-file use cases.

3. Using external scripts or commands:
   Batch file reading could be handled by running custom scripts via the execute_command tool.

   • Drawbacks: Less secure, less integrated, inconsistent with Roo Code’s tool architecture, and harder to validate or test.

Why the proposed solution is preferred:
A dedicated read_files tool is native, efficient, DRY, and fits Roo Code’s extensible tool system. It provides a clear, maintainable interface, leverages existing logic, and delivers optimal performance and usability for both AI and developers.

Additional Context & Mockups

Additional Context & Mockups:

• Example XML Usage:

  <read_files>
    <file>
      <path>src/foo.ts</path>
      <start_line>1</start_line>
      <end_line>10</end_line>
    </file>
    <file>
      <path>src/bar.ts</path>
    </file>
  </read_files>

• Example Output:

  <file><path>src/foo.ts</path>
  <content lines="1-10">
  1 | import foo from 'bar'
  2 | // ...
  </content>
  </file>
  <file><path>src/bar.ts</path>
  <content lines="1-50">
  1 | export const bar = () => {}
  </content>
  </file>

• Mermaid Diagram:

  flowchart TD
      A[AI requests read_files] --> B[Parse file descriptors]
      B --> C{For each file}
      C -->|In parallel| D[Call readFileTool logic]
      D --> E[Collect XML result]
      E --> F{All files processed}
      F -->|Yes| G[Return list of <file> XML blocks]
  

  Loading

This context and mockup illustrate the intended interface, output, and integration for the proposed feature.

Proposal Checklist

• I have searched existing Issues and Discussions to ensure this proposal is not a duplicate.
• This proposal is for a specific, actionable change intended for implementation (not a general idea).
• I understand that this proposal requires review and approval before any development work begins.

Are you interested in implementing this feature if approved?

• Yes, I would like to contribute to implementing this feature.

[samhvw8]

@teddante we already have this, but not merge yet, can you test that pr for us ?

#2886

[teddante]

@samhvw8 That would be great! Sorry I didn't spot this