GitHub Action pour Codex

Utilisez la GitHub Action pour Codex (openai/codex-action@v1) pour exécuter Codex dans des jobs de CI/CD, appliquer des correctifs ou publier des revues de code depuis un workflow GitHub Actions. L’action installe la CLI de Codex, démarre le proxy de l’API Responses si vous fournissez une clé API, puis exécute codex exec avec les autorisations que vous avez définies.

Utilisez cette action pour :

• Automatiser les retours de Codex sur les pull requests ou les versions publiées sans avoir à gérer vous-même la CLI.
• Conditionner l’acceptation des modifications à la réussite des contrôles qualité effectués par Codex dans votre pipeline de CI.
• Exécuter des tâches Codex de manière reproductible (revue de code, préparation de versions, migrations) depuis un fichier de workflow.

Pour un exemple de CI, consultez la page Mode non interactif. Vous trouverez le code source dans le dépôt openai/codex-action.

Prérequis

• Enregistrez votre clé OpenAI dans un secret GitHub (par exemple OPENAI_API_KEY) et référencez ce secret dans le workflow.
• Exécutez le job sur un runner Linux ou macOS. Sur Windows, définissez safety-strategy: unsafe.
• Récupérez une copie de votre code avant de lancer l’action pour que Codex puisse lire le contenu du dépôt.
• Choisissez les prompts à exécuter. Vous pouvez saisir le texte directement dans prompt ou indiquer dans prompt-file le chemin d’un fichier versionné dans le dépôt.

Exemple de workflow

Le workflow ci-dessous examine les nouvelles pull requests, récupère la réponse de Codex et la publie en commentaire sur la pull request concernée.

name: Codex pull request review
on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  codex:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    outputs:
      final_message: ${{ steps.run_codex.outputs.final-message }}
    steps:
      - uses: actions/checkout@v5
        with:
          ref: refs/pull/${{ github.event.pull_request.number }}/merge
          fetch-depth: 0
          persist-credentials: false

      - name: Run Codex
        id: run_codex
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          prompt-file: .github/codex/prompts/review.md
          output-file: codex-output.md

  post_feedback:
    runs-on: ubuntu-latest
    needs: codex
    if: needs.codex.outputs.final_message != ''
    permissions:
      issues: write
      pull-requests: write
    steps:
      - name: Post Codex feedback
        uses: actions/github-script@v7
        with:
          github-token: ${{ github.token }}
          script: |
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.payload.pull_request.number,
              body: process.env.CODEX_FINAL_MESSAGE,
            });
        env:
          CODEX_FINAL_MESSAGE: ${{ needs.codex.outputs.final_message }}

Remplacez .github/codex/prompts/review.md par le chemin de votre fichier de prompt ou utilisez le paramètre prompt pour saisir le texte directement. Cet exemple enregistre aussi le message final de Codex dans codex-output.md pour que vous puissiez le consulter plus tard ou le publier comme artefact.

Configurez codex exec

Pour ajuster le comportement de Codex, définissez les paramètres de l’action qui correspondent aux options de codex exec :

• prompt ou prompt-file (choisissez l’un des deux) : saisissez directement les instructions ou indiquez le chemin, dans le dépôt, d’un fichier Markdown ou texte qui décrit la tâche. Vous pouvez regrouper vos prompts dans .github/codex/prompts/.
• codex-args : ajoutez des options de la CLI. Fournissez un tableau JSON (par exemple ["--ephemeral"]) ou une chaîne interprétée par le shell (--profile ci) pour configurer les sessions, les profils ou les paramètres MCP.
• model et effort : choisissez la configuration de l’agent Codex. Laissez ces paramètres vides pour utiliser les valeurs par défaut.
• sandbox : choisissez le mode du bac à sable (workspace-write, read-only, danger-full-access) en fonction des autorisations dont Codex a besoin pour exécuter la tâche.
• output-file : enregistrez le message final de Codex sur disque pour que les étapes suivantes puissent le publier ou le comparer à une autre version.
• codex-version : fixez la version de la CLI à utiliser. Laissez ce paramètre vide pour utiliser la dernière version publiée.
• codex-home : indiquez un répertoire personnel Codex partagé pour réutiliser les fichiers de configuration ou les configurations MCP d’une étape à l’autre.

