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. Here, “team agent” means a proposed shared automation setup, not a separate Codex product: 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.

Use the organization’s approved service identity and preserve the responsible human requester in the task or pull-request record. Commit metadata alone does not establish who authorized an action.

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. Independent review prevents a proposed change from being accepted solely by its author; branch protections and CI remain separate controls. 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. For rejected changes, record whether the task, configuration, implementation or review cost made them unsuitable. Acceptance rate alone cannot determine whether the setup is worth keeping.

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