Setting up one Codex team agent everyone shares

Why a shared agent at all

Individual developers running their own configuration is fine for exploration and bad for anything that runs unattended. A Codex team agent is the version you set up once: a single identity, a single set of repository instructions, and permissions that a platform owner can change without asking fifteen people to update a local file.

The practical driver is usually auditability. When an agent opens a pull request, you want the account on it to be a service identity you can trace, not whichever engineer happened to have their laptop open.

What to configure

• A dedicated machine account with the narrowest repository access that lets it do the job. Not an admin token borrowed from someone's personal account.
• Write access to branches, never to the default branch. Everything arrives as a pull request that a human merges.
• Repository instructions committed to the repo, so the config is reviewable in a diff rather than living in a settings page nobody reads.
• An explicit list of directories excluded from the agent's reach, enforced in config and not by politeness in a prompt.
• A resource ceiling. Cap what a single run can consume so a stuck loop is an annoyance, not an invoice.

Give it a recognisable name in commit metadata. Something like codex-agent@yourcompany so anyone reading git log six months later knows immediately which changes were machine-authored.

Good jobs for a shared agent

The reliable wins are the boring, repetitive, verifiable ones. Dependency bumps where the test suite decides whether it worked. Flaky test triage that opens an issue with a stack trace and a first hypothesis. Backfilling missing tests on modules with low coverage. First-pass review comments on every pull request.

What they share is a check the agent can run itself. Where the check exists, an unattended agent is genuinely useful. Where it does not, you are queuing up work for a human reviewer and calling it automation.

What it should never do

No approvals and no merges, permanently. An agent that can approve its own output removes the only control in the system. No access to production credentials or to infrastructure that can delete data. No unattended runs against repositories holding customer-owned code until legal has actually answered the data handling question in writing.

Also expect it to open pull requests that are simply not wanted. Closing them is cheap. Feeling obliged to review them all is what kills adoption, so give the team explicit permission to close agent PRs without explanation.

Where to start

Set up the service account, point the agent at one repository, and give it exactly one recurring job for a fortnight. Dependency updates are the usual first choice. Then count how many of its pull requests were merged unchanged. Under half means the configuration needs work, not that the idea was wrong.

If you want help putting this into practice, talk to us.