OpenAI Codex for C#: Specify, Build and Test a Change

The OpenAI Codex cloud agent can read a C# project, interpret a task description and return code changes with build and test output. The quality of the result depends on what you give it before it starts: a clear task, the relevant solution context and any architecture decisions it must follow.

Without that context, Codex makes choices that may contradict your conventions or undo a decision made in a previous run. Tools like fenbs keep those approved decisions and the current task list in a shared record that any connected assistant reads first, so each Codex session starts from an agreed baseline.

What the Codex cloud agent does with C# code

The Codex cloud agent runs in a sandboxed environment. It can clone a repository, read files, write changes, run dotnet build and run dotnet test. When a task completes it returns a diff, the build output and a test summary. You review the result before merging anything.

It works best on a bounded task: a new method, a new service class, a bug fix in a named file. Broad tasks like "refactor the entire data layer" are harder to scope and harder to verify. For a comparison with other options, see cursor vs codex and codex alternatives.

How to give Codex the right solution context

Codex reads the files you reference in the task prompt. For a C# project, useful context includes:

• The solution and project structure, so it knows which project owns the type it is working with.
• The relevant interface or base class, so a new implementation follows the right contract.
• Naming conventions in the existing code, especially for async methods, result types and error handling.
• The test project name and a sample test, so it knows the pattern for new tests.

Add a sentence for any approved decision that applies to this task: "Use the Result<T> pattern for all service return types, not exceptions." If that decision lives in fenbs, ask your connected assistant to read the project context before you write the Codex prompt. For connecting a C# project context over MCP, see MCP server for C#.

Writing a useful task prompt for C# work

A good Codex prompt for C# work has three parts: what to build, where it lives and how to verify it.

1. State the goal in one sentence: "Add a GetInvoiceAsync method to InvoiceService that takes an int invoiceId and returns a Result<Invoice>."
2. Name the files: "InvoiceService is in Services/InvoiceService.cs. The Result<T> type is in Core/Result.cs."
3. State the expected test: "Add a test in InvoiceServiceTests that confirms a missing id returns a failure result, not an exception."

Keep the prompt focused on one task. If you have several changes to make, run Codex on each one separately and review the diff before moving to the next. Multiple changes in a single run are harder to review and harder to undo if one of them is wrong.

Reviewing build results

Codex returns the dotnet build output. Read the errors before the warnings. A build error Codex introduced is usually a sign that it misunderstood the type it was working with, missed a required interface member or made an assumption about a namespace that does not match your project.

Check that new code compiles against the .NET version your project targets. Codex may write code using an API available in .NET 8 when your project targets .NET 6. The prompt can prevent this: "The project targets .NET 6.0. Do not use APIs introduced after that version." State the target version once in each prompt; do not assume Codex remembers it from a previous run.

Reviewing test results

A passing test after a Codex run is a good sign, not a guarantee. Check that the test Codex wrote actually covers the behavior you asked for, not a trivial case that would pass with any implementation. A test that asserts a non-null return value is weaker than one that asserts the correct failure result for a missing invoice.

If tests fail, read the output before asking Codex to fix them. A test failure sometimes reveals that the task description was ambiguous or that an existing test describes behavior the new code changes. That is a decision for a person to make, not something to ask Codex to resolve automatically. For comparison with ChatGPT's Codex interface, see chatgpt codex.

What Codex is not the right fit for

Codex works on a narrow task against a codebase it can read in its entirety. A large C# solution with many inter-dependent projects may be too big to scope into a single run. Tasks that require human judgment at each step, such as a data migration that changes live records, are not a good fit for autonomous execution.

Codex also does not maintain memory between runs. If you close a run and start a new one, it does not know the decisions from the previous session unless you provide them again. That is the gap a persistent work record fills. Storing decisions outside the tool is not optional for a project that runs across more than one session.

Keeping architecture decisions across sessions

An architecture decision made in one Codex session is invisible to the next one unless you record it somewhere. Write each decision with enough context to be useful without the conversation that produced it: what was chosen, why, and what it means for future changes.

C# architecture decisions tend to cluster around error handling patterns, async conventions, which abstractions own which responsibilities and which NuGet packages are approved. A decision about error handling is worth very little if it says only "use Result." It needs the reason, the scope and the exception: "use Result<T> in all service return types; throwing is acceptable in the infrastructure layer only for unexpected I/O failures." The reason is what helps a future session judge whether an exception is justified.

In fenbs, Decisions and rules give each choice a permanent home: what was decided, who decided it and why. Mark architecture decisions as standing rules and they appear first in the AI context every connected assistant reads. Add unfinished implementation tasks alongside so the next Codex session picks up from a clear record rather than choosing its own path.

How to do this with fenbs

1. Create a free account at fenbs.ai and add a project for the C# solution.
2. Write each approved architecture decision as a Decisions and rules entry. Mark the ones that apply to every session as standing rules.
3. Add implementation tasks with notes on what is in progress, what was completed in the last run and what remains.
4. Connect your coding assistant from Integrations. Before writing each Codex prompt, ask the assistant to read the project context and rules.
5. After each run, update the task notes with what Codex completed, what was accepted and what needs a follow-up review.

fenbs does not connect directly to Codex or run Codex sessions. It holds the decisions and tasks that inform the session. For API key setup see codex API key. For a comparison with Copilot's cloud agent, see codex vs GitHub Copilot.