Guide
How to roll out Codex and Claude Code across an engineering organisation
Rolling out Codex and Claude Code across an engineering organisation is four pieces of work, and buying licences is none of them. Skills packages come first: the repository conventions, tools and context an agent loads before it does anything, owned once and pointed at whichever vendor harness a team uses. A permission and identity model decides which repositories, systems and credentials an agent may reach, on whose behalf, and which actions stop for a person. Agent-written changes then go through the review path every other change already takes, with their provenance recorded on the change. And the skills themselves are evaluated in CI, because a skill that has drifted from the codebase is worse than no skill at all. Run it team by team, starting with one repository that already ships often, and read adoption from merged changes and rework rate rather than seats activated.
AI coding agent rollout. The organisational work of putting shared skills packages, a permission and identity model, review gates and CI evaluation around vendor coding agents such as Codex and Claude Code, so agent-written changes reach production by the same path as every other change.
1AYM is an OpenAI Select Partner.
Checked . The security, Codex cloud and training sections quote Anthropic's and OpenAI's own documentation as read on that date. Both products change month to month and setting names change with them, so check each one against the current documentation before relying on it.
What a rollout actually consists of
A licence gives your team the vendor's coding agent and the controls available on its plan. The rollout work is to configure those controls for your repositories, connect the systems engineers need, and give the shared setup a named owner.
Which licence to buy is a separate decision, and a smaller one. Claude Team and ChatGPT Business both include a coding agent in the seat, and our comparison of the ChatGPT and Claude business plans sets out their prices, limits and controls as each vendor publishes them. What Codex usage costs on top of the seat, in included limits and credits, is in our guide to Codex pricing and credits.
Engineers are not the only staff these vendors now sell agents to. Claude Cowork, ChatGPT Work and Microsoft's Copilot Cowork take on multi-step office work, and ChatGPT Work draws on the same usage allowance as Codex, so our comparison of ChatGPT Work and Claude Cowork is worth reading before a Codex budget is set.
- Skills packages
- How this codebase is tested, what a good change looks like here, which internal services may be called and how. Written once and loaded by Codex, Claude Code or Cursor as the work requires, rather than reinvented per team. If managing reusable assets across both tools is part of the plan, see the 1AMS demonstration and scope a pilot.
- Permissions and identity
- Which repositories, cloud accounts and credentials an agent reaches, and on whose behalf. Agent identity is the part most rollouts postpone and the part that decides what a mistake can touch.
- Review gates
- The same pull request, the same code owners and the same required checks as every other change, with provenance recorded on the change so nobody has to guess later which ones an agent wrote.
- CI evaluation
- The skills are tested like code. A package that has drifted from the repository fails a check, rather than quietly producing worse changes for a quarter.
- A named owner
- One person accountable for the skills estate and the permission model. Without that, everything above becomes nobody's job by the third team.
The order matters more than the tool choice
Start in one repository that already ships frequently and has tests worth trusting, because it is the only place you can tell whether the agent helped. Get skills and permissions right there, in that order: skills give the agent enough context to be useful, permissions decide what its mistakes can reach.
Review gates come next, before the second and third team rather than after them. CI evaluation of the skills is the piece most organisations defer, and it is the one that decides whether the estate still works in six months. The trade-off is honest: done in this order the first three weeks look slow, because the visible output is configuration rather than merged pull requests. A rollout that starts with breadth instead buys three weeks and then spends a quarter unpicking a hundred private conventions formed in the first fortnight.
If the tool choice itself is still open, our comparison of Codex and Claude Code for business sets out what a seat costs, what a switch carries across and where each keeps its controls.
The questions either side of a rollout, from which plan to buy to how to govern AI once people use it, each have a page of their own in our guides for AI buyers.
Who owns each phase of a rollout?
One person answers for the whole rollout. Every phase under them still needs a working owner, and the handoffs between those owners are where a rollout usually stalls. The table names a role for each phase, because job titles vary: in a smaller company the platform lead and the security reviewer can be the same person. The exit criterion is what must be true before the phase is done, and the measure is the number that shows it.
| Dimension | Working owner | Exit criterion | Measure |
|---|---|---|---|
| Pilot repository and baseline | The rollout owner, with the tech lead of the chosen repository | One repository that ships often, with tests the team trusts, is chosen, and its baseline numbers are written down before any agent work starts. | The baseline itself: merged changes, time from draft to review-ready, reviewer time and rework, for that team |
| Skills packages | The pilot repository's tech lead writes them, and the rollout owner reviews them | The skills live in the repository, are reviewed like code, and load in each agent the team uses. | Time from first draft to review-ready, against the baseline |
| Permissions and identity | Platform engineering builds the model, and security signs it off | Which repositories, systems and credentials each agent reaches, on whose behalf, and which actions stop for a person, all written down and enforced in managed settings rather than in a wiki. | Whether you can say, from configuration alone, what a bad run could have touched |
| Review gates | The code owners of each repository, under a rule engineering leadership sets | Agent-written changes take the same pull request, code owners and required checks as every other change, with their provenance recorded automatically. | Share of merged changes with agent involvement, and reviewer time per change |
| CI evaluation of the skills | Whoever owns the skills estate, usually platform engineering | A skill that has drifted from the repository fails a check before it reaches an engineer. | Rework within thirty days |
| The next team | The rollout owner, with the joining team's lead | The new team works from the shared skills and permission model, and has been trained on them, without writing private versions of either. | The same four numbers, against that team's own baseline |
The rollout owner is a senior engineering leader, not procurement, not the IT service desk and not the vendor. Security signs off the permission model and owns nothing else in the table, and that is deliberate. A rollout run by security tends to become a list of things engineers may not do, and one run by procurement tends to become a count of seats.
Claude Code security: what to check before engineers use it
A security review of Claude Code usually starts with the model. The more useful question is what the agent on each engineer's machine may do without asking, and who decided that. Claude Code answers it through permission modes and settings, and an organisation can set both centrally. Anthropic's security page describes Manual mode: Claude Code starts read-only, asks before it edits files, runs tests or executes commands, and writes only inside the folder it was started in unless someone allows more. Auto mode hands those approvals to a separate classifier model, and an organisation can turn it off. Which mode a session starts in depends on the plan, the surface it is started from and the engineer's and organisation's settings [1].
For the vendor-assurance part of the review, Anthropic publishes its security certifications and audit reports through its Trust Center [1]. The checks below are the part that depends on your own configuration, and I would want every one of them settled before the first real repository.
- Managed settings, not a wiki page
- Policy reaches each machine from the claude.ai admin console, a device-management profile or a managed-settings.json file, and Claude Code applies it above anything an engineer, a repository or a command-line flag sets [2]. Running /status on a machine shows whether the policy arrived [2].
- The skip-everything mode switched off
- Claude Code has a mode that bypasses permission checks, and managed settings can disable it for everyone [2]. Decide on auto mode at the same time and on purpose, so nobody finds out later which engineers switched it on [1].
- The sandbox on, and failing closed
- The sandbox confines shell commands to set folders and network domains, using Seatbelt on macOS and bubblewrap on Linux and WSL2; native Windows is not supported [3]. By default, if the sandbox cannot start, Claude Code warns and runs the command unsandboxed, and one setting turns that into a hard failure. Sandboxed commands can also still read credential files such as ~/.aws/credentials and ~/.ssh until you block them [3].
- Network egress on an admin list
- Inside the sandbox no domain is allowed until someone approves it, and managed settings can restrict the list to domains an administrator added, so an engineer's approval cannot widen it [3].
- MCP servers from an approved list
- Anthropic reviews the connectors in its directory against listing criteria, but states that it does not security-audit or manage any MCP server [1]. Managed settings can limit engineers to an approved list of servers [2].
- Cloud sessions governed separately
- In Anthropic-hosted environments, Claude Code on the web runs each session in an isolated virtual machine that Anthropic manages, keeps GitHub credentials out of it and restricts pushes to the current branch [1]. Sessions routed to a self-hosted environment run on your own infrastructure, where isolation, network egress and git credentials are yours to secure [1]. Anthropic-hosted sessions do not read a laptop's device-management profile or settings file, so their policy has to come from server-managed settings [2].
- The data terms for your plan
- On Team, Enterprise and the API, Anthropic does not train models on code or prompts sent to Claude Code unless the customer opts in, and standard retention is 30 days. Zero data retention is available to qualifying Claude for Enterprise organisations, enabled per organisation [4]. The client also keeps session transcripts in plain text on the engineer's machine for 30 days by default, which your endpoint policy should account for [4].
None of these settings replaces review. Anthropic's own page says its protections reduce the risk of prompt injection and that no system is immune to every attack [1]. Approvals inside the tool are one gate and the review path is another, and our write-up of letting the agent propose while a separate check decides what ships explains why the second cannot be skipped.
Codex cloud: what runs where, and who can see your code
Codex cloud runs coding tasks on OpenAI's infrastructure instead of the engineer's laptop. Each task gets its own isolated workspace, created from a published environment that holds the repositories, dependencies, tools and access settings, and it keeps working while the engineer's computer is asleep [6, 7]. Tasks start from ChatGPT on the web or the desktop app, or from Slack and Microsoft Teams in an Enterprise workspace that allows it, and the result comes back as changed files and test results to review before anyone commits or opens a pull request [6, 7]. Cloud environments work with GitHub repositories. GitLab and self-hosted GitHub Enterprise Server are not yet supported there, and OpenAI lists both on its roadmap [7]. Code review of GitLab merge requests is a separate integration, in beta, that also runs in Codex cloud [13].
What a security team needs is where the boundaries sit. On OpenAI's documentation they are these.
- Who can switch it on
- Codex cloud is off by default in Enterprise workspaces, unless the workspace had already switched on the legacy version. An admin grants Use Codex in the cloud to the people who should have it, and separately grants Manage workspace environments to those who build shared environments [8].
- Which repositories it reaches
- Codex cloud respects the repository permissions and protections of the connected source system, and workspace access does not bypass them [8]. The real control is therefore in GitHub: limit each audience to the repositories it needs.
- What leaves the environment
- Each environment's internet settings decide which domains its virtual machine can reach, from a package-manager preset to custom domains or unrestricted access [7]. Enterprise admins add workspace-wide limits in Agent Security, and a domain allowed there does not override a restriction in the environment's own settings [9]. OpenAI lists the risks of agent internet access plainly: prompt injection from untrusted content, code or secret exfiltration, and malware or vulnerable dependencies [10].
- Where credentials sit
- An environment variable is passed straight to programs in the environment. A network secret is not: programs see a placeholder, and a proxy substitutes the real value only on HTTPS requests to the domains you allowed [7]. Registry tokens and API keys belong in the second kind.
- Who can see a task
- An environment can stay private to the person who built it or be shared with the workspace. Sharing lets colleagues start their own tasks from the setup; it does not give them someone else's task or the right to edit the environment [7]. A task's saved state is recoverable for up to seven days after its last turn or resume, and OpenAI's own guidance is that saved state does not replace source control [7].
- What gets recorded
- Enterprise workspaces can export supported records, Codex activity among them, through the Compliance API into an audit or investigation system. OpenAI says to use those records for investigations and to report adoption from analytics instead [12].
One trap is common to both products, and it catches rollouts that did the hard work on laptops: the policy pushed to engineers' machines does not govern the cloud route. Codex cloud environments do not inherit device-management (MDM) policy or local network access [8], and Claude Code sessions in Anthropic-hosted cloud environments ignore the laptop's policy and need server-managed settings [2]. Before a pilot uses either cloud route, test one request the policy should allow and one it should block, which is also what OpenAI's admin guidance recommends [9].
What should Codex and Claude Code training cover?
The keystrokes are the smallest part, and both vendors document them well for free. Training that changes what reaches production teaches your own layer on your own repositories: the skills, the permissions and the review path this page describes. Six things belong in it.
- Instructions versus settings
- Codex reads AGENTS.md files before it starts work, and Claude Code reads CLAUDE.md or, where there is none, AGENTS.md [5, 11]. Anthropic is explicit that those files are context rather than enforced configuration; anything that must never happen belongs in managed settings [5]. An engineer who knows the difference stops treating a line in a markdown file as a control.
- Permission modes and approvals
- What each mode lets the agent do without asking, how approving a command once differs from allowing it for good, and why nobody skips the checks on a repository that matters.
- Reviewing agent-written changes
- Reading fluent code sceptically, running the tests before reading the diff, and checking that provenance is on the change. Tidy code that is wrong is the failure this part exists for.
- Untrusted input
- Issues, READMEs, dependency documentation and web pages can carry instructions. OpenAI's own example is a GitHub issue asking the agent to run a script that posts the latest commit to an outside server [10]. Engineers should recognise that pattern before an agent meets it.
- Changing a shared skill
- How to propose a change to a skill, evaluate it in CI and ship it, and who owns the estate. This is what stops skills forking into private copies by the third team.
- Usage and cost
- What draws down an allowance or credits, and why loading less context into each session is the cheapest control an engineer has.
Train each team when it joins, on its own repository, in the same week its permissions go live. A course run for all of engineering before the skills exist teaches people to work around a layer that is not there yet.
Where do-it-yourself rollouts stall
None of this is beyond a competent in-house team, and plenty of organisations do it themselves. The ones that stall tend to stall in the same places, and every one of them is organisational rather than technical.
- Skills nobody owns
- Each team writes its own, none are reviewed, and nobody can say whether the setups agree. The estate grows faster than the ability to reason about it.
- Permissions granted per person
- Access follows whoever asked, so what an agent can reach is whatever its operator happens to hold, and no one can answer what a bad run would have touched.
- A side channel to production
- Agent-written changes attract a lighter review because they read tidily. Tidy is the failure mode: fluent code passes eyes that would have caught the same error written badly.
- Adoption measured by licences
- Seat counts rise, nobody can name a change that reached production because of the tools, and the renewal conversation has no evidence in it.
An unowned skills estate accrues debt you can price
Leaving this layer unowned has a price, and on one engagement we can put a measurement against part of it. On an enterprise platform we hold the lead architect role for, the skills estate had drifted far enough that re-architecting it produced a material reduction in the average cost per session. The engagement file records the measurements and their provenance; the measurements were taken by 1AYM on that platform, before and after the change.
The mechanism was dull, which is the point. Skills written as flat, monolithic files dragged far more context into every session than the task in front of them used. Nobody had decided that; it accumulated, one unreviewed package at a time, which is exactly what an unowned estate does. The fix was architecture rather than heroics: routing, description budgets and evaluation, the same layer this page describes.
How do you measure adoption honestly?
Seat activation measures procurement. It tells you what was bought, not what changed. A handful of numbers, read per team and against that team's own baseline, tell you whether the rollout worked.
- Share of merged changes with agent involvement
- Recorded on the change automatically, never self-reported. A survey of how useful engineers found the tools measures enthusiasm.
- Time from first draft to review-ready
- The interval these tools genuinely compress. If it has not moved, the skills packages are too thin to carry the codebase.
- Reviewer time per change
- If this is rising, the rollout has moved cost from author to reviewer rather than removing it. That is a real result and it belongs in the report.
- Rework within thirty days
- Changes reverted or substantially rewritten. The number that says whether faster output was worth having.
When not to roll out
Do not roll out to an organisation that cannot merge a small change quickly today. Agents raise the volume of proposed changes, so if review is already the bottleneck, more proposals make it worse and the tools take the blame for a queue that predates them.
Do not roll out where nobody senior owns the outcome. Skills, permissions and gates are decisions with trade-offs attached, and a rollout without an owner reverts to whatever each team improvises.
And do not buy a programme where one squad and a fortnight would settle the question. Put Codex or Claude Code on a real repository with two weeks and a target, and count the changes that merged. If the answer there is no, an organisation-wide rollout will not rescue it, and the money is better spent on the tests and the review capacity that would have made the answer yes.
Where 1AYM fits
Setting up and rolling out coding agents is core 1AYM work, including every block on this page: the phase owners, the managed settings and cloud policies, the skills estate and its CI checks, and the training. We sell it as AI Engineering Transformation, and the engagement ends with your engineers owning that layer rather than renting it from us. The documented case is the platform described above, which runs on Claude Code.
We build on OpenAI's and Anthropic's tools alike, so the evidence from your pilot decides between Codex and Claude Code. A fixed-scope statement of work for the first team can start within a day of the scope being signed, and if you have already scoped the rollout, we can resource it on contract from the collective of associates who work with us, held to the same standard as the rest of the firm. Book a call below or email enquiries@1aym.com if that would help.
For engineers: the settings behind the security checks
The configuration names behind the checks above, as each vendor documents them on the date at the top of the page. Names change between releases, so confirm each one against the current documentation before you ship a policy.
- Claude Code managed settings
- Delivered as server-managed settings from the claude.ai admin console, through device management, or as a managed-settings.json file. permissions.disableBypassPermissionsMode set to "disable" removes the skip-permissions mode, disableAutoMode turns auto mode off, allowManagedPermissionRulesOnly makes managed settings the only source of permission rules, and allowManagedMcpServersOnly limits MCP servers to the managed allowedMcpServers list. The Setting sources line in /status shows which source is in force [2].
- Claude Code sandbox
- sandbox.enabled turns it on; sandbox.failIfUnavailable makes a sandbox that cannot start a hard failure; allowUnsandboxedCommands set to false removes the retry outside the sandbox; sandbox.network.allowManagedDomainsOnly honours only managed domain lists; sandbox.credentials or sandbox.filesystem.denyRead blocks credential files. Linux and WSL2 need bubblewrap and socat installed [3].
- Claude Code data and telemetry
- Local transcripts live under ~/.claude/projects/ for 30 days, adjustable with cleanupPeriodDays. DISABLE_TELEMETRY=1 stops usage metrics, and CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC turns off all non-essential traffic at once. Metrics, error reports and /feedback reports are off by default on Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry and Claude Platform on AWS, though metrics default on when a host platform manages the provider [4].
- Codex cloud access and policy
- Use Codex in the cloud and Manage workspace environments are separate role permissions [8]. In Admin Console, Agent Security holds a Global baseline and a Codex Cloud override for execution settings such as sandboxing and managed networking. Requirements are limits users cannot override, defaults are starting values within them, and turning Manage Networking off is not the same switch as an environment's internet access being off [9].
- Codex cloud secrets and private services
- The proxy substitutes network secrets only on HTTPS, port 443, to their allowed domains, during setup and tasks. Private services are reached through a VPN, with Tailscale the supported provider today, and OIDC for short-lived cloud credentials is available by request on Enterprise. For services that filter by source IP, OpenAI publishes an agent egress IP feed whose ranges are shared across customers, so keep the service's own authentication in place [7].
Sources
- [1]Anthropic, Claude Code: Security (read 30 September 2026)
- [2]Anthropic, Claude Code: Deploy managed settings (read 30 September 2026)
- [3]Anthropic, Claude Code: Configure the sandboxed Bash tool (read 30 September 2026)
- [4]Anthropic, Claude Code: Data usage (read 30 September 2026)
- [5]Anthropic, Claude Code: How Claude remembers your project (read 30 September 2026)
- [6]OpenAI, Codex Cloud (read 30 September 2026)
- [7]OpenAI, Codex: Cloud environments (read 30 September 2026)
- [8]OpenAI, Codex: Enterprise admin setup (read 30 September 2026)
- [9]OpenAI, Agent Security (read 30 September 2026)
- [10]OpenAI, Codex Cloud (Legacy): internet access (read 30 September 2026)
- [11]OpenAI, Codex: Custom instructions with AGENTS.md (read 30 September 2026)
- [12]OpenAI, Compliance API and audit events (read 30 September 2026)
- [13]OpenAI, Codex: Review GitLab merge requests with Codex (read 30 September 2026)
Related questions
Should we standardise on one coding agent, or run Codex and Claude Code side by side?
Choose from the evidence on your workflows. Stay with one tool when it meets the need and a second would add more cost and maintenance than value. Switch when the new tool meets your acceptance criteria and the benefit justifies the transition. Keep both where each earns its place on named tasks. In every case, give the shared skills, permission model and review path clear owners, and revisit the choice when measured results change.
Do we pilot with one team first, or roll out to all of engineering?
One team, one repository that ships frequently, and a fixed end date. A pilot exists to produce evidence a wider rollout can be designed from: which skills the codebase actually needs, where permissions bite, what review load looks like. Rolling out to everyone first inverts that, and the conventions formed in the opening fortnight are then the thing you have to unpick before anything can be shared.
Who should own an AI coding agent rollout?
A senior engineering leader with authority over how code reaches production, usually whoever runs platform engineering or developer experience, or the head of engineering in a smaller company. Procurement, the service desk and the vendor all have a part, but none of them decides which repositories an agent reaches, what it may do unasked or how its changes are reviewed. Security signs off the permission model, code owners own review in their repositories, and each team lead owns adoption in their team. An outside firm can build the layer, but the owner should be one of your own people, or the rollout ends when the contract does.
How long before engineers feel the difference?
A focused pilot can show useful changes quickly, but the wider schedule depends on your repositories, permissions, integrations and review capacity. Our AI Engineering Transformation engagement is typically scoped at six to twelve weeks; that is a planning range for the work, not a guaranteed time to benefit. Agree the first team's acceptance criteria and measure the result before setting the pace for the next teams.
Who owns the skills packages once the rollout is done?
The client, in the client's repositories, reviewed like any other code, with a named owner for the estate and a maintainer per package. If an external firm holds the skills, the organisation has bought a dependency instead of a capability. The test is simple: can your engineers change a skill, evaluate it in CI and ship it without anyone external in the loop.
What do we do about engineers already using these tools without a policy?
Treat that as the starting material, not as a violation. Find out which repositories, which tools and which credentials are already in play, then write the permission model and the skills packages around what is genuinely happening. A ban produces the same usage with less visibility, and the conventions those engineers have already worked out are usually the best first draft of the skills estate.
More in this topic
- Claude Code vs GitHub CopilotComparison
Which of the two an engineering team on GitHub should use, from each vendor's own pages.
- Codex vs GitHub CopilotComparison guide
Whether a team whose code is on GitHub needs Codex, GitHub Copilot or both.
The shared instruction file every agent reads: let the agent map the repository, then answer its questions on what the code cannot show.
Further
- AI harness & platform engineering · The engagement this is bought as: architecture, skills packages, guardrails and CI on Codex, Claude Code and Cursor.
- AI, data and automation enablement across a global agency · The engagement file behind the skills-debt measurements, with provenance stated.
- What is an AI harness? · Who builds the runtime the rollout sits on, and what the organisation still has to write.
We build these systems for a living. See the engagement files for what that looks like in practice, or write to us if yours is the next one.
Last reviewed · 1AYM