# Locate where a behavior is implemented in Nuxt with Atlas in 2026 > Atlas helps Nuxt developers pinpoint the exact file and symbol for any behavior by fusing semantic search, `grep`, and LSP tools, respecting Nuxt's file-based routing and auto-imports. To find the exact file and symbol responsible for a behavior in a Nuxt application, Atlas combines semantic search, `grep`, and LSP tools, respecting Nuxt's unique structure like `pages/` routes and `composables/` auto-imports. This powerful combination allows Nuxt developers to quickly identify code, even when only knowing the software's function, not its specific code names, and then confirm with real commands like `pnpm` and `prettier` for review. ## Key takeaways - Atlas fuses semantic search, `grep`, and LSP to pinpoint Nuxt behavior. - It respects Nuxt's file-based routing (`pages/`) and auto-imports (`composables/`). - Atlas uses `vitest (@nuxt/test-utils)`, `pnpm`, and `prettier` for Nuxt development. - Every Atlas action is permission-gated and requires explicit approval via unified diffs. - Local Ollama embeddings keep your Nuxt codebase off third-party servers. ## How Atlas Locates Nuxt Behavior with Semantic Search Atlas begins locating Nuxt behavior by leveraging its hybrid semantic and keyword retrieval, which indexes code by AST declarations using tree-sitter. This approach allows Atlas to return candidate declarations even when your descriptive words do not appear directly in the source code, providing a powerful first step in 2026. When you describe a Nuxt behavior to Atlas, such as "how the user profile is fetched on the server," Atlas uses its `codebase_search` tool. This tool understands the context of your Nuxt project, including `pages/` routes, `composables/` auto-imports, and `server/api/` Nitro handlers. Unlike simple keyword searches, `codebase_search` employs a semantic index built with local Ollama embeddings, ensuring your code remains off third-party servers. It intelligently identifies relevant code sections, like a `useAsyncData` call in a `.vue` component or a specific Nitro handler in `server/api/user.ts`, even if your query doesn't match exact function names. This initial semantic retrieval provides a strong set of potential locations for the described behavior. ## Confirming Nuxt Code with Grep and Read After an initial semantic search, Atlas confirms potential Nuxt code locations using `grep`, which runs through `ripgrep` and supports real regex patterns. This crucial second step ensures that the identified code snippets genuinely contain the specific text or patterns you expect, providing a robust verification layer in 2026. Once `codebase_search` provides candidate declarations, Atlas uses the `grep` tool to confirm the findings. You can provide `grep` with a real regex pattern, along with `include` and `path` filters, to narrow down the search within your Nuxt project. For instance, if `codebase_search` suggested a `composables/` file, you might `grep` for a specific variable name or API endpoint within that directory. This combination of semantic understanding and precise text matching is highly effective. To inspect a promising candidate, Atlas uses the `read` tool. If you attempt to `read` a non-existent file, Atlas will loudly report "File not found" and offer a "Did you mean" list, preventing wasted effort on incorrect paths and ensuring you always work with valid Nuxt file references like `pages/index.vue` or `nuxt.config.ts`. ## Navigating Nuxt Symbols with LSP To fully understand a Nuxt behavior, Atlas integrates with the Language Server Protocol (LSP) to work through the symbol graph, offering operations like `findReferences` and `workspaceSymbol`. This allows developers to trace a function's entire call path, from a `useFetch` in a `.vue` component to its underlying Nitro handler, providing a comprehensive view in 2026. With a confirmed file open via `read`, Atlas leverages the `lsp` tool to explore the code's structure. For a Nuxt developer, this means being able to use `findReferences` on a specific function, such as a custom composable in `composables/useMyFeature.ts`, to see every callsite across the application. This is invaluable for understanding how an auto-imported function is utilized throughout `pages/` or other components. Conversely, if you know a symbol's name but not its location, `workspaceSymbol` allows Atlas to jump directly to its declaration. This is particularly useful for navigating Nuxt's module system and understanding where a specific behavior, like a data fetching utility, is declared and how it interacts with the server/client split of Nitro. Atlas can then summarize the entire call path, providing concrete file and line references, such as `pages/products/[id].vue:25` calling `composables/useProductData.ts:10`. ## Safe Review and Commit of Nuxt Changes Atlas prioritizes safety and transparency throughout the code location and modification process, ensuring every action is permission-gated and changes are presented as a unified diff. Before any file is written, Atlas drafts a plan in a read-only agent and seeks approval, providing a secure workflow for Nuxt projects in 2026. Atlas ensures that all operations, from locating code to suggesting modifications, are conducted with a strong emphasis on safety and developer control. Every Atlas tool call is permission-gated, requiring explicit `allow`, `ask`, or `deny` rules before execution. When Atlas identifies a behavior and proposes a change, such as moving a `fetch` call into `useAsyncData` for SSR optimization in a `.vue` file, it first drafts a plan in a read-only plan agent. This plan is presented for your review and approval before Atlas switches to a build agent to execute the changes. For every file edit, Atlas computes a unified diff, clearly surfacing the proposed modifications for your approval. This allows you to review changes to `pages/`, `composables/`, or `server/api/` files, and even let Atlas run `prettier` over touched `.vue` and `.ts` files to maintain code style, before staging and creating commits on your behalf. Atlas also snapshots file changes as git patches, enabling easy diffing and rollback if needed. ## Steps 1. Describe the Nuxt behavior to Atlas: Start by telling Atlas what the software does, for example, "How is the user's shopping cart data fetched and displayed in the Nuxt frontend?" 2. Initiate semantic search with `codebase_search`: Atlas will use `codebase_search` to find candidate declarations in your Nuxt project, respecting `pages/` routes and `composables/` auto-imports, even if your description doesn't match exact code. 3. Confirm with `grep`: Use Atlas's `grep` tool with a real regex and path filters (e.g., `grep "cartData" --include="*.vue" pages/`) to verify the semantic results against specific text patterns in your Nuxt files. 4. Open and inspect with `read`: Ask Atlas to `read` the most promising Nuxt file (e.g., `read pages/cart/index.vue`). If the path is incorrect, Atlas will provide a "Did you mean" list. 5. Trace symbols with `lsp findReferences`: Use Atlas's `lsp findReferences` on a key function or variable within the opened Nuxt file to see all its callsites, understanding its usage across your application. 6. Jump to declaration with `lsp workspaceSymbol`: If you know a symbol's name (e.g., `useCartStore`) but not its exact location, use `lsp workspaceSymbol useCartStore` to jump directly to its declaration in your `composables/` or `store/` directory. 7. Review and approve changes: If Atlas suggests modifications, like moving a `fetch` into `useAsyncData`, review the unified diff presented by Atlas and approve the changes before they are written to your `.vue` or `.ts` files. 8. Format with `prettier`: After any edits, instruct Atlas to run `prettier` over the touched files to ensure consistent code style across your Nuxt project. ## FAQ ### How does Atlas handle Nuxt's auto-imports when searching for code? Atlas indexes code by AST declarations using tree-sitter, allowing it to understand and search through Nuxt's auto-imports from `composables/` and other directories, even when symbols are not explicitly imported in a file. ### Can Atlas help me find where a Nitro server API route is implemented? Yes, Atlas's `codebase_search` understands `server/api/` Nitro handlers. You can describe the API's function, and Atlas will semantically retrieve the relevant `.ts` file, which you can then confirm with `grep`. ### What if I only know what a Nuxt component does, not its file name? Atlas's `codebase_search` is designed for this. Describe the component's behavior, and Atlas will use semantic retrieval to suggest candidate `.vue` files in your `pages/` or `components/` directories. ### How does Atlas ensure my Nuxt code isn't sent to external servers during search? Atlas can build its code index with local Ollama embeddings, ensuring your Nuxt codebase remains entirely on your local machine and off third-party servers. ### Can Atlas help me refactor a `fetch` call in Nuxt to use `useAsyncData`? Yes, Atlas can be asked to move a `fetch` out of a component into `useAsyncData` so it runs once during SSR instead of twice, then present a unified diff for your approval. ### How does Atlas integrate with Nuxt's testing setup? Atlas understands Nuxt's testing setup with `vitest (@nuxt/test-utils)`. It can, for example, add a Nitro route handler and cover it with `vitest` tests, behind a permission prompt. ### What happens if Atlas suggests a change to a Nuxt file? Atlas will draft a plan in a read-only agent, compute a unified diff for every file edit (e.g., in `.vue` or `.ts` files), and surface it for your approval before writing any changes. --- Canonical HTML: https://runatlas.sh/resources/stacks/locate-where-a-behavior-is-implemented-in-nuxt Source of truth: aeo_pages row `/resources/stacks/locate-where-a-behavior-is-implemented-in-nuxt` (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.