Gérez les privilèges

Sur les runners hébergés par GitHub, Codex dispose de droits d’accès étendus si vous ne les limitez pas. Utilisez les paramètres suivants pour restreindre ces accès :

• safety-strategy (par défaut drop-sudo) supprime sudo avant d’exécuter Codex. Cette suppression est irréversible pour toute la durée du job et protège les secrets en mémoire. Sur Windows, vous devez définir safety-strategy: unsafe.
• unprivileged-user : associez safety-strategy: unprivileged-user à codex-user pour exécuter Codex sous un compte précis. Vérifiez que ce compte dispose des droits de lecture et d’écriture sur la copie locale du dépôt (consultez l’exemple unprivileged-user pour savoir comment changer le propriétaire des fichiers).
• read-only empêche Codex de modifier les fichiers ou d’accéder au réseau, mais Codex conserve des privilèges élevés. Ne comptez pas uniquement sur read-only pour protéger les secrets.
• sandbox limite l’accès de Codex au système de fichiers et au réseau. Choisissez l’option la plus restrictive qui permette de mener la tâche à bien.
• allow-users et allow-bots limitent les comptes qui peuvent déclencher le workflow. Par défaut, seuls les utilisateurs disposant d’un accès en écriture peuvent exécuter l’action. Indiquez explicitement les autres comptes de confiance à autoriser ou laissez le champ vide pour conserver le comportement par défaut.

Récupérez les sorties

L’action renvoie le dernier message de Codex dans la sortie final-message. Associez cette valeur à une sortie du job, comme dans l’exemple ci-dessus, ou traitez-la directement dans les étapes suivantes. Pour récupérer la transcription complète depuis le runner, combinez output-file avec la fonctionnalité de publication d’artefacts. Si vous avez besoin de données structurées, passez --output-schema dans codex-args pour imposer un schéma JSON.

Liste de contrôle de sécurité

• Limitez les comptes autorisés à lancer le workflow. Privilégiez les événements de confiance ou les approbations explicites plutôt que de permettre à tout le monde d’exécuter Codex sur votre dépôt.
• Filtrez les données issues des pull requests, des messages de commit ou du corps des issues GitHub avant de les intégrer aux prompts afin d’éviter les attaques par injection de prompt. Examinez les commentaires HTML et le texte masqué avant de les transmettre à Codex.
• Protégez votre clé OPENAI_API_KEY en laissant le paramètre safety-strategy sur drop-sudo ou en exécutant Codex sous un compte sans privilèges. Ne laissez jamais l’action en mode unsafe sur des runners partagés entre plusieurs locataires.
• Exécutez Codex à la dernière étape du job pour éviter que des changements d’état inattendus se répercutent sur les étapes suivantes.
• Renouvelez immédiatement les clés si vous pensez que les journaux du proxy ou la sortie de l’action ont révélé des secrets.

Dépannage

• Vous avez renseigné à la fois prompt et prompt-file : supprimez l’un des deux paramètres pour fournir une seule source.
• responses-api-proxy n’a pas écrit les informations sur le serveur : vérifiez que la clé API est présente et valide. Le proxy démarre uniquement si vous fournissez openai-api-key.
• Vous attendiez la suppression de sudo, mais sudo a fonctionné : vérifiez qu’aucune étape précédente n’a rétabli sudo et que le runner utilise Linux ou macOS. Relancez l’exécution dans un nouveau job.
• Erreurs de permissions après drop-sudo : accordez les droits d’écriture avant l’exécution de l’action (par exemple avec chmod -R g+rwX "$GITHUB_WORKSPACE" ou en suivant l’exemple unprivileged-user).
• Déclenchement bloqué faute d’autorisation : ajustez allow-users ou allow-bots si vous devez autoriser des comptes de service en plus des collaborateurs déjà autorisés par défaut grâce à leur accès en écriture.