FileReadTool: Read Files

FileReadTool in Claude Code is not merely a "file reader," but a core runtime component responsible for structured management, context control, and cross-tool collaboration. Through strict reading rules, multimodal support, and snapshot mechanisms, it lays the foundation for subsequent editing operations and security validation, serving as an indispensable observation entry point within the overall toolchain.

Within the architecture of Claude Code, FileReadTool appears superficially to just "read files," but in reality, it undertakes three core responsibilities:

1. Provide the model with a stable entry point for reading project files
2. Structure and track reading results
3. Establish a "read state" for subsequent edits

The third point is the most easily overlooked. Claude Code does not encourage arbitrary file modifications, but strictly emphasizes:

Read first, edit later

And FileReadTool is precisely the starting point of this critical chain. Its design logic is defined very clearly in the source code prompt:

export const DESCRIPTION = 'Read a file from the local filesystem.'

return `Reads a file from the local filesystem.
- The file_path parameter must be an absolute path
- By default, it reads up to 2000 lines
- This tool can only read files, not directories`

Behind these basic rules lies a highly explicit product design intent:

• Paths must be deterministic (mandatory absolute paths)
• Long files have a default upper limit (to prevent context explosion)
• Files and directories are handled separately (preventing the model from confusing "content reading" with "directory traversal")

The existence of FileReadTool breaks the limitations of a traditional "text-based cat". The same prompt file explicitly outlines its support scope:

- This tool allows Claude Code to read images
- This tool can read PDF files (.pdf)
- This tool can read Jupyter notebooks (.ipynb files)

This means that Read serves as a unified multimodal reading entry point in Claude Code. Exactly because of this capability, Claude Code emphasizes in its interaction guidelines:

When the user provides a screenshot path, you must use Read to view it

Although the functional boundary of FileReadTool itself is limited to "reading," it deeply participates in Claude Code's runtime state management. Subsequent writing tools (such as Edit / Write) rely on the context provided by Read for legitimacy checks:

• Has this file been read before?
• What was the timestamp when it was read?
• Has the file changed since then?

Therefore, the true role of Read also includes:

Provide a trustworthy "read snapshot" for subsequent Edit / Write operations

The biggest difference from many coarse-grained Agents lies here: Claude Code explicitly incorporates "*what was read, and when it was read" into the runtime state, thereby preventing erroneous overwrites caused by external file changes or hallucinations.

The source code hardcodes a critical limitation:

export const MAX_LINES_TO_READ = 2000

This is no arbitrary guess, but rather reflects Claude Code's consistent approach of maintaining a balance between information completeness and context efficiency: ensuring the model receives sufficient information without cramming an entire oversized file into the context window in one go.

To this end, it provides a flexible pagination reading mechanism:

• Full file reading by default (truncated to 2,000 lines)
• Supports an offset parameter
• Supports a limit parameter to restrict the number of returned lines

This allows the model to gradually move from a "global rough read" to a "local precise read," loading content on demand.

Within the runtime call chain of Claude Code, Read often plays the bridge role of "from search to understanding." For example, the standard path for fixing a compilation/runtime error:

1. First, use GrepTool to locate suspicious code positions
2. Then, use FileReadTool to read the target file
3. Analyze function logic, contextual dependencies, and adjacent implementations
4. Decide whether to hand it over to FileEditTool for modification

Within the entire tool ecosystem, its collaborative relationship with other components is as follows:

• GlobTool: Locate filenames first, then read content
• GrepTool: Search for keywords first, then read local code blocks
• LSPTool: Perform semantic/symbol localization first, then read the main text context
• FileEditTool: Edit only after reading (relies on the read state)
• BashTool: Verify after modification (completing the loop)

Incorrect. It does more than just display; it directly participates in judging subsequent edit legitimacy and maintaining runtime state.

Quite the opposite. Claude Code explicitly intends: structured reading should go through Read, while shell commands are reserved strictly for scenarios that genuinely require terminal interaction (such as installing dependencies, running tests, cleaning directories, etc.), preventing the abuse of terminal commands within the Agent to handle code content.

Not at all. It undertakes multimodal tasks such as image display, PDF parsing, and Notebook reading, serving as the unified multimodal entry point in Claude Code.

• The core value of FileReadTool lies not in "being able to read files," but in transforming the file comprehension process into a structured, trackable, and formal runtime capability that can participate in write validation.
• Mandatory absolute paths + a default 2,000-line upper limit + the offset/limit pagination mechanism make it the primary gate controlling context window bloat.
• As the unified standard for multimodal reading entry points, it effectively delineates the boundary between "code/document content analysis" and "terminal shell operations."
• Within a complete workflow, Read provides a trustworthy "read snapshot," ensuring that the subsequent Edit/Write toolchain adheres to the security norm of "read first, edit later."
• It is the most important and foundational observation entry point across the entire Claude Code tool ecosystem.