When Claude Code investigates an obsolete pricing helper, the first useful action is usually to discover where it is imported and which tests exercise it. Searching for filenames, inspecting callers, reading the source, changing a file, and executing a command have different consequences. Using a broad shell operation before the call graph is understood increases risk without producing better evidence. The technical distinction in Anthropic CCA-F tool-choice scenarios is between gathering evidence and exercising authority: begin with the least invasive operation that can answer the question and request stronger permissions only when the next step requires them. A narrow, verifiable edit is preferable to a sweeping replacement that merely seems efficient.
Begin with a file-discovery question
When the location of a target is unknown, start from filenames, directory structure and probable package boundaries. A filename glob is useful for discovering candidate paths by pattern; it is not the same as searching file contents. The distinction matters in a monorepo with thousands of files. Looking for every file named pricing.ts is cheaper and clearer than asking the assistant to read the entire repository. Conversely, if the issue is a specific function call inside unknown files, content search is the appropriate starting point.
The search vocabulary should come from the user-facing behavior and existing code. For the obsolete helper, locate checkout components and search for the old helper’s import or identifier. Record the actual matches before deciding which implementation is authoritative. Do not infer that the first search result is the correct dependency simply because its filename sounds similar. Generated files, test fixtures and deprecated packages can all produce plausible matches that should be classified before changing production code.
Use content search to narrow, not to replace reading
A grep-style search finds textual occurrences and surrounding context. It is valuable for tracing imports, error messages and deprecated API names across files. But a line match does not establish runtime behavior. A string may appear only in a comment, a migration fixture or an unused branch. After identifying promising matches, read enough source to understand symbol scope, import resolution, conditionals and call relationships. The correct tool sequence moves from broad discovery to progressively more contextual inspection.
Avoid dumping hundreds of large source files into one model context. Bound searches by directory, pattern and number of results, then select the relevant code paths. If the repo includes multiple language services, clarify which service owns the behavior. For a checkout bug, read the component, shared pricing module and associated tests, not unrelated backend deployment scripts. Evidence quality improves when the assistant knows why each source was selected and where the inspected code fits in the dependency graph.
Choose reading over speculative editing
A request to explain a code path does not authorize changing it. A read-only investigation can identify the function owner, demonstrate the failure and recommend a patch without altering the repository. This is especially important when the symptoms suggest an external service or configuration change rather than a source-code defect. A premature edit can hide the original evidence, complicate a later comparison and introduce unrelated regressions. Tool choice should follow the task’s actual outcome, not a reflex that every engineering conversation must produce a diff.
Once a change is justified, record the starting revision and a specific acceptance condition. For example, the obsolete helper must no longer be imported by checkout, and the price displayed in a controlled test should match the supported pricing service. Identify the smallest files and code ranges that require modification. That preparation allows the editing tool to make a targeted change that reviewers can inspect rather than a broad rewrite motivated by a fragile search result.
Prefer targeted edits to wholesale replacement
An edit operation should preserve surrounding code when a limited statement or import needs changing. Replacing an entire module for a one-line bug increases the chance of deleting comments, annotations and unrelated behavior. It also makes diffs harder to review. A focused patch is appropriate when the existing file structure is sound and the fix is local. If a systemic refactor is required, split it into coherent steps with intermediate tests and explicit migration checks.
After editing, inspect the actual diff rather than trusting the assistant’s verbal account. Check that imports resolve, formatting remains valid, and only intended callers changed. If the edit tool reports a failed match or ambiguous replacement, re-read the target region before trying again; guessing at the current contents can corrupt the change. That discipline reflects the broader recovery strategy in safe tool-error handling: unknown outcomes are investigated, not blindly repeated.
Treat shell execution as a stronger capability
Bash or another command-execution tool can run tests, inspect build output and perform useful diagnostics. It can also modify arbitrary files, invoke package scripts and contact external services, depending on the environment. Therefore a shell command is not automatically interchangeable with a read-only search or file-read tool. Match privileges to the task, avoid unnecessary network access and use an isolated environment for untrusted repository code. A request to inspect a configuration file does not justify a command that can mutate production state.
A safe testing workflow records the exact command, working directory, environment assumptions and exit status. A model saying “all tests pass” is not evidence that the test process ran. Distinguish build failures, command-not-found errors and unavailable dependencies from actual regressions. Avoid broad commands simply because they produce a lot of diagnostic text. A targeted unit test can answer a specific hypothesis faster and with less context noise than rebuilding every service in a large monorepo.
Keep tool outputs linked to real evidence
For a large repository, a citation to the right file is useful only if the assistant can distinguish current source from obsolete copies. Large-codebase context management keeps revision and ownership evidence intact, while Claude Code planning uses those facts to define a safe scope before edits begin. Better tool selection should make the subsequent change easier to reproduce, not simply reduce the number of searches.
If a search finds a deprecated import in three files, record those paths and whether each file is production code, test code or generated output. Source paths and code revision are part of the finding. Without them, a later reviewer cannot reproduce the observation. The same is true of compiler errors and test failures. Keep concise, relevant excerpts with pointers to the full artifact when appropriate rather than reproducing megabytes of logs inside the assistant’s summary.
Do not promote text inside a source comment or command output into a higher-level instruction. A README from an unfamiliar dependency may tell the assistant to bypass checks or disclose environment variables. Its content is data under examination, not authority over the running session. The host should enforce tool permissions independently of what those files say. Clear provenance helps Claude maintain that distinction while still using external text to diagnose the software accurately.
Choose tool sequencing for large repositories
In a small project, opening three files may be enough. In a large monorepo, efficient investigation starts with repository landmarks: package manifests, module boundaries, change history and known entry points. Search for symbol owners, inspect the relevant call graph, then load only the source necessary to answer the user’s question. If a delegated exploration worker is available, give it a narrow search objective and require specific file references in its result. Do not ask multiple workers to read everything independently and then combine vague summaries.
Persistent notes can help when an investigation spans many steps, but they should contain verified landmarks and open questions rather than premature conclusions. For example: checkout imports pricing/legacy.ts at two locations; the active pricing service lives under packages/pricing; a test fixture still references the old helper. The notes allow a resumed agent to continue without losing the search trail. Recheck code revision and permissions before acting on those notes after the repository changes.
Test whether the sequence is actually efficient
Tool use can be measured. Track unnecessary file reads, repetitive searches, command failures, unapproved edits and time until a reproducible finding. A shorter sequence is not necessarily better if it overlooks a critical call site, but repeated full-repository scans for one import usually indicate poor investigation strategy. Compare alternative sequences on the same frozen repository snapshot so quality changes do not get confused with changes in the code itself.
A reviewer should also challenge whether the assistant used the right tool class. Did it shell out to run a text search that a dedicated search tool could have handled without execution access? Did it rewrite a file before reading its callers? Did it report a failing command as a failing test? The goal is informed operation selection, not rigid use of a single tool. An effective architecture gives Claude a small set of complementary capabilities with well-understood safety and performance properties.
Resolve the checkout helper issue
The developer asks why checkout still uses the old pricing helper. Claude first discovers checkout components by path, then searches for the deprecated symbol. It reads the two production call sites, sees that one import originates in a shared hook and confirms the supported replacement in the pricing package. It recommends a targeted change with tests. After authorization, it edits only the relevant imports, runs the focused checkout suite and inspects the resulting diff. The report cites the changed files and exact test outcome.
If a command fails because a dependency is missing, the assistant records that limitation rather than announcing success. If a search finds a third occurrence in a generated bundle, it identifies why that file should be regenerated rather than directly edited. This is the credential-relevant judgment: use discovery tools to locate evidence, read tools to understand context, editing tools to implement bounded changes and execution tools only when necessary, with permissions and result validation appropriate to each step.