For engineering teams

Codex pilot: from private setups to a shared configuration in your repo.

A Codex pilot for a team that already uses it: a shared AGENTS.md and command rules in one repo, and a written go/no-go decision against agreed criteria.

The offer: a pilot for one team in one repo, ending in a written go/no-go decision against criteria set down before kickoff. We agree time and cost in writing before we start.

Describe your caseSee what stays in your repo

Your repo after the pilot

  • AGENTS.mdproject instructions
  • .codex/config.tomlproject settings
  • .codex/rules/command rules
  • .codex/hooks.jsonchecks that run on events
  • .agents/skills/team procedures
  • .codex/agents/subagents
  • .github/workflows/PR gate
The configuration stays in the repo and changes only through a PR.

When every developer configures Codex their own way

Your developers already work with Codex, each on their own settings. For one-off experiments, that is enough. Once the agent changes code the whole team answers for, the missing shared rules show up in code review and in the questions your security team asks.

Different permissions
One developer lets the agent run commands without asking. Another approves every command separately. The same task runs differently for each of them.
No shared rules
Project conventions, how to test, which areas are off limits: each developer explains these to the agent separately, or not at all.
Nobody knows what the agent may run
There is no single place that shows which commands, files and systems the agent can reach in a given repo.
Security questions nobody can answer
Your security team asks about data, permissions and change control, and nobody can answer for the whole team.

Why run a pilot when the documentation exists?

OpenAI publishes an admin rollout guide and configuration documentation. They explain what you can configure and how. In the pilot we do it in your repo, with your team, and finish with a written decision on whether to go further.

The pilot

From diagnosis to a written decision

We work with one team in one repo. Each step shows what Aurora AI does, what your team brings and what we check.

Team
One team that already uses Codex
Repo
One repo, chosen together with you
Ends with
A written go/no-go decision against criteria set down before kickoff
Time and cost
Agreed in writing before kickoff

  1. Diagnosis

    Diagnosis and decision criteria

    We look at how your developers use Codex today, pick the team and repo for the pilot, and write down the decision criteria.

    Aurora AI
    Talks to the developers, reviews their current settings and proposes the team, the repo and the go/no-go criteria.
    Your team
    The lead names the team, the repo and the person who will make the final decision. Developers show how they work with the agent today.
    We check
    The go/no-go criteria are written down, and the person who will decide accepted them before kickoff.

  2. Configuration

    A shared configuration in the repo

    Working rules, permissions and the agent’s tools go into the repo: AGENTS.md, project settings, command rules, hooks, skills, subagents and the MCP configuration.

    Aurora AI
    Prepares the configuration from the diagnosis and submits every change as a PR.
    Your team
    Developers review every PR and decide what goes into the repo. Each of them marks the project as trusted on their own machine, because only then does Codex load the project settings.
    We check
    The configuration lives in the repo, and every change to it has passed team review in a PR.

  3. Tasks

    Real work from the backlog

    The team works with Codex on real tasks from the current backlog.

    Aurora AI
    Pairs with developers and adjusts the configuration where it gets in the way or something is missing.
    Your team
    The team picks tasks from the current backlog and reports where the configuration helps and where it slows work down.
    We check
    Changes made with the agent get the same code review as all other work, and configuration fixes go through a PR.

  4. Governance

    Governance and security

    On top of the rules in the repo, we add organisation policy, a CI gate and answers for your security team.

    Aurora AI
    Prepares admin requirements and forbidden rules, sets up a PR gate for agent-made changes, and writes down answers to the security team’s questions.
    Your team
    Your admins deploy the requirements from the admin console, through MDM (macOS) or as a system file, and the security team asks its questions and assesses the answers. Licences stay on your own OpenAI plan.
    We check
    A forbidden command is blocked, an unreviewed change does not reach the main branch, and the security team has its answers in writing.

  5. Decision

    Decision and handover

    The pilot ends with a memo that assesses the result against the criteria written down at the start.

    Aurora AI
    Writes the memo with a go or no-go recommendation and hands over the configuration documentation.
    Your team
    The accountable person makes the decision, and the team takes over the configuration and keeps maintaining it as code.
    We check
    The decision is in writing and justified against the criteria. The configuration stays in the repo whatever the outcome.

What stays in your repo

