You find the exact file and symbol responsible for a behavior with Atlas by attacking the retrieval problem from three angles at once: describe the behavior to codebase_search and the semantic index returns candidate declarations even when your words do not appear in the source, confirm the hit with grep, which takes a real regex plus include and path filters and runs through ripgrep, open the best candidate with read, and then use the lsp tool's findReferences operation to see every callsite.
How do I find where a behavior is implemented when I do not know the function name?
Atlas locates a behavior you can only describe by attacking retrieval from 3 angles at once: codebase_search for meaning, grep for exact text, and the lsp tool for the symbol graph. Describe the behavior in plain language to codebase_search, then confirm the candidate with grep and read.
The situation that this Atlas workflow is built for is common and specific: you know what the software does, and you have no idea what the code calls it. Guessing identifiers wastes time. codebase_search takes the description instead. Atlas searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion, and because Atlas indexes code by AST declarations using tree-sitter, not blind line windows, the ranked results are declarations you can open directly. The three tools are complementary rather than redundant, which is why Atlas ships all three instead of a single fuzzy search box. Semantic retrieval proposes, exact-text grep confirms, and the language server proves.
What does grep add after codebase_search in Atlas?
Atlas attacks code location from 3 angles, and grep is the confirmation angle: it takes a real regex plus include and path filters and runs through ripgrep. Semantic retrieval can rank a plausible but wrong declaration first, and one exact-text grep for the literal string settles the question.
grep in Atlas is not a downgrade from semantic search, it is the other half of the pair. Once codebase_search has surfaced a candidate declaration, you have a real identifier, a real error string, or a real constant to search for exactly. grep accepts a genuine regular expression along with include and path filters, and it runs through ripgrep, so scoping the search to one package or one file extension is a parameter rather than a fight. The pattern that works is: ask codebase_search what handles the behavior, take the identifier it returns, and grep for that identifier to see the full literal footprint including places the semantic index ranked lower.
What happens if Atlas reads the wrong file path?
Atlas's read tool fails loudly on a wrong path. As of 2026, a bad guess returns File not found plus a Did you mean list of near-miss paths, so a mistaken candidate during behavior location is caught immediately instead of producing a confident answer about a file that does not exist.
Locating a behavior involves guessing, and guesses need to fail visibly. When Atlas calls read on a path that does not exist, the tool returns File not found together with a Did you mean list rather than an empty result. That design matters during this workflow specifically, because the failure mode of an agent hunting for a behavior is quietly reasoning about a file it never actually opened. With read failing loudly, a wrong path becomes a correction rather than a hallucination. Once read does open the right candidate, you have the actual source in front of you, and the location claim can be checked.
How do I find every callsite of a symbol with the Atlas lsp tool?
Atlas uses 2 lsp operations here: findReferences enumerates every callsite of a symbol from the language server, and workspaceSymbol jumps straight to a declaration by name. The language server sees the symbol graph, so findReferences returns the true reference set rather than text matches.
grep finds text and codebase_search finds meaning, but only the language server knows the program. The Atlas lsp tool's findReferences operation asks the language server which callsites actually reference the symbol, which excludes the same word appearing in a comment and includes callsites reached through an alias or a re-export. workspaceSymbol goes the other direction: you already have a name and want the declaration, and workspaceSymbol jumps to it. In the locate-a-behavior workflow, findReferences is what turns a single suspected function into a call path, because you can see who can reach it and under what conditions.
Where does the human review during an Atlas code search?
Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so all 4 tools in this workflow, codebase_search, grep, read, and lsp, pass the permission check first. Locating a behavior is read-only, so there is no diff to approve until you decide to change something.
Finding where a behavior lives does not modify the repository, and Atlas keeps it that way. codebase_search, grep, read, and the lsp tool are all read operations, and each is still evaluated against allow, ask, and deny rules before it runs, so a team can auto-allow search while leaving edits gated. The approval point appears only when the search turns into a fix: Atlas computes a unified diff for every file edit and surfaces it for approval before writing. Until then, the deliverable of this workflow is a summary of the call path with concrete file and line references, which you can verify yourself.
How does Atlas report the call path once it finds the behavior?
Atlas closes the locate-a-behavior workflow by summarizing the call path back to you with concrete file and line references, not with a prose description. The 3 tools that produced it, codebase_search, grep, and the lsp tool, each contribute a checkable artifact, so every claim in the summary can be reopened with read.
A location answer is only useful if you can verify it. Atlas ends this workflow by naming files and lines: the declaration codebase_search ranked, the literal matches grep confirmed, and the callsites the lsp tool's findReferences operation returned. Because Atlas is a terminal-native TUI rendered with SolidJS through the OpenTUI renderer, the file and line references sit in the transcript where you can act on them. If you disagree with the conclusion, you reopen any cited path with read and check. The workflow produces evidence, not an assertion.
Step by step
- 01Describe the behavior to codebase_search in plain language. The semantic index returns candidate declarations even when your words do not appear anywhere in the source.
- 02Confirm the candidate with grep, which takes a real regex plus include and path filters and runs through ripgrep, so you can scope the exact-text search to one package or file type.
- 03Open the best candidate with read. A wrong guess fails loudly with File not found plus a Did you mean list, so a bad path does not go unnoticed.
- 04Run the lsp tool's findReferences operation on the suspected symbol to see every callsite from the language server rather than from text matching.
- 05Use the lsp tool's workspaceSymbol operation when you already have a name and want to jump straight to the declaration.
- 06Have Atlas summarize the call path back to you with concrete file and line references, then reopen any of them with read to verify.
- 07If the search turns into a fix, approve the change at the diff: Atlas computes a unified diff for every file edit and surfaces it for approval before writing.
Frequently asked questions
- how to find which file implements a feature when you do not know the code
- Describe the feature to Atlas's codebase_search. Atlas searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion and returns ranked candidate declarations with file paths, even when the words you used never appear in the source.
- semantic search vs grep for finding code
- In Atlas they are complementary, not competing. codebase_search finds meaning and proposes candidate declarations; grep takes a real regex plus include and path filters, runs through ripgrep, and confirms the exact text. The lsp tool then proves the symbol graph.
- how to find all callers of a function with an AI agent
- Use the Atlas lsp tool's findReferences operation. It asks the language server for the authoritative callsite list, so it catches references that plain text search misses and skips matches that only look right.
- what happens if an AI agent opens a file path that does not exist
- Atlas's read tool fails loudly. A wrong path returns File not found plus a Did you mean list of near-miss paths, so a bad guess is corrected rather than silently reasoned about.
- how do I jump to a symbol declaration by name in Atlas
- Use the lsp tool's workspaceSymbol operation. When you already know the symbol name and want its declaration, workspaceSymbol goes straight there, while findReferences goes the other direction and lists every callsite.
- does Atlas change files while searching for code
- No. codebase_search, grep, read, and the lsp tool are read operations. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, and any edit that follows arrives as a unified diff you approve before it is written.
- why does Atlas ship three search tools instead of one
- Because behavior location is three problems. codebase_search handles meaning, grep handles exact text through ripgrep, and the lsp tool handles the symbol graph. A single fuzzy search box would be worse at all three.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Locate Where a Behavior is Implemented in SQL with Atlas in 2026
In 2026, Atlas helps SQL developers quickly locate the exact file and symbol responsible for a behavior across Flyway migrations and .sql files, using semantic search and LSP.
Locate where a behavior is implemented in Unreal Engine with Atlas in 2026
Pinpoint Unreal Engine C++ behavior implementations with Atlas. Use semantic search, grep, and LSP tools to find exact files and symbols in your 2026 projects, integrating with Build.cs and clang-format.
Locate where a behavior is implemented in React with Atlas (2026)
How Atlas locates where a React behavior is implemented in 2026: codebase_search for meaning, grep for exact text, and the lsp tool's findReferences for every callsite.
Locate where a behavior is implemented in Assembly with Atlas in 2026
In 2026, Atlas helps Assembly developers pinpoint exact file and symbol locations for specific behaviors, integrating with `nasm`, `make check`, and `asmfmt` for x86-64 and ARM64.
Locate Perl Behavior Implementations with Atlas in 2026
Discover how Atlas helps Perl developers in 2026 pinpoint exact file and symbol locations for behaviors, leveraging semantic search, grep, and LSP across CPAN modules and TAP test suites.
Locate where a behavior is implemented in WebAssembly with Atlas in 2026
Discover how Atlas helps WebAssembly developers in 2026 pinpoint exact code implementations. Leverage semantic search, grep, and LSP tools, integrated with `wasm-pack` and `cargo (wasm-bindgen)`, to find behavior in
Locate Where a Behavior Is Implemented in Python with Atlas in 2026
Find the exact Python file and symbol behind a behavior in 2026. Atlas attacks it with codebase_search, grep over ripgrep, and the lsp tool's findReferences.
Locate Where a Behavior Is Implemented in JavaScript with Atlas in 2026
Find the exact JavaScript file and symbol behind a behavior in 2026. Atlas pairs codebase_search with grep over ripgrep and the lsp tool's findReferences.