Codex .NET: practical guide for C# developers

Codex is a command line coding agent from OpenAI. To use it on a .NET project, open a terminal in the repository root and run codex. The agent reads AGENTS.md for project instructions, so the first real step is making that file specific to your C# stack. This guide covers setup, AGENTS.md content, a practical working loop, testing, and multi-agent use for ASP.NET Core, EF Core, xUnit/NUnit, and dotnet CLI.

Why Codex fits C# and .NET development

.NET gives Codex a predictable surface. The dotnet CLI centralizes restore, build, test, format, and migration commands, and the compiler emits file/line/severity diagnostics that the agent can act on. Project files are XML, so Codex can add package references or project references without guessing. ASP.NET Core has strong conventions around dependency injection, middleware, and minimal APIs, which means the agent often generates idiomatic code on the first pass. EF Core migrations and DbContext setup are also well represented in training data, but they need explicit rules, which the next section covers.

If you are new to the CLI, the How to use Codex CLI guide covers starting a session and basic interaction, but this article focuses on .NET-specific setup.

Preparing a .NET solution for Codex

The most important file is AGENTS.md at the solution root. It should tell Codex exactly how to build, test, lint, and where the projects live. Keep it short enough that the agent reads it every turn. A realistic example for a solution with src/ and tests/ folders:

# AGENTS.md for .NET

## Commands
- Restore: `dotnet restore`
- Build: `dotnet build --no-restore`
- Test: `dotnet test --no-build --logger console;verbosity=normal`
- Lint/format check: `dotnet format --verify-no-changes`

## Project layout
- Solution file at root: `MyApp.sln`
- Source projects under `src/`
- Test projects under `tests/`
- Use file-scoped namespaces and nullable enable.

## Conventions
- Use C# 12, enable nullable and implicit usings.
- Use ASP.NET Core minimal APIs for new endpoints.
- Use EF Core migrations; run `dotnet ef migrations add` before editing model classes.
- Do not run `dotnet ef database update` unless explicitly asked.
- Use xUnit for tests; one test class per production class.
- Never modify generated migration files manually.

## Rules
- Run `dotnet test` after any code change.
- Do not change target frameworks in csproj without asking.
- Keep async all the way down; avoid `.Result` and `.Wait()`.
- Do not add NuGet packages unless requested.

This file prevents the most common .NET agent failures: running the wrong test project, adding unnecessary packages, or trying to apply migrations without review. Keep it in version control and update it when the solution layout changes.

The working loop: plan, code, test, review

Use small, test-first tasks and review the diff before letting the agent continue. A practical loop:

1. Open codex in the solution root.
2. Give a specific prompt with the expected file, behavior, and test command.
3. Let Codex make the change and run dotnet build or dotnet test.
4. Review git diff carefully, especially for unintended changes to csproj, migration snapshots, or generated code.
5. Ask for fixes or run tests locally before committing.

Example prompts that work well:

• Add a GET /api/products/{id} endpoint using minimal APIs that returns a product DTO from EF Core, with 404 when not found.
• Write xUnit tests for ProductService.CreateAsync, mocking IProductRepository; cover success and validation failure.
• Convert this controller action to a minimal API endpoint in ASP.NET Core 8, keeping the same response shape and status codes.
• Add a nullable reference type warning fix across the src/ projects without changing public API signatures.
• Create an EF Core migration for adding Sku to Product and update ProductDto mapping; do not update the database.

The last prompt is best run with dotnet ef available, and the agent should produce the migration files plus the snapshot diff for you to review.

Codex strengths and .NET pitfalls to watch

Codex is strong at boilerplate and repetitive .NET work: adding minimal API endpoints, mapping DTOs, writing xUnit/NUnit tests with mocks, registering services in DI, configuring middleware, wiring EF Core queries, and fixing nullable warnings. It also reads compiler errors and iterates well.

The risky areas are specific to .NET conventions:

• EF Core migrations: the agent may create multiple migrations for one model change, edit snapshot incorrectly, or try to update the database. Always review migration files and the snapshot.
• Async and concurrency: watch for blocking calls like .Result or .Wait(), missing ConfigureAwait(false) in libraries, and accidental sync-over-async.
• DI lifetimes: the agent sometimes registers a scoped service in a singleton or captures a scoped DbContext in a background service. Ask for a lifetime review.
• Solution and project file edits: it may add package references without pinning versions or change TargetFramework unexpectedly.
• Generated and build artifacts: ensure bin/, obj/, and Migrations generated files are either ignored or reviewed.

A quick guide for task types:

Testing and verifying agent changes in .NET

Make testing mandatory in every turn. Put in AGENTS.md that the agent must run dotnet test after code changes, and use dotnet build with warnings to catch issues early. For targeted work, ask for dotnet test --filter FullyQualifiedName~ProductService instead of the whole suite. If the solution has multiple test projects, specify the exact project.

Before a migration is accepted, run dotnet ef migrations script to review the SQL, and check that the ModelSnapshot.cs diff matches the intended model change. This catches wrong column types or missing indexes. Running AI code review on agent output is useful for .NET because a second model often finds DI lifetime mistakes and EF Core query inefficiencies that the first agent misses. The agent can also run dotnet format to keep style consistent, but review formatting-only changes separately from behavior changes.

Parallel agents on one .NET solution with AgentVera

AgentVera lets many coding agents work in parallel, each in its own real terminal panel and often in its own git worktree, so parallel .NET tasks such as adding an endpoint and creating an EF Core migration do not overwrite each other’s files. Automatic code review and checkpoints matter most for .NET work: a review pass can catch a bad DI lifetime or a broken migration snapshot, and being able to undo a single turn is useful when an agent edits generated migration code. See how this fits a team workflow in AI agent workflow: teams, parallel parts and flows. Keep token budgets tight for long solution-wide refactors.

Wrapping up

Codex is a practical coding agent for .NET when the project’s guardrails are in AGENTS.md and you review the changes it makes. Start with small, test-driven prompts, enforce dotnet test after each change, and treat EF Core migrations and DI lifetimes as review points. Over time, the agent becomes a fast pair programmer for the routine parts of ASP.NET Core and EF Core work.