Codex sur GitHub : reviews de PR et actions

Codex peut relire des pull requests et s'exécuter dans GitHub Actions, si bien que chaque diff est lu automatiquement avant même qu'un humain ne l'ouvre. Codex passe ainsi du statut d'outil qu'on invoque à la main à celui de composant de votre pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète → : un reviewer qui commente le style, attrape les bugs évidents, signale les changements risqués et ne fatigue jamais à 23h un vendredi de déploiement.

Cette leçon met tout ça en place concrètement. Vous verrez les deux façons dont Codex se connecte à GitHub, un workflow propre qui relit chaque PR, les permissions de token exactement impliquées, et comment l'empêcher de vider votre budget en silence.

Deux façons pour Codex de rencontrer votre repo

Il existe deux voies d'intégration distinctes, et les confondre est à l'origine de la plupart des malentendus.

L'app GitHub Codex (managée). Vous installez Codex depuis le côté ChatGPT et connectez votre compte GitHub. Codex peut ensuite être assigné à des issues et des pull requests directement dans l'interface GitHub. Vous le mentionnez, il lit la PR, et il peut proposer des changements ou laisser des commentaires de review. C'est la voie sans effort : pas de YAML, pas de runner, OpenAI héberge l'exécution.

Codex CLI dans GitHub Actions (piloté par vous). Vous exécutez le Codex CLI comme une étape de votre propre workflow. C'est ce qu'il vous faut quand vous voulez le contrôle : prompts sur mesure, vos propres secrets, gating sur des chemins de fichiers précis, et une sortie qui alimente d'autres étapes. Le runner et la logique sont à vous.

L'app managée s'adopte plus vite. La voie Actions est celle qu'une équipe sérieuse met en production, parce que vous pouvez versionner la logique de review dans le repo lui-même et raisonner précisément sur ce qui s'exécute. Le reste de cette leçon se concentre sur la voie Actions.

Ce que « relire le diff » veut dire concrètement

Une pull request, c'est un diff plus du contexte. Quand Codex relit une PR dans Actions, le pattern utile est le suivant :

1. Le workflow se déclenche sur pull_request.
2. Une étape calcule le diff (les lignes modifiées, pas tout le repo).
3. Codex lit le diff avec un prompt de review.
4. Codex poste un commentaire sur la PR via l'APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → GitHub.

Le choix de conception décisif porte sur ce que vous donnez au modèle. Ne déversez pas tout le repository dans le contexte à chaque PR. C'est lent, coûteux et majoritairement du bruit. Donnez le diff, et éventuellement les fichiers qu'il touche. Le signal est dans ce qui a changé.

Un workflow propre qui relit chaque PR

Voici un workflow minimal et exécutable. Il tourne sur chaque PR, envoie le diff à Codex avec un prompt de review ciblé, et poste le résultat en un seul commentaire.

name: Codex PR Review
on:
  pull_request:
    types: [opened, synchronize]

permissions:
  contents: read
  pull-requests: write

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Compute diff
        run: |
          git diff origin/${{ github.base_ref }}...HEAD > pr.diff
          echo "Diff size: $(wc -l < pr.diff) lines"

      - name: Review with Codex
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: |
          npm install -g @openai/codex
          codex exec --skip-git-repo-check \
            "Review the changes in pr.diff. Flag bugs, security \
             issues, and missing tests. Be concise. If it looks \
             good, say so in one line." > review.md

      - name: Post comment
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: gh pr comment ${{ github.event.pull_request.number }} --body-file review.md

Quelques points à relever.

fetch-depth: 0 récupère tout l'historique pour que le git diff contre la branche de base fonctionne réellement. Sans ça, vous obtenez un clone superficiel et le diff casse.

codex exec lance Codex en mode non interactif, exactement ce qu'il faut en CI. Il lit le prompt, fait le travail, et sort. Le flag --skip-git-repo-check l'empêche de se plaindre de l'état du checkout sur le runner.

La dernière étape utilise gh, le CLI GitHub, préinstallé sur les runners hébergés par GitHub. gh pr comment poste la review. Aucune glu API sur mesure n'est nécessaire.

