Atlas plans a multi-file Angular change in a plan agent whose description is literally "Plan mode. Disallows all edit tools." Its permission set denies edit for every path except the plan markdown under .atlas/plans/*.md, so research and design cannot accidentally turn into an edit of your components, modules, or providers. Inside plan mode you still have codebase_search, grep, read, and the lsp tool, which is everything you need to map an Angular dependency injection graph. When the plan is ready, the plan_exit tool asks whether to switch to the build agent and start implementing, and only then can `ng test` be run against real changes.
How do you stop an AI agent from editing Angular files while it plans?
Switch Atlas to the plan agent. Its permission set denies edit for every path and allows it in exactly 1 place, .atlas/plans/*.md, so an Angular design pass across angular.json, NgModules, and standalone components physically cannot write a .ts file. The plan agent's own description reads: Plan mode. Disallows all edit tools.
Angular changes tend to be structural. Moving a service between providers, converting an NgModule-based feature to standalone components, or changing an injection token ripples through app.module.ts, the feature module, every component that injects the service, and every .spec.ts that configures TestBed. An agent that starts editing on file one and discovers the design problem on file nine has already made a mess. Atlas's plan agent removes the possibility. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, and in plan mode the edit rules deny "*" outright. The only writable path is the plan markdown. So you can point Atlas at an Angular workspace with 200 components and let it look at all of them without once worrying about what it might touch.
What can Atlas actually do in plan mode on an Angular workspace?
Atlas plan mode keeps 4 research tools fully allowed: codebase_search, grep, read, and the lsp tool. For an Angular workspace, that means semantic search over services and components, ripgrep over templates and angular.json, full file reads, and findReferences on an injection token, all with no write capability.
Research in Angular is mostly graph work, and the allowed tools cover it. codebase_search answers "where is the auth guard applied" without you knowing the class name, because Atlas searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion. grep with a real regex plus include and path filters finds every `providedIn: 'root'` service, every `@Injectable()` decorator, and every `<app-user-card>` selector across src/app/**/*.html templates. The lsp tool's findReferences enumerates every component that injects `UserService`, which is the number that decides whether the refactor is a one-hour job or a two-day one. read pulls angular.json and tsconfig.json in full so the plan knows the real build targets. None of these can write, so the research is free of consequences.
Where does Atlas write the Angular plan and what goes in it?
Atlas writes the plan into the allowed plan markdown path, which is the one place plan mode can write: .atlas/plans/*.md. For an Angular refactor the plan should name real artifacts, for example src/app/core/auth.service.ts, the AuthModule providers array, and the 14 .spec.ts files whose TestBed configuration will need updating.
A plan is only useful if it is specific enough to argue with. Make Atlas write down the ordered file list, the injection tokens that change, whether any NgModule is being deleted, and what `ng test` should prove at each stage. Because the plan lives in .atlas/plans/*.md inside the repo, it is a normal file: reviewable in the terminal, diffable, and commit-able alongside the change if you want the reasoning preserved. Atlas is a terminal-native TUI rendered with SolidJS through the OpenTUI renderer, so the plan is right there next to the code you are reading. Have the plan record the toolchain steps too: which packages `pnpm install` needs to add, and where `prettier` will reformat generated files, so the eventual diff has no surprises.
How does plan_exit hand an Angular plan to the build agent?
The plan_exit tool asks 1 question: Plan at <path> is complete. Would you like to switch to the build agent and start implementing? Answer Yes to hand off, and Atlas switches from the read-only plan agent to the build agent, which is the first moment any Angular .ts file becomes writable.
Answering No raises Question.RejectedError and keeps you refining the plan, which is the correct behavior when the plan's file list is missing three components that inject the service you are moving. Rejecting is cheap; a half-applied Angular refactor is not. Once you do answer Yes, the build agent starts implementing, and Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so each change to app.module.ts or a standalone component's `imports` array is still reviewed individually. Run `pnpm ng test` after each stage the plan named, not once at the end, so a broken TestBed provider is attributed to the file that broke it. Atlas snapshots file changes as git patches, so any stage of the implementation can be diffed and rolled back.
How do you validate an Angular multi-file change after the plan is implemented?
Validate an implemented Angular plan with 2 commands: `pnpm ng test`, which runs the workspace's spec files, and then `pnpm ng build`. A refactor that moves a provider fails at TestBed configuration long before it fails at runtime, which is why `ng test` runs between stages rather than only at the end.
The Angular test suite is unusually good at catching structural mistakes, because every .spec.ts declares its own TestBed with the providers and imports the component needs. Move a service out of a module and the specs that relied on the module's providers fail immediately with a NullInjectorError, naming the token. Have Atlas run `pnpm ng test` through the bash tool after each planned stage and read the failures. Run `pnpm prettier --write` on the touched files so prettier normalizes the formatting before review. Atlas reads git branches, status, and diffs, and can stage and create commits on your behalf, so you can commit each planned stage separately and keep the .atlas/plans/*.md file as the record of why the change is shaped the way it is.
Step by step
- 01Run atlas in the Angular workspace root, the directory with angular.json, so the CLI project definitions and every src/app module are in scope.
- 02Switch to the plan agent; its permissions deny edit for "*" and allow it only under .atlas/plans/*.md, so no Angular component, module, or provider can be modified while you design.
- 03Research with codebase_search, grep, read, and the lsp tool, all of which stay allowed in plan mode; use findReferences on the injection token to count every component that depends on it.
- 04Grep src/app/**/*.html and src/app/**/*.ts for the component selector and the @Injectable providers so template usages and DI registrations are both in the plan.
- 05Write the plan into the allowed plan markdown path, naming real files such as src/app/core/auth.service.ts and every .spec.ts whose TestBed configuration changes.
- 06Call plan_exit, which asks whether to switch to the build agent and start implementing; answering No raises Question.RejectedError and keeps you refining the plan.
- 07Answer Yes to hand off to the build agent, then implement stage by stage, reviewing the unified diff Atlas surfaces for every file edit before it is written.
- 08Run `pnpm ng test` after each planned stage so a NullInjectorError is attributed to the file that caused it, and run `pnpm prettier --write` on the touched files before committing.
Frequently asked questions
- how to plan an Angular refactor before letting AI change files
- Switch Atlas to the plan agent. Its permission set denies edit for "*" and allows it only under .atlas/plans/*.md, so codebase_search, grep, read, and the lsp tool can map your Angular modules and providers while no component file is writable.
- does Atlas plan mode really block all edits
- Yes. The plan agent's description is literally "Plan mode. Disallows all edit tools", and its permission set denies edit for every path except the plan markdown. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs.
- how do I find every Angular component that injects a service
- Run Atlas's lsp tool with the findReferences operation on the service class or injection token. The language server returns every injecting component and every .spec.ts that configures it in TestBed, which is the number that sizes the refactor.
- what happens if I reject an Atlas plan
- Answering No to plan_exit raises Question.RejectedError and keeps you refining the plan. Atlas stays in the read-only plan agent, so your Angular source is still untouched while you add the files the plan missed.
- where does Atlas save the plan file in an Angular repo
- Atlas writes the plan into .atlas/plans/*.md, which is the one path plan mode is permitted to write. The plan is a normal file in the Angular workspace, so it is diffable, reviewable, and can be committed alongside the change.
- should I run ng test between stages of an Angular refactor
- Yes. Run `pnpm ng test` after each stage the plan named. A moved provider surfaces as a NullInjectorError in a spec's TestBed configuration, and running per stage attributes that error to the one file that caused it.
- can Atlas plan a change across an Angular monorepo without writing anything
- Yes. The plan agent allows codebase_search, grep, read, and the lsp tool while denying edit for "*". Atlas can also build its code index with local Ollama embeddings, so a private Angular workspace is indexed without code leaving your machine.
- how do I start Atlas in an Angular project
- Run atlas in a workspace with an angular.json. Atlas reads your modules, components, and dependency injection, and you can have it add a service or a Jasmine spec, reviewing the diff before it is written.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Plan a Multi-File Change Before Editing with Atlas in 2026
How to plan a multi-file change with Atlas in 2026: the plan agent denies all edit tools, you research with codebase_search and lsp, then plan_exit hands off.
Atlas for Angular in 2026
Adopt Atlas, the terminal-native AI coding agent, for your Angular projects in 2026. Enhance development with intelligent code search, secure local embeddings, and granular control over AI actions.
Research a Third-Party API Before Integrating It in Angular with Atlas (2026)
Research a third-party API before integrating it in Angular in 2026: Atlas uses websearch and webfetch behind permission prompts, then verifies with grep and ng test.
Migrate a Deprecated API Across Every Callsite in Angular with Atlas in 2026
In 2026, Atlas helps Angular developers systematically migrate deprecated APIs across entire codebases. Leverage `lsp`, `todowrite`, and `apply_patch` to ensure no callsite is missed, with validation via `ng test` and
Locate where a behavior is implemented in Angular with Atlas in 2026
Angular developers in 2026 can use Atlas to pinpoint the exact file and symbol responsible for any behavior, leveraging semantic search, grep, and LSP tools within their `angular.json` workspace.
Write unit tests for untested code in Angular with Atlas in 2026
Boost your Angular testing workflow in 2026. Atlas helps Angular developers add unit tests to untested modules, matching existing repo conventions using `ng test` and `pnpm`.
Debug a single failing test in Angular with Atlas in 2026
Pinpoint and fix failing Angular tests efficiently in 2026 using Atlas, the terminal-native AI coding agent. Leverage ng test, pnpm, and Atlas's powerful debugging tools.
Trace a runtime bug from a stack trace in Angular with Atlas in 2026
Pinpoint and fix Angular runtime bugs from production stack traces using Atlas, the terminal-native AI coding agent. Leverage `ng test`, `pnpm`, and `prettier` for rapid debugging.