CCAR-F 2.5 — Choosing Claude Code’s built-in tools

Which built-in tool answers this question?

What do you need?

Files matching a name pattern
Globe.g. **/*.test.tsx
Where some text appears
Grepfunction names, errors, imports
What one file says
Readthen follow what it imports
Change or run something
Edit · Write · Bashtargeted edit, new file, command

Glob looks at names and paths; Grep looks inside files. Read and Edit work on one file you already know about.

The six tools and their jobs

Tool	Does	Reach for it when	Permission prompt?
`Glob`	Finds files by path pattern, newest first, up to 100 results	You know the shape of the file name: `src/*/.ts`, `*.{json,yaml}`	No
`Grep`	Searches file contents with ripgrep regex; skips gitignored files	You know text that should be inside: a function name, an error string	No
`Read`	Returns a file with line numbers; also images, PDFs, notebooks	You have a specific file to understand	No, inside the project
`Edit`	Replaces an exact, unique string in a file	A targeted change to an existing file	Yes
`Write`	Creates a file or overwrites it entirely	A new file, or a rewrite of a small one	Yes
`Bash`	Runs a shell command	Tests, builds, git, anything no dedicated tool covers	Yes

Two details decide many answers. Grep’s default output mode is files_with_matches — just paths — which is often all you need to decide what to read next; content adds matching lines with line numbers, and count gives totals. Its glob and type filters narrow a search to, say, **/*.tsx or Python files. Glob, by contrast, never looks inside a file: searching for a function name with Glob can only match file names.

Explore incrementally: search, then read

The costly mistake with an unfamiliar codebase is reading lots of files “to get context”. Every file read lands in the context window, most of it irrelevant, and the details that matter get diluted. Anthropic’s context-engineering guidance describes the better pattern, and names Claude Code as an example: keep lightweight references such as file paths, and pull content in just in time with tools like glob and grep. Each step tells you where to look next.

Tracing a feature through unfamiliar code

Grep for an entry pointroute, command name or error text
Read that filenote what it imports and calls
Grep for each namefind definitions and every caller
Read only what mattersthen make the change

repeat until the flow is understood

Search narrows, reading confirms. Only the files on the path you are tracing ever enter the context window.

Worked example · Where is the refund limit enforced?

A developer at an online retailer asks Claude Code why refunds over $500 are rejected. The repository has about 4,000 files and nobody on the call knows the payments code.

Search for evidence, not files. Grep for 500 would be noise, so Claude greps for the error customers see, “exceeds refund limit”, and gets two files.
Read the first hit. refunds/handler.ts throws the error after calling checkRefundPolicy imported from policy/index.ts.
Follow the wrapper. policy/index.ts only re-exports names from three modules. Claude lists what it exports, then greps for each exported name to see which module really defines checkRefundPolicy and who else calls it.
Read the definition. policy/limits.ts reads MAX_AGENT_REFUND from configuration — the $500 is not in code at all.
Answer, having read four files. The limit lives in configuration, and two other services call the same check, which matters if anyone changes it.

Takeaway: Grep to find the entry point, Read to follow it, Grep again to trace names across modules. Reading everything first would have cost thousands of lines of context and found the same four files.

Changing files: Edit, and when to fall back

Edit is the precise tool: give it an old_string and a new_string, and it replaces that text. Three rules make it safe. The file must have been read in the conversation first — and a read cut short by a partial-view notice does not count (newer models can skip this in some cases). The old_string must match exactly: one character of whitespace or indentation is enough to miss. And it must appear exactly once, unless you set replace_all: true to change every occurrence.

Why did this Edit fail?

Passes: File was read in this conversationa full read, not a partial view
Passes: old_string matches character for characterindentation included
Fails: old_string appears exactly onceappears 3 times in the file
Check: Every occurrence should changeonly then use replace_all: true

The usual culprit is the last two rows: the target text is not unique. Add surrounding lines until it is, or use replace_all only if every copy should change.

When the text is not unique, first give Edit more context — the lines around the one occurrence you mean. If no stretch of text reliably pins it down, fall back to reading the whole file and writing the corrected version with Write. That trades precision for certainty, so keep it for small files or genuinely tangled cases: rewriting a large file risks silently dropping content you did not mean to touch.

An Edit that fails, and two ways outtext

Edit  config.ts
  old_string: timeout: 30
  → error: old_string appears 3 times

Edit  config.ts                    # 1. add context to pin one occurrence
  old_string: payments: {\n    timeout: 30
  new_string: payments: {\n    timeout: 60

# 2. If no unique context exists: Read the whole file, then Write it back
#    with the one change. Check the diff before moving on.

Worked example · Renaming a setting across a service

A hospital scheduling team asks Claude Code to rename the setting slotLength to appointmentMinutes everywhere it appears, and to change the default from 15 to 20 in one place only.

Find every use. Grep for slotLength with output_mode: content lists 14 matches across 9 files, with line numbers.
Rename with confidence. In each file, the rename is intended for every occurrence, so replace_all: true is correct there.
Change the default precisely. The literal 15 appears many times in the config file, so Claude includes the surrounding appointmentMinutes: key in old_string to make the match unique.
Verify with Bash. Claude runs the test suite and Greps once more for slotLength to confirm nothing was missed.

Takeaway: replace_all is right when every copy should change; unique context is right when only one should. Grep before and after tells you which case you are in, and whether you finished.

Traps the wrong answers are built from

Tempting but wrong	Do this instead
Reading every file up front to “build context”	Grep for an entry point, Read it, and follow imports and names outward.
Using Glob to find where a function is called	Use Grep; Glob matches file paths, not contents.
Retrying the same Edit after a non-unique match error	Add surrounding context, use `replace_all` if every copy should change, or Read then Write.
Rewriting a whole large file with Write for a one-line change	Use Edit for targeted changes; keep Write for new files or small rewrites.
Tracing a function only through its wrapper module	List the wrapper’s exported names and Grep for each across the codebase.

You should now be able to

Choose Grep for content search and Glob for path patterns.
Use Read for a specific file and Write for new files or full rewrites.
Make targeted changes with Edit, and recover when old_string is not unique.
Explore an unfamiliar codebase incrementally: search, read, follow imports, search again.
Trace a function across wrapper modules by searching for each exported name.

Choosing Claude Code’s built-in tools