Les permissions de tokentokenUn token est l'unité de base de texte que traitent les modèles de langage : le plus souvent un fragment de mot, un mot entier ou un signe de ponctuation, plutôt qu'un simple caractère.Voir la définition complète →, précisément

Deux tokens différents sont en jeu, et les traiter de la même manière est une erreur de sécurité.

`GITHUB_TOKEN` est le token que GitHub génère automatiquement pour l'exécution du workflow. Sa portée est définie par le bloc permissions: en haut du fichier. Le bloc ci-dessus accorde :

• contents: read pour que le checkout puisse lire votre code.
• pull-requests: write pour que gh pr comment puisse poster.

C'est toute la surface d'exposition. Notez ce qui manque : pas de contents: write, pas de actions: write, rien qui permette au job de pousser du code ou de réécrire le repo. Accordez le jeu de permissions le plus étroit qui fasse fonctionner le job. Si votre workflow se contente de commenter, il n'a jamais besoin d'accès en écriture au code. La documentation des permissions de GitHub liste tous les scopes.

`OPENAI_API_KEY` est votre clé pour l'API OpenAI, stockée comme secret de repository ou d'organisation. Elle autorise les appels Codex et c'est elle qui est facturée. Elle n'a rien à voir avec les permissions GitHub ; c'est le credential côté modèle.

Gardez-les bien distincts : GITHUB_TOKEN contrôle ce que le job peut faire *à votre repo*, OPENAI_API_KEY contrôle ce qu'il peut faire *avec OpenAI* (et ce que ça coûte).

Rester en sécurité

La version dangereuse de ce pattern tourne sur pull_request_target avec des permissions d'écriture, puis exécute du code venant de la PR. Cette combinaison permet à un fork malveillant d'exécuter des commandes arbitraires avec vos secrets. Ne le faites pas.

Le workflow ci-dessus utilise pull_request, pas pull_request_target. Avec le trigger pull_request standard, les workflows issus de forks tournent avec un GITHUB_TOKEN en lecture seule et aucun accès à vos secrets, ce qui signifie que l'étape Codex est sautée pour les contributeurs externes. C'est le défaut sûr. Pour les PR internes issues de branches de votre propre repo, les secrets sont disponibles et la review s'exécute normalement.

Trois garde-fousgarde-fousRègles et contrôles qui maintiennent un système d'IA dans des limites sûres, légales et conformes à la marque, en bloquant les sorties et actions hors cadre.Voir la définition complète → supplémentaires :

• Ne laissez jamais le reviewer exécuter le code de la PR. Relire un diff comme du texte est sûr. Lancer les scripts de build ou les tests de la branche avec votre OPENAI_API_KEY dans l'environnement, c'est comme ça qu'arrivent les attaques sur la supply chain. Gardez review et exécution séparées.
• Pinnez vos actions. actions/checkout@v4 sur un tag, ça passe, mais pour tout ce qui est tierce partie, pinnez sur un SHA de commit complet afin qu'un tag compromis ne puisse pas injecter de code.
• Stockez la clé au niveau de l'organisation avec protection d'environnement si plusieurs repos la partagent, pour la faire tourner en un seul endroit.

Rester bon marché

Chaque PR qui déclenche ce workflow provoque un appel API, et les gros diffs signifient de gros volumes de tokens. Un repo avec un trafic de PR important peut générer un coût réel si vous êtes négligent. Contrôlez-le sur trois niveaux.

Filtrez ce qui déclenche. Ne tournez que sur les branches et les chemins qui comptent. Sautez les changements de docs ou de fichiers générés :

on:
  pull_request:
    types: [opened, synchronize]
    paths:
      - "src/**"
      - "!**/*.md"

Désormais, une PR qui ne touche que du markdown ne dépense pas un token.

Plafonnez le diff que vous envoyez. Un refactoring de 4 000 lignes n'a pas besoin d'un commentaire de review en contexte complet ; le diff lui-même est le bruit. Tronquez ou rejetez les diffs trop gros avant que le modèle ne les voie :

if [ "$(wc -l < pr.diff)" -gt 800 ]; then
  echo "Diff too large for automated review; skipping." > review.md
  exit 0
