Choosing Claude Code Built-in Tools: Grep, Glob, Read, Write, Edit

1.Grep searches contents, Glob matches paths

Claude Code has two search tools, and they answer different questions. Grep looks inside files. Use it to find a function name, an error message string, an import statement, or every place a function is called. Glob looks only at file paths. Use it to find files by name or extension, such as every test file matching **/*.test.tsx or every config file under a directory. A useful check: if the answer depends on what is written inside a file, you need Grep. If it depends only on what the file is called or where it lives, you need Glob.

type GrepInput = {
  pattern: string;
  path?: string;
  glob?: string;
  type?: string;
  output_mode?: "content" | "files_with_matches" | "count";
  "-i"?: boolean;
  "-o"?: boolean; // print only the matched parts of each line; requires output_mode: "content"
  "-n"?: boolean;
  "-B"?: number;
  "-A"?: number;
  "-C"?: number;
  context?: number;
  head_limit?: number;
  offset?: number;
  multiline?: boolean;
};

Bash can also search, using shell commands like find or grep. For the exam, though, the preferred answer is the dedicated tool. Grep and Glob are read-only and are built for exactly these jobs. Bash runs arbitrary commands and normally needs permission. When a question can be answered from file names alone, don't read any files: running two Glob patterns and comparing the two lists of results is often all the task needs.

Sources12

2.Read, Write and Edit, and the Read + Write fallback

The three file tools split the work cleanly. Read loads a file's contents. Write creates a file or replaces all of its contents. Edit makes a targeted change: you give it an old_string to find and a new_string to put in its place. That makes Edit the default for small changes to existing files. You don't resend the whole file, and the rest of the file can't be accidentally rewritten.

type FileEditInput = {
  file_path: string;
  old_string: string;
  new_string: string;
  replace_all?: boolean;
};

type FileReadInput = {
  file_path: string;
  offset?: number;
  limit?: number;
  pages?: string;
};

type FileWriteInput = {
  file_path: string;
  content: string;
};

Edit has one weak point: its anchor has to identify exactly one place in the file. If old_string appears more than once, Edit can't tell which occurrence you mean, and the call fails. replace_all only helps if you really want every occurrence changed. Edit also struggles when a change touches many scattered places, such as pulling several separate blocks together into one. In both cases, the reliable fallback is to Read the whole file, build the corrected version, and Write it back in one go. You then control the entire result instead of hoping each anchor matches.

Sources1

3.Build understanding incrementally and trace through wrappers

Reading every file in a codebase up front fills the context window with code that has nothing to do with the task. The better pattern is to narrow down step by step. Start with Grep to find entry points, such as the route handler, the error message the user reported, or the function named in the bug. Then Read those files and follow their imports one step at a time. Each Read should be justified by something a search or a previous Read showed you. Claude Code's own debugging loop follows this pattern: search for the relevant source files, then read them to understand the code.

Wrapper modules complicate this. A utility module might re-export a function under one or more different names, so a Grep for the original name finds only some of the real callers. The fix has two steps. First, Read the wrapper module and list every name it exports for the function, including the original and each alias. Then Grep the codebase for each of those names in turn. Only the combined results give you the full set of callers, which matters most when you're about to change the function's signature.

Sources34

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Glob can find files that mention a function name, because it matches file patterns.Why is that wrong?

   Glob matches file paths and names only. It never looks inside a file. Finding text such as a function name, error message or import requires Grep, which searches file contents.

   Covered in Grep searches contents, Glob matches paths

2. 2.When Edit fails because the anchor text is not unique, set replace_all or retry the same Edit until it works.Why is that wrong?

   replace_all changes every occurrence, not just the one you meant, and retrying an ambiguous anchor fails the same way each time. The reliable fallback is to Read the full file and then Write the corrected contents, because Write replaces the whole file.

   Covered in Read, Write and Edit, and the Read + Write fallback

3. 3.To understand a codebase properly, Claude should Read all the relevant-looking files before doing anything else.Why is that wrong?

   Reading everything up front wastes context. Search first to find entry points, then read only the files the search points to, following imports from there.

   Covered in Build understanding incrementally and trace through wrappers

4. 4.A single Grep for a function's original name finds all of its callers.Why is that wrong?

   Callers that import the function through a re-exported alias never use the original name. List every exported name from the wrapper module first, then run a regex search for each one.

   Covered in Build understanding incrementally and trace through wrappers