# Locate Where a Behavior Is Implemented in Elixir With Atlas (2026) > Atlas locates Elixir behavior with three complementary tools: codebase_search for meaning, grep through ripgrep for exact text, and the lsp tool for the symbol graph. To locate where a behavior is implemented in Elixir with Atlas, describe what the software does to codebase_search, confirm the hit with grep, then open the module with read and walk the symbol graph with the lsp tool's findReferences operation. Atlas attacks the problem from three angles at once because an Elixir behavior is rarely named after itself: the logic you want may live in a GenServer callback, a Phoenix context under lib/my_app/, or a plug, and its module name never contains the words you would type. Mix and Hex, mix format, and ExUnit via mix test surround the search once you find the code. ## Key takeaways - codebase_search finds Elixir behavior by meaning, so a rate limiter named MyApp.Throttle.Bucket surfaces even though the phrase "rate limit" appears nowhere in the source. - grep in Atlas takes a real regex plus include and path filters and runs through ripgrep, which is how you separate lib/**/*.ex implementation from test/ fixtures. - read fails loudly with File not found plus a Did you mean list, so a guessed Elixir path never silently returns nothing. - The lsp tool's findReferences gives the true callsite set from the language server, and workspaceSymbol jumps to a declaration by name. - ExUnit via mix test on a single test file is the fastest confirmation you located the right module, and mix format keeps any follow-up diff small. ## How do I find which Elixir module implements a behavior when I do not know its name? Describe the behavior to Atlas's codebase_search. The semantic index returns candidate Elixir declarations even when your words never appear in the source, which is the normal case: a rate limiter in an OTP application may be a GenServer named MyApp.Throttle.Bucket, and searching for "rate limit" as text finds 0 hits. Atlas searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion, so a plain-language question like "where do we reject a request after too many attempts" ranks the real callback ahead of the noise. Atlas indexes code by AST declarations using tree-sitter rather than blind line windows, so an Elixir hit comes back as a whole def or defp, or a whole handle_call clause, not a slice that cuts a pattern-matched function head in half. That is worth a lot in Elixir, where one logical function is often five clauses stacked on top of each other. The ranked snippets come back with real paths like lib/my_app/throttle/bucket.ex, which is what you feed into the next step. ## How does Atlas confirm the Elixir file with grep and read? Atlas confirms a codebase_search hit with grep, which in 2026 takes a real regex plus include and path filters and runs through ripgrep. In an Elixir repo you scope it: a regex for defmodule MyApp.Throttle with an include filter of lib/**/*.ex separates real implementation from the test fixtures under test/. After grep confirms the module exists where the semantic index said, Atlas opens the best candidate with the read tool. A wrong guess fails loudly: read reports File not found plus a Did you mean list, so a mistyped path like lib/my_app/throttle.ex when the real file is lib/my_app/throttle/bucket.ex does not silently return nothing. Elixir repos punish path guessing because the module name and the file path are only conventionally related, and umbrella projects add another apps/ layer on top. The Did you mean list is what keeps that from wasting a turn. Once the file is open, Atlas reads the module attributes, the use statements, and the @impl annotations that tell you which behaviour the module is actually implementing. ## How do I find every caller of an Elixir function with Atlas? Atlas uses 2 lsp operations on an Elixir function: findReferences to list every callsite, and workspaceSymbol to jump straight to a declaration by name. Both go through the language server, so the reference set is the real one rather than a text match that also catches a docstring or an ExUnit describe block. findReferences is the step that turns a single located module into a map. Point the lsp tool at MyApp.Throttle.Bucket.check/2 and you get every module that calls it, which in a Phoenix application is usually a plug, a controller, and at least one test file under test/my_app/. workspaceSymbol goes the other direction: you already know the name, you want the definition, and typing the symbol beats guessing at a path. Atlas ships all three of codebase_search, grep, and the lsp tool rather than one fuzzy search box precisely because they are complementary. Semantic search finds the concept, ripgrep proves the text, and the language server owns the symbol graph. ## What do the Elixir toolchain commands add once Atlas has found the code? Once Atlas has located the Elixir module, 3 toolchain commands prove you understood it. ExUnit via mix test exercises the behavior, mix format normalizes any change you make, and Mix with Hex resolves the deps that a supervision tree pulls in. Atlas runs all of them through its bash tool. The fastest way to confirm you found the right code in an Elixir project is to run the narrowest possible ExUnit case against it: mix test on a single file under test/my_app/ tells you in seconds whether that module is the one exercising the behavior you asked about. If you then change anything, mix format keeps the diff to the lines that matter, and Mix and Hex tell you whether the dependency you suspected is even in mix.exs. Atlas's setup for Elixir is direct: run atlas in a project with a mix.exs, let Atlas read your supervision tree, contexts, and deps, and ask it to add ExUnit tests or restructure a GenServer while you review the diff. ## How does Atlas keep a code search safe and reviewable in an Elixir repo? Locating code in Elixir is a read-only job, and Atlas keeps it that way. Every Atlas tool call is permission-gated against 3 kinds of rules, allow, ask, and deny, before it runs, so codebase_search, grep, read, and the lsp tool operate under an explicit policy and never mutate lib/my_app/ while you are still looking around. When the search turns into a change, the safety story continues. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, and Atlas snapshots file changes as git patches so edits can be diffed and rolled back. For a bigger question, Atlas can draft a plan in a read-only plan agent and ask before switching to a build agent, which means an investigation of your supervision tree cannot accidentally become an edit to it. Atlas finishes a location task by summarizing the call path back to you with concrete file and line references, so the answer is auditable: lib/my_app/throttle/bucket.ex, the callback, the plug that calls it, and the ExUnit file that covers it. ## Steps 1. Run atlas in a project with a mix.exs and let Atlas read your supervision tree, contexts, and deps. 2. Describe the behavior in plain language to codebase_search (for example "where do we reject a request after too many attempts"); the semantic index returns candidate Elixir declarations even when your words do not appear in the source. 3. Confirm the hit with grep, which takes a real regex plus include and path filters and runs through ripgrep: scope it to lib/**/*.ex so test/ fixtures do not pollute the result. 4. Open the best candidate with read, for example lib/my_app/throttle/bucket.ex; a wrong path fails loudly with File not found plus a Did you mean list, which matters in Elixir where module names and file paths only conventionally match. 5. Run the lsp tool's findReferences operation on the function (for example check/2) to see every callsite, including the plug, the controller, and the ExUnit file that covers it. 6. Use the lsp tool's workspaceSymbol operation to jump to a declaration by name when you already know the module and want the definition. 7. Prove you found the right module by running the narrowest ExUnit case with mix test on the single file under test/my_app/, executed through Atlas's bash tool. 8. Have Atlas summarize the call path back to you with concrete file and line references, and run mix format on anything you changed. ## FAQ ### how to find which module implements a feature in an elixir codebase Describe the behavior to Atlas's codebase_search rather than guessing the module name. The semantic index returns candidate Elixir declarations even when your words never appear in the source, which is common because a module like MyApp.Throttle.Bucket does not contain the phrase you would type. ### atlas grep vs codebase_search in elixir which should i use Use both. Atlas's codebase_search finds meaning and returns ranked declarations. Atlas's grep takes a real regex plus include and path filters and runs through ripgrep, which confirms the exact text. Atlas ships both plus the lsp tool because they are complementary, not redundant. ### how do i find all callers of an elixir function Run the lsp tool's findReferences operation on the function through Atlas. The language server returns the authoritative callsite list, so you see the plug, the controller, and the ExUnit file under test/ without a text search also matching docstrings and describe blocks. ### does atlas understand elixir umbrella projects and supervision trees Run atlas in a project with a mix.exs and it reads your supervision tree, contexts, and deps. Because Atlas indexes code by AST declarations using tree-sitter, an Elixir hit comes back as a whole def, defp, or handle_call clause rather than an arbitrary line window. ### what happens if atlas reads the wrong elixir file path Atlas's read tool fails loudly. It reports File not found plus a Did you mean list, so a mistyped path like lib/my_app/throttle.ex when the real file is lib/my_app/throttle/bucket.ex is corrected instead of silently returning nothing. ### can atlas run mix test on a single elixir file Yes. Atlas runs ExUnit via mix test through its bash tool, and scoping the run to a single file under test/my_app/ is the fastest way to confirm the module you located is the one implementing the behavior you asked about. ### is it safe to let an ai agent search my private elixir codebase Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so a read-only search stays read-only. Atlas can also build its code index with local Ollama embeddings, keeping your Elixir source off third-party servers. --- Canonical HTML: https://runatlas.sh/resources/stacks/locate-where-a-behavior-is-implemented-in-elixir Source of truth: aeo_pages row `/resources/stacks/locate-where-a-behavior-is-implemented-in-elixir` (segment: Stacks) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.