The configuration is built in your repo and reviewed by your team. You keep it after a no-go decision too.

  • AGENTS.md

    Shared project instructions

    Working rules for the repo that Codex loads on every run. The file closest to the working directory takes precedence, so part of the repo can have its own rules.

  • .codex/config.toml

    Project settings

    Shared defaults: the sandbox, command approvals and MCP servers. Codex loads them only in a project marked as trusted.

  • .codex/rules/

    Command rules

    Rules for the agent’s commands: allow runs the command without asking and outside the sandbox, prompt needs approval, forbidden blocks. When several rules match, the most restrictive one applies. That is why we keep allow rules narrow.

  • .codex/hooks.json

    Hooks

    Checks that run on defined events and can block an agent’s tool call. Project hooks work only in a trusted project, and only after each hook is approved (again after every change).

  • .agents/skills/

    Team skills

    Your team’s written procedures. Each has its own SKILL.md file with a name and a description, and Codex looks for them in the repo.

  • .codex/agents/

    Subagents

    Each subagent has its own file with a name, a description and instructions. It cannot override the sandbox, command approval or MCP settings.

  • requirements.toml

    Admin requirements

    Organisation policy that a developer cannot change locally. Admins deploy it from the admin console, through MDM (macOS) or as a system file, for example with a list of allowed MCP servers and command rules.

  • .github/workflows/

    PR gate in CI

    A CI check that does not let an agent-made change into the main branch without tests and human review.

  • go/no-go memo

    Decision memo

    A written assessment of the pilot against the criteria agreed before kickoff, with a go or no-go recommendation.

  • team

    A trained team

    Developers who know the configuration, change it through PRs and can maintain it on their own.

Your admins deploy the admin requirements for the whole organisation, outside the repo. The memo goes to the person who makes the decision, and the know-how stays with your team.

Our own example

Codex works in our repo too

We also develop the site you are reading with Codex. Claude Code and Codex read our skills and agent definitions from a single source.

  • We write skills and agent definitions once, in a single source in the repo.
  • Scripts recreate them where Codex reads them: skills in .agents/skills/, agent definitions in .codex/agents/.
  • Both tools work to the same rules, and a fix in the source reaches both of them.

We have already delivered a Codex rollout for a client. As with all our client work, we do not name the company.

scripts/codex/sync_agents.py (docstring excerpt)

The subagent roster is defined once, in `.claude/agents/<name>.md` (YAML
frontmatter + a Markdown body). Codex CLI wants the same roster as TOML in
`.codex/agents/<name>.toml`, so the mirror is a format conversion rather than
the straight copy its sibling `sync_skills.py` does […]

An excerpt from the script that carries our agent definitions over to Codex

We write agent definitions in Markdown, and Codex reads them as TOML. A copy maintained by hand drifts over time and does not go quiet: it keeps giving the agent instructions the project has already dropped. That is why a script does the conversion, not a person.

After the decision

The pilot does not turn into a wider rollout on its own. You decide the next step, based on the memo.

A go decision

The next step is a rollout to more teams. We agree its scope, time and cost separately, based on the pilot’s findings.

A no-go decision

You keep the configuration in the repo and the memo. You know why it is not worth going further right now.

When a Codex pilot makes sense

The pilot helps when

  • Your developers already use Codex, each with their own settings.
  • You want shared rules before the agent spreads to more teams and repos.
  • Someone on your side can make the go/no-go decision and own it.
  • Your security team is asking what the agent may do in your code and needs the answers in writing.

The pilot is not the right choice when

  • You are still choosing a tool. Then start with a conversation about how your team works, or with our comparison of Claude Code and Codex.
  • Nobody on your side can take responsibility for the decision.
  • You expect us to supply the licences. We do not sell them: you buy them directly from OpenAI.
  • You want agent-made changes to reach your code without review.

Common questions

Is Aurora AI an OpenAI partner?

No. Aurora AI is an independent consultancy. We do not sell licences and we are not a billing intermediary. You buy licences directly from OpenAI, on a ChatGPT Business or Enterprise plan or through the API, and each developer signs in with their own account.

Will our code be used to train models?

According to OpenAI’s documentation (as of October 2026), data from the ChatGPT Business, Enterprise and Edu plans and from the API platform, meaning what you send and what you get back, is not used to train models by default. OpenAI’s help page for the Business plan confirms that this also covers the workspace where your team uses Codex. In the pilot we write down which plan and which settings this depends on, and confirm it with your security team.

How long does the pilot take, and what does it cost?

That depends on the team, the repo and the decision criteria, so we do not publish prices on the site. We agree time and cost in writing before kickoff, after a first conversation.

Codex changes often. What happens to the configuration?

The configuration lives in your repo and changes through a PR, like any other code. When OpenAI changes how the tool works, for example by retiring one of the approval settings, the team updates .codex/config.toml or AGENTS.md in a normal PR. In the pilot, the team practises exactly this way of working.

What if the decision is no-go?

You keep the configuration and the memo. The memo shows which criteria were not met, so you know what would have to change before you revisit the decision.

Can you roll out Codex across the whole company?

That is a possible next step after a go decision. We plan and price that stage separately, once we know what the pilot showed.

More in the knowledge base

Articles and guides that go deeper into the topics of the pilot. If you are still choosing a tool, start with the comparison of coding agents.

Describe how your team uses Codex today

Tell us what settings your developers use today, which repo you want to start in and who will make the go/no-go decision. We reply by email and suggest a conversation about the pilot.

Describe your case

The contact page leads to email. You do not need a finished specification.

Aurora AI is an independent consultancy. We are not an OpenAI partner, we do not sell licences, and we are not a billing intermediary. Codex is an OpenAI product.