---
title: "Codex"
description: "Scoped credentials for OpenAI Codex agents"
url: "https://gazebohq.com/agents/codex"
---

OpenAI Codex can work through coding tasks that involve repositories, code changes, tests, and configured external tools. For a cloud-based or long-running coding workflow, the question is not only whether the code change is correct; it is also which services the agent can reach while interpreting the repository, task description, test output, and tool responses. A broadly privileged token made available for convenience can turn a repository-scoped maintenance task into access across an organisation's source code, deployments, data, or billing. Start with a bounded workspace and a clear task, keep durable service keys out of prompts and repository files, and give the agent a separate identity with access tailored to the branch, project, environment, and action that actually need automation.

## Why does Codex need scoped service credentials?

Codex tasks can be autonomous and extended, so a credential may be used later in a workflow after the initial request has changed shape. GitHub, Vercel, Stripe, Supabase, and similar services should not be exposed with account-wide authority merely because an agent needs one narrow operation. Use provider-side scopes to constrain the repository, project, database, or environment first, then use Gazebo to associate the resulting credential path with a Codex profile. That profile makes retrieval auditable and independently revocable when a task ends, an agent behavior is unexpected, or access needs to be handed off. It does not remove the need for pull-request review, branch protection, deployment approval, secret scanning, or careful review of instructions embedded in issues and repository content. Least privilege limits the blast radius; operational review decides whether an action should happen.

## How it works

1. Connect the services relevant to the task and prepare credentials with the smallest practical provider-side boundary, such as a fine-grained repository token, a single deployment project, or staging-only database access.
2. Create a Codex access profile for the task, branch, project, or sprint. Separate diagnostic read access from write-capable release access, and do not combine unrelated clients or environments in one profile.
3. Configure Codex to use Gazebo's MCP endpoint for credential retrieval. Keep the endpoint bearer token in the intended agent configuration and keep raw service keys out of prompts, committed settings, shell history, and generated test output.
4. When a configured tool needs service access, Codex calls get_credential. Gazebo validates the profile and logs the retrieval, so service credentials are obtained through a named agent boundary instead of ambient environment access.
5. Review the credential history with the agent task, diff, test and CI results, provider audit trail, and deployment outcome. Revoke the profile as soon as the task is done or if its requested scope changes; issue a new, explicit profile for follow-up work.

## Use cases

**Repository-scoped GitHub access:** Use a fine-grained GitHub credential limited to the repositories Codex is meant to inspect or change, and grant only the contents, pull-request, or checks permissions required. A review task may be read-only; opening a pull request is a separate permission. Preserve normal branch rules so the agent cannot turn repository access into an unreviewed protected-branch change.

**Task-scoped credentials:** Create a profile for a defined maintenance task, migration, or sprint rather than treating the agent as a permanent employee account. Name the profile so its owner, repository, environment, and intended capability are evident. When the work ends, revoke it; a later task must justify its own access instead of inheriting yesterday's permissions.

**Audit long-running agent tasks:** For a long run, correlate the timestamped credential retrievals with the task transcript, commits, CI logs, deployment events, and provider audit records. This makes it possible to distinguish what Codex was permitted to request from the API actions a tool actually completed. On a suspicious request, revoke first, preserve the evidence, and inspect the instructions and changed code before resuming.

**Separate implementation from release authority:** Let Codex prepare code, tests, and a deployment plan with a profile suited to implementation, but keep production release permissions in a separate profile and approval step. Check the target repository, branch, project, and environment before issuing that second access path. This reduces the chance that an ambiguous task or a tool instruction turns a successful code edit directly into a production release.

**Primary integrations:** github, vercel, stripe, supabase