# Codex Angular: practical workflows for Angular developers

URL: https://agentvera.dev/en/blog/codex-for-angular/ · Published: 2026-11-01

Practical guide to using Codex on Angular projects: AGENTS.md setup, prompts for standalone components and services, signals, RxJS, testing, and pitfalls.

**In short:**

- Codex works best in Angular when AGENTS.md defines Angular CLI commands, standalone conventions, signal/RxJS boundaries, and testing rules.
- Give Codex small, testable tasks and have it run focused Angular tests after each change instead of broad refactors.
- Review generated diffs closely around DI, TestBed providers, change detection, and mixed signals and RxJS code.

The [Codex](/en/agents/codex/) coding agent can be a reliable pair programmer for Angular work when you give it clear project rules. Run `codex` in your Angular repository root, point it at an AGENTS.md file, and treat it like a fast junior engineer who needs explicit guardrails. Below is a practical workflow for standalone components, signals, RxJS, DI, and Angular CLI testing.

## Where Codex fits in Angular development

Angular has strong conventions: CLI generators, TypeScript, dependency injection, explicit template bindings, and regular test files. Codex can edit several files at once and run the Angular CLI, so it can create a standalone component, update `app.routes.ts`, adjust a service, and add a TestBed spec in one turn. The key is that AGENTS.md removes guessing. The agent does not have to infer whether you use Jasmine or Jest, where feature folders live, or whether to create an NgModule. Because Angular relies on DI and change detection, Codex often produces syntactically valid code, but you still need to review the diff around providers, signals, and subscriptions. For general Codex CLI behavior, see [How to use Codex CLI](/en/blog/how-to-use-codex-cli/).

## Prepare AGENTS.md for a Codex session

Create `AGENTS.md` in the repository root, next to `angular.json` and `package.json`. Keep it short enough to read in one screen, but explicit. The file should list commands, folder conventions, Angular-specific rules, and testing rules. Update it when your team changes conventions. Example:

```markdown
# AGENTS.md

## Commands
- Install dependencies: npm ci
- Run locally: npm start
- Build: npm run build
- Unit tests: npm run test -- --watch=false
- Run one spec: npm run test -- --watch=false --include=src/app/features/todos/todo.service.spec.ts
- Lint: npm run lint

## Angular conventions
- Standalone components only; do not create NgModules unless the task explicitly requires an Angular module.
- Use signals for component state; use `inject()` instead of constructor injection in new services and components.
- Keep RxJS at the edges: HTTP calls and event buses are streams, component state is signal fields.
- Use OnPush change detection for presentational components.
- Put feature code under `src/app/features/<feature>/`; shared code under `src/app/shared/`.
- One component, service, directive, or pipe per file.
- Unit tests use Jasmine and Angular TestBed; a new component or service must include a spec that mocks external dependencies.
- Do not use `any`; use `unknown` or a defined interface.
- Do not edit generated environment files or generated icon assets unless the task says so.
```

Do not put secrets, long architectural docs, or generated code in AGENTS.md; Codex reads it frequently and a small, current file works best.

## A repeatable Codex loop for Angular changes

Use a loop: plan, small step, run the relevant tests, review the diff. Do not ask for a broad refactor. Start with one component or service, then ask Codex to run a focused spec. After the step, review `git diff` before moving on. Example prompts for common Angular work:

1. Create a standalone `UserProfileComponent` under `src/app/features/user/`. It should use an input for `userId`, inject `UserService`, load the user into a signal, and render name and email. Add a Jasmine spec with a mocked service.
2. The spec `user.service.spec.ts` fails because `HttpClient` is not provided. Update the TestBed setup with `provideHttpClient` and `provideHttpClientTesting` instead of modifying the production service.
3. Convert `selectedFilters` in `ProductListComponent` from a `BehaviorSubject` to a signal. Keep `products$` as an RxJS stream from the server, and expose `filteredProducts` as a computed signal. Run the affected tests.
4. Register the new `AdminOrdersComponent` in `app.routes.ts` as a lazy standalone route. Do not add it to an NgModule.
5. After your last change, run `npm run test -- --watch=false`, then show `git diff --stat` and fix only the failures caused by that change.

## What Codex does well and where it trips in Angular

Codex handles routine Angular changes well, but Angular has specific failure modes that a generic model can miss.