fi

Debouncez sur `synchronize`. L'événement synchronize se déclenche à chaque push sur la branche de la PR. Si quelqu'un pousse dix commits en une minute, vous obtenez dix reviews. Utilisez concurrency pour annuler les exécutions dépassées, afin que seul le dernier push soit relu :

concurrency:
  group: codex-review-${{ github.event.pull_request.number }}
  cancel-in-progress: true

Ce seul bloc réduit souvent de plus de moitié la dépense sur les PR actives, parce que vous cessez de payer pour relire du code remplacé quelques secondes plus tard.

Aller plus loin qu'un simple commentaire

Un commentaire à plat est le point de départ. Une fois la plomberie en place, **les mouvements intéressants portent sur *où va la sortie* et *à quel point elle est structurée***.

Commentaires de review inline. Au lieu d'un commentaire unique sur la PR, vous pouvez poster des commentaires sur des lignes précises via l'API de review GitHub. Cela suppose de remapper les constats de Codex vers des chemins de fichiers et des numéros de ligne, et c'est là que les structured outputs prouvent leur valeur : faites renvoyer au modèle du JSON avec des champs path, line et comment, puis bouclez dessus et postez chacun avec gh api. Vous avez déjà croisé les structured outputs dans le bloc API ; c'est un bon endroit pour les appliquer, parce que « laisse un commentaire à la ligne 42 de auth.py » n'est actionnable que si le modèle vous donne le numéro de ligne sous une forme parsable.

Gating du merge. Un commentaire de review est consultatif. Si vous voulez des dents, faites sortir le job avec un code non nul quand Codex signale quelque chose de critique, et marquez le check comme requis dans la branch protection. Soyez conservateur ici : un reviewer qui bloque les merges sur des chicaneries de style est désactivé en une semaine. Ne bloquez que sur les catégories qui vous importent vraiment, comme un pattern de secret fuité ou un test supprimé.

Alimenter un contexte plus riche, de façon sélective. Pour une PR qui touche un seul module, inclure la totalité du source de ce module (pas tout le repo) donne à Codex assez de contexte pour attraper le « tu as changé la signature de la fonction mais pas ses appelants ». La règle tient : élargissez le contexte délibérément, selon les fichiers modifiés, jamais en bloc.

Quand utiliser plutôt l'app managée

Si votre équipe est petite et que vous voulez surtout un second avis compétent sur les PR sans maintenir de YAML, l'app GitHub Codex managée est le meilleur choix. Vous assignez Codex à une PR et il relit. Vous perdez le contrôle fin sur les prompts, le gating et les filtres de coût, mais vous gagnez en simplicité, et OpenAI gère le runner.

Optez pour la voie Actions dès que vous avez besoin de l'un de ces éléments : critères de review sur mesure versionnés dans le repo, intégration avec d'autres étapes de CI, contrôles de coût stricts, ou gestion cloisonnée de quels secrets touchent quels jobs. La plupart des équipes commencent avec l'app et passent à Actions quand la logique de review devient quelque chose qu'elles veulent posséder et régler.

Points clés

• Utilisez le trigger `pull_request`, pas `pull_request_target`, pour que les PR issues de forks tournent sans vos secrets. N'exécutez jamais le code d'une PR dans un job qui détient votre OPENAI_API_KEY.
• Réduisez `GITHUB_TOKEN` au minimum : contents: read et pull-requests: write suffisent pour relire et commenter. Gardez-le mentalement distinct de OPENAI_API_KEY, qui pilote le coût.
• Envoyez le diff, pas le repo. Filtrez les triggers par chemin, plafonnez les diffs trop gros avant l'appel API, et ajoutez un bloc concurrency pour annuler les exécutions dépassées lors de pushes rapides.
• Utilisez les structured outputs (JSON avec chemin et ligne) quand vous voulez des commentaires de review inline plutôt qu'un pavé de synthèse.
• Commencez avec l'app Codex managée ; passez à Actions quand vous avez besoin d'une logique de review versionnée, de gating de merge ou d'un contrôle de coût serré.