Roster pour Codex
Donnez à Codex un contexte organisationnel en direct autour du code.
Connectez Codex à Roster via MCP pour qu'il puisse déterminer qui est responsable de, révise, approuve, prend en charge ou reçoit une escalade pour un travail d'ingénierie.
Codex comprend le dépôt. Roster détermine qui doit agir autour.
Dernière vérification : 13 juillet 2026
Le contexte du dépôt ne répond pas à toutes les questions de propriété
Codex peut inspecter du code, modifier des fichiers, exécuter des commandes et aider à réaliser des tâches d'ingénierie.
Mais beaucoup de décisions dépendent d'un contexte organisationnel hors du dépôt :
“Qui est responsable de ce service aujourd'hui ?”
“Qui doit approuver le déploiement ?”
“Qui révise les changements sur l'authentification ?”
“Qui traite cette escalade client ?”
“Qui remplace le responsable de release ?”
Cette information peut être répartie entre :
- Projets Roster
- Utilisateurs et groupes d'annuaire
- Rôles métier
- Modèles de propriété de services
- Responsabilités régionales
- Politiques d'approbation
- Délégations temporaires
Roster rend ce contexte disponible via le même standard MCP que Codex utilise pour se connecter aux outils et systèmes externes.
Ce que Codex peut identifier
La documentation Codex actuelle d'OpenAI prend en charge les serveurs MCP Streamable HTTP avec authentification par jeton bearer ou OAuth. Roster se branche comme l'un de ces serveurs.
Codex
↓ MCP Streamable HTTP
Roster
↓
Propriété projet + service
↓
Utilisateurs, groupes et rôles d'annuaire
↓
Appartenances actives + délégations
↓
Propriétaire, réviseur, approbateur ou contact d'escalade résoluCe que Codex peut identifier autour du code
Connecter Roster à Codex
Ajoutez le serveur MCP Roster à votre configuration Codex et authentifiez l'identité agissante.
Ajouter le serveur MCP Roster :
codex mcp add roster --url https://roster.example.com/mcpConfirmer la configuration :
codex mcp listPour la connexion OAuth :
codex mcp login rosterVous pouvez aussi configurer le serveur directement dans ~/.codex/config.toml :
[mcp_servers.roster]
url = "https://roster.example.com/mcp"Redémarrez Codex après avoir modifié la configuration MCP et vérifiez la connexion via son interface MCP. Le guide Codex actuel de Roster prend en charge la connexion via la CLI Codex, l'UI Codex ou ~/.codex/config.toml.
Mode clé API pour l'automatisation — utilisez une clé API Roster à portée limitée pour les workflows Codex non interactifs qui ne doivent pas déclencher un flux OAuth navigateur :
export ROSTER_MCP_BEARER_TOKEN="rst_..."[mcp_servers.roster]
url = "https://roster.example.com/mcp"
bearer_token_env_var = "ROSTER_MCP_BEARER_TOKEN"Scope automatisation resolve-only
Pour des workflows resolve-only, utilisez des autorisations étroits. La clé appartient à une identité Roster et reste contrainte par ses permissions Roster et les règles de ressources cible.
mcp:resolve
mcp:resolve-requests:read
mcp:projects:read
mcp:participants:readAjouter une compétence Roster
Rendre les outils MCP disponibles ne garantit pas que Codex les utilisera à chaque fois qu'un contexte organisationnel est requis. Packagez une compétence Roster avec des instructions.
---
name: roster
description: Utilise le MCP Roster en direct pour le routage d'approbations,
la propriété, les participants, les contacts délégués, l'appartenance de
projet, les libellés et la récupération des requêtes Resolve récentes.
Utilise lorsque l'utilisateur demande qui doit approuver, prendre en charge,
réviser, posséder ou être contacté pour une tâche métier ou d'ingénierie.
---
# Roster
Utilise le MCP Roster en direct comme source de référence pour les réponses
actuelles de propriété et de routage.
Ne reconstruis pas les approbateurs ou propriétaires actuels à partir des
fichiers du dépôt, de la mémoire ou d'exemples obsolètes lorsque Roster est
disponible.
## Workflow
1. Pour les questions ouvertes de propriété, approbation, revue ou
escalade, appelle Roster `resolve`.
2. Pour les vérifications exactes de projet, participant, libellé,
délégation ou appartenance, utilise les outils Roster correspondants.
3. Inclus les délégations actives lorsque pertinentes.
4. Indique clairement lorsque aucun résultat n'est trouvé ou que la
demande est hors du périmètre de l'identité connectée.
5. Ne renvoie que les noms, groupes, rôles ou coordonnées demandés.Codex peut utiliser des compétences pour aider à sélectionner le workflow correct pour une tâche, et la documentation Roster recommande de distribuer le comportement Roster via une compétence ou un plugin Codex.
Exemple : identifier un approbateur de déploiement
Un développeur demande :
“Révise cette release et détermine qui doit approuver le déploiement production Atlas.”
- Codex passe en revue le dépôt et les changements de la release.
- Codex détermine qu'une approbation organisationnelle est requise.
- Codex appelle Roster :
resolve( query: "Qui doit approuver le déploiement production Atlas ?" ) - Roster évalue le projet Atlas, le participant d'approbation de release, les libellés et métadonnées pertinents, les utilisateurs ou groupes d'annuaire associés, l'appartenance active et les délégations en cours.
- Codex renvoie l'approbateur sélectionné.
Codex ou un autre système connecté peut ensuite créer une demande de revue, un ticket, un commentaire de pull-request ou une tâche d'approbation.
Roster complète les systèmes de propriété d'ingénierie
Roster n'a pas besoin de remplacer CODEOWNERS, les équipes GitHub ou GitLab, Backstage, les catalogues de services, les plateformes de gestion d'incidents ou les systèmes de gestion de projet. Ces systèmes peuvent fournir une propriété statique ou spécifique à la plateforme.
Roster ajoute une résolution runtime lorsque la réponse dépend du contexte projet actuel, de l'appartenance d'annuaire, du rôle métier, de la géographie, du seuil d'approbation, du statut actif, de la délégation ou de la responsabilité transverse.
- Contexte projet
- Appartenance d'annuaire
- Rôle métier
- Géographie
- Seuil d'approbation
- Statut actif
- Délégation
- Responsabilité transverse