Searching the Codebase

A context window, however large, is finite, and most real codebases are far bigger than what fits in it comfortably. Search is what makes that a non-issue: instead of needing the whole project loaded to find something, Claude Code narrows down to the handful of relevant files first, and only reads those.

Two distinct search tools

Pattern matching by filename (glob-style) answers "which files match this naming pattern" — all the test files, everything under a specific directory, every file with a given extension. It's fast and useful when you already roughly know the shape of what you're looking for.

Content search (grep-style, with full regex support) answers "which files contain this text or pattern" — every call site of a function, every place a specific string appears, every file importing a particular module. This is the workhorse for "where is X actually used" questions that filenames alone can't answer.

Why this beats "just read everything"

Reading an entire large codebase into context on every request would be slow, expensive, and would crowd out room for the actual conversation and the work itself. Searching first means the agent spends its reading budget on the handful of files that are actually relevant to the current task, the same way an experienced engineer joining a new codebase greps for a symbol before opening every file in the repository.

A typical search-then-read pattern

1. Search for where a symbol, string, or pattern appears — this returns file paths and matching lines, not full file contents.
2. Skim the matches to judge which files are actually relevant to the task at hand.
3. Read only those files, in full or in the relevant range, to get the context needed to act.

This pattern repeats constantly throughout a session, often invisibly — a request like "fix the bug where logging in with an expired token doesn't redirect properly" starts with a search for authentication and redirect-related code, not a guess at which file to open first.

When search isn't enough on its own

Search finds where something is; it doesn't tell you why it's structured that way. For anything non-trivial, search narrows the field, and reading the surrounding code (and sometimes its git history) provides the reasoning that file names and grep matches alone can't.

Next: git, the tool that turns a set of edits into a reviewable, shareable change.