ServicesCoding agent tools
Getting your repositories and teams ready for OpenAI Codex
We prepare repositories for Codex, set sandbox and approval rules that match your policies, sort out access and models, and train your teams on the CLI, the IDE extension and the cloud agent.
## Build and test - Install: pnpm install --frozen-lockfile - Fast tests: pnpm test:unit (no network) - Lint: pnpm lint ## Do not edit - src/generated/, vendor/, db/migrations/ ## Definition of done - Unit tests and lint pass with no new warnings - Keep each task to one diff that is easy to review
What each repository needs first
We begin with a fresh clone in the sandbox and see what builds and runs there. We check credentials, local services, private registries and generated code. After that we deal with the points where an agent's run and an engineer's local run differ most.
- AGENTS.md entries for building, testing and linting the code
- Brief notes on how the code is organised, which conventions apply and when a task counts as done
- A quick test target that gives the same result on every run, and a label on any suite that is slow or flaky
- Paths that are off limits to the agent: migrations, infrastructure, generated code and vendored dependencies
Where Codex runs, and what it may do there
The CLI runs in an engineer's local checkout, under that engineer's account and the policy you have configured. The cloud agent clones the repository into an OpenAI-hosted environment, where secrets, setup and network rules are configured separately. The desktop app and the IDE extension can connect differently from both, so each of them gets a policy of its own.
Even when the CLI runs locally, your prompts and the relevant code go to whichever model provider is set up. We write down how that data flows. Whoever owns your data and your contract with the provider then checks it against that agreement.
- A sandbox mode and an approval policy for each repository
- What Codex may reach over the network, including package registries
- The type of account, access to models, and who the administrators are
- Settings for the whole team, stored in configuration files and versioned
- Which repositories and data are in scope, fixed ahead of the pilot
When Codex can run without anyone watching
The pilot is interactive: a small group of engineers takes on several typical tasks, under the review process and required checks you already use. Running Codex unattended, in CI or in the cloud, is a decision of its own, because no one sees a run fail while it happens. We recommend it only for narrow, clearly specified work. It also needs checks the agent does not control, pipeline code that alone decides on pushes and merges, and credentials limited to that one job.
- Interactive work first, with tasks short enough for a single review
- Runs without supervision only where the agent cannot touch the tests or the review
- Reverts, rework and what review turns up, recorded per model, task and team, never per person
Training, and handing tasks to the cloud agent
Training uses real items from your backlog. Engineers practise splitting work into diffs a reviewer can follow, and deciding what belongs in AGENTS.md. They also learn when a fresh session works better than further steering, and how to judge changes they did not write themselves. Delegation to the cloud agent gets a session of its own. A run that nobody observed needs a different kind of review from changes you guided step by step.
Each session is for one team, working in that team's repositories. We run it remotely or at your own site in Poland and Germany. Sessions run in English, Polish or German.
What we hand over
- An AGENTS.md file and a sandbox configuration in every repository
- Runbooks that cover onboarding and any later change to a policy
- The pilot's comparisons, with figures from your own tasks
- A written reason for every setting we chose
How you know the setup works
- The share of Codex tasks whose result is merged
- How often the sandbox or an approval rule stops genuine work, and whether it should have
- Spend per accepted change, for runs in the CLI, the IDE and the cloud
Questions
Our teams already work with Claude Code or Cursor. Is this still relevant?
Yes. AGENTS.md is not specific to Codex: several other tools read it as well, so one file holds the instructions they share. Permissions and sandbox settings differ from tool to tool and are set up for each one. To compare the tools fairly on your own work, see coding agent evaluations.
What will a team spend on Codex?
You can pay for Codex through usage included in a ChatGPT plan, credits, token-based billing in an Enterprise workspace or an API key of your own. These can also be combined. We take the invoices and usage figures, work out what you actually spend and express it as a cost per accepted change.
Can we have the training without the setup work?
Yes, as long as Codex already runs your build and tests reliably. We confirm that before the first session.
Which Codex does this page cover?
The coding agent from OpenAI, available as a CLI, an IDE extension, a desktop app and a cloud version. Products and firms that share the name are not part of our work.
Related services
Harness engineering
The setup that tells an agent how to build, test and change your code, kept in version control.
Evaluations on your repositories
Tools, models or settings tested side by side on changes you have already merged, before you commit to one.
Coding agent adoption
Agents taken from a few pilot teams to the rest of engineering, with training and one shared setup.
LLM cost optimisation
Agent spend broken down by team and task, then lowered through defaults, budgets and routing your platform team can run.
From the blog
Handing tasks to cloud coding agents
What a task should contain before it goes to a cloud coding agent, with a reusable brief, three readiness questions and rules for handing work back.
Coding agent security
Practical security and governance for coding agents: prompt injection, secrets, permissions, sandboxing, unattended runs and ownership.
Talk to an engineer
Bring one piece of work you would like to improve. The call takes 30 minutes and needs no access to your systems or your data.
Booking runs on Google Calendar.
Prefer to write first? Leave your email and a few lines, and we reply with times.
Look for the draft in your email program
Send it from there, and an engineer replies in person with times for a 30-minute call. If no draft has opened, write to us at miki@cloudsail.com.