| Task | Good prompt | Watch for |
|------|-------------|-----------|
| Standalone component | Generate a card component with signal inputs and OnPush | Missing imports, wrong selector, missing standalone flag, template type errors |
| Service with DI | Create `OrderService` that injects `HttpClient` and returns a signal | Constructor vs `inject()`, sharing state accidentally, missing `providedIn: 'root'` |
| RxJS to signal | Replace a `BehaviorSubject` with a signal plus computed values | Mixing `observable$` and `signal()` incorrectly, subscriptions in template, missed async cleanup |
| TestBed spec | Make `UserListComponent` spec pass with mocked service | Providing the mock in wrong place, using `NO_ERRORS_SCHEMA` to hide template issues, missing `provideHttpClient` |
| Routing | Add lazy standalone route for admin feature | Wrong `loadComponent`, adding to NgModule, lazy import path mistakes |

Watch closely when Codex touches DI. A generated spec may mock a service but forget to provide it in TestBed, or may use `NO_ERRORS_SCHEMA` to silence template binding errors. Standalone components need explicit imports for `NgIf`, `NgFor`, `AsyncPipe`, and forms modules; Codex can miss those. Signals and RxJS can be mixed incorrectly: a computed signal might read an observable without subscribing, or a subscription might be created in a template expression. Change detection also matters; Codex may not preserve `OnPush` or may add `ChangeDetectorRef` calls unnecessarily. Review every change to `@Injectable`, `inject()`, route config, and test bed providers.

## Keep Angular tests green after Codex edits

After a Codex step, treat the Angular test suite as the source of truth. Ask for focused runs first: `npm run test -- --watch=false --include=...`. Then run lint and a production build. Use `git diff --check` for whitespace issues. If a spec fails, ask Codex to reproduce it locally and print the full error before patching. For larger changes, a second model review is useful: an [AI code review](/en/blog/ai-code-review/) can catch missing `provideHttpClient` in tests, incorrect standalone imports, or an `AsyncPipe` used on a signal. Codex can also add or update specs for the changed behavior; require that instead of leaving existing tests untouched.

## Parallel Codex agents with AgentVera on Angular

For Angular work, the most useful parts of AgentVera are parallel git worktrees, automatic code review, checkpoints, and token budgets. Each Codex session can work in its own worktree, so one can add a standalone feature while another fixes a service spec without overwriting files. When a turn ends, a second model reviews the diff and links findings to file:line, catching missing `provideHttpClient` or mixed signal/RxJS code. Checkpoints let you undo a bad refactor in one click, and token budgets stop a runaway test loop from eating the whole day.

## Final takeaways for Angular Codex use

Codex on Angular is most useful as a constrained loop. Put the CLI commands, paths, and signal/RxJS rules in AGENTS.md, ask for one small change at a time, run relevant tests, and review the diff around DI and templates. The agent speeds up component and spec writing, but you remain responsible for the Angular-specific correctness.

## Frequently asked questions

**How do I use Codex with an Angular project?** Run codex in the root of the Angular repository and keep an AGENTS.md file at the project root. The file should describe Angular CLI commands, folder layout, standalone component rules, and test conventions so the agent does not guess.

**Can Codex generate Angular standalone components and services?** Yes, Codex can generate standalone components, services, directives, and their Jasmine or Jest specs. Give it a concrete prompt that includes the path, inputs, injected dependencies, and expected test setup, then review the result for DI and signal/RxJS boundaries.

**What should I put in AGENTS.md for an Angular project?** Include the exact npm scripts for install, build, test, and lint; where feature and shared code lives; rules such as standalone components only, inject() instead of constructor injection, signals for component state, and no any. Also describe the test framework and TestBed conventions.

**How do I avoid broken tests when Codex changes Angular code?** Ask Codex to run focused tests after every change and to print actual failures. Review the diff around TestBed providers, standalone imports, HttpClient setup, and signal/observable conversions before accepting the change.

---

**About AgentVera.** AgentVera is a desktop app for macOS, Windows and Linux, built by Solviera Teknoloji. It runs 18 AI coding agents (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) side by side, per project, in real terminals with the user's own CLI installs and logins. The free plan has unlimited agents. Download: https://agentvera.dev/en/download/ · Pricing: https://agentvera.dev/en/pricing/