Roster for Codex

Give Codex live organizational context around the code.

Connect Codex to Roster over MCP so it can resolve who owns, reviews, approves, handles, or receives an escalation for engineering work.

Codex understands the repository. Roster resolves who should act around it.

Connect Roster to Codex Read the setup guide

Last verified 07/13/2026

Repository context cannot answer every ownership question

Codex can inspect code, modify files, run commands, and help complete engineering tasks.

But many decisions depend on organizational context outside the repository:

“Who owns this service today?”

“Who should approve the deployment?”

“Who reviews changes to authentication?”

“Who handles this customer escalation?”

“Who is covering for the release owner?”

That information may live across:

Roster projects
Directory users and groups
Business roles
Service ownership models
Regional responsibilities
Approval policies
Temporary delegations

Roster makes that context available through the same MCP standard Codex uses to connect to external tools and systems.

What Codex can resolve

OpenAI's current Codex documentation supports Streamable HTTP MCP servers with bearer-token or OAuth authentication. Roster plugs in as one of those servers.

Codex
   ↓ Streamable HTTP MCP
Roster
   ↓
Project + service ownership
   ↓
Directory users, groups, and roles
   ↓
Active memberships + delegations
   ↓
Resolved owner, reviewer, approver, or escalation contact

What Codex can resolve around the code

Component or service ownership

Look up the current owner of a service or component from the Roster participant model.

“Use Roster to find who owns the identity service.”

Review responsibility

Route review requests to the participant responsible for a specific area of the codebase.

“Who should review this change to authentication logic?”

Deployment approval

Resolve the approver for a production release based on project, environment, and delegation.

“Who should approve the Atlas production release?”

Security escalation

Route dependency vulnerabilities and security findings to the right owner.

“Which participant should receive this dependency vulnerability escalation?”

Cross-functional review

Pull in security, procurement, or legal reviewers when the change requires them.

“Who should review this third-party library from security and procurement?”

Delegated coverage

Fall back to the active delegate when the normal owner is unavailable.

“Who is covering for the platform release owner?”

Connect Roster to Codex

Add the Roster MCP server to your Codex configuration and authenticate the acting identity.

Add the Roster MCP server:

codex mcp add roster --url https://roster.example.com/mcp

Confirm the configuration:

codex mcp list

For OAuth login:

codex mcp login roster

You can also configure the server directly in ~/.codex/config.toml:

[mcp_servers.roster]
url = "https://roster.example.com/mcp"

Restart Codex after changing MCP configuration and verify the connection through its MCP interface. Roster's current Codex guide supports connection through the Codex CLI, Codex UI, or ~/.codex/config.toml.

API-key mode for automation — use a scoped Roster API key for non-interactive Codex workflows that should not launch an OAuth browser flow:

export ROSTER_MCP_BEARER_TOKEN="rst_..."

[mcp_servers.roster]
url = "https://roster.example.com/mcp"
bearer_token_env_var = "ROSTER_MCP_BEARER_TOKEN"

Resolve-only automation scope

For resolve-only workflows, use narrow scopes. The key belongs to a Roster identity and remains constrained by that identity's Roster permissions and target-resource rules.

mcp:resolve
mcp:resolve-requests:read
mcp:projects:read
mcp:participants:read

Add a Roster skill

Making the MCP tools available does not ensure that Codex will use them whenever organizational context is required. Package a Roster skill with instructions.

---
name: roster
description: Use live Roster MCP for approval routing, ownership,
  participants, delegated contacts, project membership, labels, and recent
  Resolve request retrieval. Use when the user asks who should approve,
  handle, review, own, or be contacted for a business or engineering task.
---

# Roster

Use live Roster MCP as the source of truth for current ownership and
routing answers.

Do not reconstruct current approvers or owners from repository files,
memory, or stale examples when Roster is available.

## Workflow

1. For open-ended ownership, approval, review, or escalation questions,
   call Roster `resolve`.

2. For exact project, participant, label, delegation, or membership
   checks, use the matching Roster lookup tools.

3. Include active delegations where applicable.

4. State clearly when no result is found or the request is outside the
   connected identity's scope.

5. Return only the requested names, groups, roles, or contact details.

Codex can use skills to help select the correct workflow for a task, and Roster's documentation recommends distributing the Roster behavior through a skill or Codex plugin.

Example: resolve a deployment approver

A developer asks:

“Review this release and determine who must approve the Atlas production deployment.”

Codex reviews the repository and release changes.
Codex determines that organizational approval is required.

Codex calls Roster:

resolve(
  query: "Who should approve the Atlas production deployment?"
)

Roster evaluates the Atlas project, the release-approval participant, relevant labels and metadata, associated directory users or groups, active membership, and current delegations.
Codex returns the selected approver.

Codex or another connected system can then create a review request, ticket, pull-request comment, or approval task.

Roster complements engineering ownership systems

Roster does not need to replace CODEOWNERS, GitHub or GitLab teams, Backstage, service catalogs, incident-management platforms, or project-management systems. Those systems can provide static or platform-specific ownership.

Roster adds runtime resolution when the answer depends on current project context, directory membership, business role, geography, approval threshold, active status, delegation, or cross-functional responsibility.

Project context
Directory membership
Business role
Geography
Approval threshold
Active status
Delegation
Cross-functional responsibility

Security and governance

Identity attribution

Every agent or service account should act through its own Roster identity.

Least privilege

Grant only the scopes required for the workflow.

Project boundaries

MCP scopes do not bypass project and resource-level authorization.

Controlled context

Send only the business context needed for the routing decision.

Explicit failure handling

Treat no-result, ambiguity, and authorization failure as workflow states rather than opportunities for the agent to guess.

Auditable requests

Use Resolve history and available audit capabilities to inspect how organizational decisions were made.

Frequently asked questions

No — Codex connects through OpenAI's Codex CLI and config, while Claude connects through Claude's custom connector settings in Claude Desktop, Claude.ai, or Cowork. The setup steps differ, but both use the same Roster MCP server and `resolve` tool underneath.

Connect Codex to current organizational ownership

Let Codex work with the code while Roster resolves the people, groups, roles, and delegates responsible for what happens next.

Connect Roster to Codex Read the Codex setup guide Explore all integrations