- In short
- In Claude Code, Grep and Glob answer two different questions. Grep searches the text inside files for a pattern, so you use it to find where code or strings live. Glob matches file paths by a naming pattern, so you use it to discover which files exist.
Grep vs Glob: two tools, two different questions
The grep vs glob distinction is the first thing a Claude Certified Architect needs to settle, because almost every codebase task in Claude Code starts by locating something, and there are exactly two ways to locate it. You either search the text that lives inside files, or you search for files by the shape of their path. Grep does the first; Glob does the second. Getting this backwards is the single most common built-in tool mistake the exam probes for.
Think of it as the difference between asking a librarian "which books mention photosynthesis?" and asking "which books are on the second shelf?". The first question is about content, and only reading inside the books answers it. The second is about location, and you answer it from the catalogue without opening anything. Grep reads inside; Glob reads the catalogue.
- Grep vs Glob
- Grep searches file contents for a pattern and returns the lines or files that match. Glob matches file paths against a naming pattern and returns the files whose names fit. Content search versus path search.
What Grep does: searching file contents
Grep is the content-search tool. You hand it a pattern and it scans the text inside your files, returning either the file paths that contain a match, the matching lines themselves, or a count per file. It is built on ripgrep, so the pattern is a ripgrep regular expression rather than a literal string, and metacharacters need escaping. Searching for a Go literal like interface{} means writing the pattern with the braces escaped.
Two behaviours matter for the exam. First, Grep respects .gitignore by default, so generated artefacts and dependencies are skipped unless you point Grep directly at a path. Second, you can narrow the scan with a glob parameter such as **/*.tsx or a type parameter such as py, which keeps the search fast on a large repository. Use Grep whenever the real question is "where in the code does X appear", a function call site, an imported symbol, a thrown error message, a configuration key.
What Glob does: matching file paths
Glob never opens a file. It matches paths against a shell-style pattern and hands back the names that fit, sorted by modification time. The syntax is the familiar one: ** matches any depth of directories, so **/*.test.tsx finds every test file anywhere in the tree, and src/**/*.ts finds TypeScript files under src. Results are capped at a fixed number of files, and Claude is told when that cap is hit so it can tighten the pattern.
The behaviour that surprises people is that Glob does not respect .gitignore by default, so it will list ignored files alongside tracked ones, the opposite of Grep. Use Glob whenever the question is about the set of files itself: find every YAML config, list the migration files, locate the component that matches a naming convention. If you could answer the question by reading only file names, Glob is the tool.
Why picking the wrong one costs you
When the tools are swapped, the failure is rarely a loud error. It is a quiet waste. Ask Grep to "find the test files" by searching for the word test and you get a flood of lines from every file that happens to contain that word in a comment or a variable name, none of which tells you which files are tests. Ask Glob to "find the callers of calculateTax" and it returns nothing useful, because no file is named after the function it calls; the call sites live inside files, and Glob never looks inside.
This is why the distinction is worth memorising rather than reasoning out under time pressure. In an exam scenario the wrong tool will often look superficially plausible, and the only reliable filter is the rule: is this a question about content or about paths? Content routes to Grep, paths route to Glob, and there is no overlap to agonise over.
How Grep and Glob work together
In practice the two tools are partners as often as alternatives. A common pattern is to narrow with Glob and then search with Grep: list the files of interest by path, then scan only those for the pattern you care about. The reverse pairing is just as useful. Grep to find where something lives, then Read to open the handful of files it pointed to. Glob and Grep are the cheap discovery tools that decide what is worth the expensive step of reading a file in full.
Because both return locations rather than whole files, they are also the context-efficient way to navigate a large repository. Each one hands back a short list, paths from Glob, lines or paths from Grep, instead of dumping file bodies into the conversation. That economy is why Claude Code leans on them for exploration and reserves Read for the files those searches have already proven relevant.
Worked example
You join an unfamiliar payments service and are asked: where is the legacy processRefund function defined, and which test files exercise it?
There are two questions hiding in one task, and each maps cleanly to a different tool. The first question, where is processRefund defined, is about content, because a definition is text inside a file. You run Grep for the pattern function processRefund or def processRefund, scoped with a type parameter to the language of the repo. Grep returns the one file and line where the definition lives. Glob could never have answered this: no file is named processRefund, and the definition is buried inside a larger module.
The second question, which test files exercise it, is partly about paths and partly about content, so it takes both tools in sequence. You start with Glob using a pattern like **/*refund*.test.ts to find tests named after the feature, which catches the obvious cases by path. Then you run Grep for processRefund scoped to your test directory to catch the tests that call it without naming it. Glob found the files whose names advertise the feature; Grep found the files whose contents use it. Trying to do either half with the wrong tool would have missed results or buried you in noise, and the whole task resolves in two cheap searches before you read a single file in full.
Common misreadings to avoid
The exam rewards architects who can feel, instantly, which side of the content-versus-path line a task sits on. Both traps below come from blurring that line.
Misconception
To find all the .test.tsx files in a project, I should Grep for .test.tsx.
What's actually true
Misconception
Glob can find everywhere a function is called because it matches patterns.
What's actually true
Grep in depth: output modes and scoping
Grep is more than a yes-or-no content match, and knowing its options is part of using it well. It offers three output modes that change what comes back: the default returns only the file paths that contain a match, a content mode returns the matching lines with their file and line numbers, and a count mode returns how many matches each file holds. Choosing the lighter mode when you only need to know which files match keeps the result small and the context window lean, while the content mode is what you reach for when you need to read the surrounding line.
You also scope Grep to keep it fast and relevant. A glob parameter restricts the search to paths that fit a pattern such as every TSX file, and a type parameter restricts it by language such as Python or Rust. By default a pattern matches within a single line, but a multiline option lets it span line boundaries when the thing you are hunting wraps across lines. Because Grep runs on the ripgrep engine, the pattern is a ripgrep regular expression, so metacharacters need escaping, and the search honours your gitignore file so generated output and dependencies stay out of the results unless you point Grep straight at them.
Glob in depth: patterns and ordering
Glob has its own behaviours worth holding in mind for a scenario question. Its patterns are the familiar shell style, where a double star matches directories at any depth and brace expansion lets a single pattern match several extensions at once. The files it returns come back sorted by modification time, which means the most recently touched files surface first, a small convenience when you are looking for whatever changed last. There is a cap on how many paths it returns, and when the cap is reached Glob flags the truncation so you can narrow the pattern rather than silently miss files.
The behaviour that most often trips people is that Glob does not honour gitignore by default, the opposite of Grep, so it lists ignored files alongside tracked ones unless you change that setting. Holding the two defaults side by side, Grep skipping ignored files and Glob including them, is the kind of precise distinction the exam likes to probe, because it changes which files each tool will surface on the very same repository.
How this shows up on the exam
Domain 2 (Tool Design and MCP Integration) is 18 percent of the exam, and Task Statement 2.5 is the part that tests fluency with the built-in tools. Questions here are almost never "what does Grep stand for". They give you a concrete developer task inside Scenario 4, Developer Productivity with Claude, and ask which built-in tool or sequence resolves it. The distractors are built precisely from the swap, offering Glob for a content search or Grep for a file-discovery task, and they read as plausible to anyone who has not internalised the rule. Settle the one question, content or path, and the correct option separates itself from the noise every time.
A developer asks Claude Code to locate every place the deprecated string 'LEGACY_AUTH_TOKEN' appears so it can be removed before release. Which built-in tool directly answers this, and why?
People also ask
What is the difference between grep and glob in Claude Code?
Does Grep search file names or file contents?
When should I use Glob instead of Grep?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Claude Code Tutorial #4 - Tools & Permissions
Why watch: Directly covers Claude Code's built-in tool set, clarifying when Grep (content search) versus Glob (file-path/name matching) is the right tool - exactly the distinction this KP tests.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.