À la fin, Codex CLI sait faire deux choses sur un dépôt GitNest dans osFoundry. Il écrit sur une branche des fichiers issus de votre session de terminal, et il sort un change set terminé sous forme de pull request, soit dans GitNest, soit en brouillon sur GitHub ou GitLab. Codex ne commite et ne pousse rien lui-même. Chaque tâche arrive sous forme de carte dans "Needs your approval" sur la connexion Codex CLI, avec les fichiers, la branche ou le commit exact affichés dessus. Rien ne se passe tant que le propriétaire du dépôt n'a pas cliqué.
Qui fait quoi
| Codex CLI | osFoundry | |
|---|---|---|
| Connexion | Votre compte Codex. Codex détient un jeton OAuth osFoundry avec osfoundry:read et osfoundry:write
|
Le propriétaire a approuvé la connexion une seule fois, dans l'onglet Connected |
| Ce qu'il peut envoyer | Jusqu'à 20 fichiers UTF-8, 200 KB au total, pour une branche. Ou un ID de change set épinglé à une version et à un commit composé | Enregistre chaque demande comme une proposition avec une date d'expiration |
| Qui approuve | Codex vous demande avant chaque appel en écriture (default_tools_approval_mode = "writes") |
Le propriétaire de la connexion clique sur Approve and create, ou Approve and publish, tant qu'il a toujours son rôle sur le dépôt |
| Qui écrit | Personne côté Codex | osFoundry crée le commit, ou ouvre la pull request, après approbation |
| Jetons du fournisseur | Jamais envoyés | Le compte GitHub ou GitLab lié du propriétaire sert au moment de l'approbation, uniquement pour la branche propre au change set |
| Merge | Hors de portée | Reste entre les mains des humains, dans GitNest ou chez le fournisseur |
Mise en place
1. Restreindre Codex aux outils GitNest
La connexion se crée comme d'habitude : l'icône de clé dans l'en-tête, l'onglet Connected, Other MCP client, et un nom d'affichage comme Codex CLI. Ce nom apparaît sur chaque carte et chaque notification, alors choisissez-en un que le propriétaire reconnaîtra.
Côté Codex :
codex mcp add osfoundry --url https://api.osfoundry.io/api/v1/external-mcp
# ~/.codex/config.toml
[mcp_servers.osfoundry]
url = "https://api.osfoundry.io/api/v1/external-mcp"
scopes = ["osfoundry:read", "osfoundry:write"]
default_tools_approval_mode = "writes"
enabled_tools = [
"list_granted_resources",
"read_gitnest_repository",
"list_gitnest_work",
"list_gitnest_checks",
"propose_gitnest_file_import",
"propose_gitnest_native_publication",
"propose_gitnest_provider_publication",
]
codex mcp login osfoundry
Le serveur expose 59 outils. Ce tutoriel n'a besoin que de ces sept-là. Les trois outils propose_ sont les seuls qui ne sont pas marqués en lecture seule : avec "writes", Codex lance donc les quatre outils de lecture tout seul et s'arrête pour vous demander avant chaque proposition. Cela fait deux approbations à la suite : la vôtre dans le terminal, puis celle du propriétaire dans osFoundry. Si c'est vous le propriétaire, la première sert juste à vérifier que Codex s'apprête à demander ce que vous vouliez.
2. Placer le dépôt dans un projet où se trouve la connexion
Une connexion ne voit un dépôt GitNest qu'à travers un projet. Dans GitNest, ouvrez le dépôt et repérez la section Project. Seul le propriétaire du dépôt a le sélecteur. Choisissez le projet, et le toast affiche "Repository project updated". Ensuite, dans l'onglet Connected, sélectionnez Codex CLI et, sous Projects, cliquez sur Add to project pour ce même projet.
L'import de fichiers demande en plus un dépôt GitNest natif, c'est-à-dire dont le Git vit dans osFoundry. La description de l'outil le dit clairement : "Repository GitNest must be enabled." Un dépôt qui ne fait que refléter GitHub passe plutôt par le change set et la publication chez le fournisseur.
3. Pour GitHub ou GitLab, lier le compte du fournisseur
propose_gitnest_provider_publication pousse avec le compte Git lié du propriétaire, au moment où le propriétaire approuve. Si aucun compte n'est lié, cette approbation n'a rien avec quoi pousser. Codex n'a jamais besoin d'un jeton GitHub pour tout ça.
Un vrai déroulé
Codex n'est pas installé sur la machine où cet article a été écrit, donc la session ci-dessous est un Example simulé. Les noms d'outils et d'arguments viennent du tools/list du serveur en production, avec le préfixe mcp__osfoundry__ que Codex ajoute. Le dépôt, les fichiers, les IDs et les réponses sont du contenu de démonstration.
Example (simulated)
> shop-api has no CI. In osFoundry, put a GitHub Actions workflow that runs
`make test` on pull requests, plus the Makefile target, on a branch
codex/ci-workflow.
• mcp__osfoundry__list_granted_resources {}
← project "Checkout" · GitNest repository "shop-api"
• mcp__osfoundry__read_gitnest_repository {"repository_id": "…"}
← native, GitNest enabled, default branch main
• mcp__osfoundry__propose_gitnest_file_import {
"repository_id": "…", "branch": "codex/ci-workflow",
"message": "Add CI workflow and make test target",
"files": [
{"path": ".github/workflows/ci.yml", "content": "name: ci\non: [pull_request]\n…"},
{"path": "Makefile", "content": "test:\n\tpython -m pytest -q\n"}],
"idempotency_key": "codex-shop-api-ci-0001"}
[Codex asks: allow this tool call? → yes]
← proposal waiting for the owner
I prepared one commit for shop-api on codex/ci-workflow with two files.
Nothing is committed yet. The owner approves it in osFoundry.
Dans osFoundry, la cloche affiche "Codex CLI proposes GitNest file changes". Sur le panneau de la connexion, la carte indique "Commit GitNest files in shop-api", puis "Commit to branch: codex/ci-workflow" et le message de commit. "Review all proposed files (2)" déplie le texte complet de chaque fichier, pas un résumé du diff. Approve and create crée le commit. Decline l'abandonne.
Exemple : la carte Commit GitNest files pour shop-api avec les deux fichiers proposés dépliés
Plus tard dans la journée, avec un change set déjà composé dans GitNest :
Example (simulated)
> Is the "Add CI workflow" change set green? If so, open it on GitHub as a draft PR.
• mcp__osfoundry__list_gitnest_work {"repository_id": "…", "kind": "changes"}
← "Add CI workflow" · version 3
• mcp__osfoundry__list_gitnest_checks {"repository_id": "…", "change_set_id": "…"}
← composed commit 73e59f27bc4f…: unit passed · lint passed
• mcp__osfoundry__propose_gitnest_provider_publication {
"repository_id": "…", "change_set_id": "…",
"expected_change_set_version": 3,
"expected_composition_oid": "73e59f27bc4f…",
"idempotency_key": "codex-shop-api-ci-pr-0001"}
[Codex asks: allow this tool call? → yes]
← proposal waiting for the owner
Both checks passed on the composed commit. I asked for a draft GitHub PR of
version 3; it opens when the owner approves it in osFoundry.
Codex ne choisit ni la branche, ni le titre, ni la cible de la pull request. Le schéma n'accepte que le change set, la version qu'il a lue et le commit composé qu'il a lu. Demander draft: false ou un autre target_branch est refusé avant même que la demande n'arrive à quelqu'un.
La carte s'intitule "Open a draft GitHub or GitLab pull request in shop-api". Elle affiche "Change set: … · expected version 3", "Reviewed commit: 73e59f27bc4f…", un lien "Review change set before approving" et une ligne qui explique ce que fait l'approbation : elle "uses your linked Git provider account to push this change-set branch and open a draft pull request". Le bouton est Approve and publish. Pour un dépôt qui vit dans GitNest, propose_gitnest_native_publication produit la carte jumelle, "Publish GitNest pull request", qui "creates a publication branch and opens a pull request in this native repository".
Exemple : une carte de pull request chez le fournisseur et une carte de publication native dans Needs your approval
Le lien de la carte ouvre le change set dans GitNest. Les checks de son commit composé sont en haut, au-dessus des onglets de revue, pour que le propriétaire voie ce que Codex a vu avant de trancher.
Où passe la limite
Un import de fichiers ne transporte que du texte. Chaque entrée est un chemin et son contenu complet, rien d'autre. Pas de mode de fichier, pas de suppression, pas de binaire, et le commit entier reste dans la limite de 20 fichiers et 200 KB. Comme ça, chaque octet reste lisible sur la carte. L'upload que le propriétaire fait lui-même depuis son navigateur dans GitNest va beaucoup plus loin (2,000 fichiers, 8 MB chacun, 32 MB au total), parce que là, c'est une personne qui commite ses propres fichiers.
La publication part d'un change set composé, pas d'une branche choisie par Codex. La carte fige la version et le commit que Codex a regardés. Si le change set est recomposé avant le clic, la nouvelle vérification d'osFoundry refuse la proposition au lieu de publier quelque chose que personne n'a relu. À l'approbation, elle vérifie aussi les permissions actuelles, les niveaux de risque et les checks obligatoires du dépôt, ainsi que la cible. Ces règles sont fixées par des humains dans GitNest, sous Risk tiers et Required checks, et Codex ne peut pas y toucher.
Sur GitHub ou GitLab, seule la branche propre au change set bouge. La pull request s'ouvre en brouillon, et le push passe par le compte lié du propriétaire au moment de l'approbation. Codex ne voit jamais ce jeton, et vos autres branches ne font pas partie du push.
Le merge n'est pas sur la liste. Aucune de ces propositions ne va plus loin qu'une pull request ouverte. Qui la merge, et tout ce qu'un merge déclenche, reste du ressort des personnes du dépôt.
Les deux outils de publication portent openWorldHint: true dans tools/list, l'import de fichiers non. Une pull request est visible par des gens extérieurs à la conversation. Un client bien conçu y voit une raison de demander d'abord, comme le fait Codex ici.
Pour la suite, essayez l'import sur une branche que personne n'utilise encore. Demandez à Codex de proposer un seul nouveau fichier, un CONTRIBUTING.md ou un workflow de CI, ouvrez "Review all proposed files" sur la carte et approuvez. La page GitNest explique comment les change sets, les checks et la publication s'articulent côté dépôt.
Top comments (0)