Action GitHub Codex

Utilisez l’action GitHub Codex (openai/codex-action@v1) pour exécuter Codex dans des tâches CI/CD, appliquer des correctifs ou publier des revues depuis un workflow GitHub Actions. L’action installe la CLI Codex, démarre le proxy de la Responses API lorsque vous fournissez une API key, puis exécute codex exec avec les autorisations que vous spécifiez.

Utilisez cette action lorsque vous souhaitez :

• Automatiser les retours de Codex sur les pull requests ou les versions sans avoir à gérer vous-même la CLI.
• Conditionner les modifications à des contrôles qualité pilotés par Codex dans le cadre de votre pipeline CI.
• Exécuter des tâches Codex reproductibles (revue de code, préparation d’une version, migrations) depuis un fichier de workflow.

Pour consulter un exemple de CI, reportez-vous au Mode non interactif et explorez le code source dans le dépôt openai/codex-action.

Prérequis

• Stockez votre clé OpenAI comme secret GitHub (par exemple OPENAI_API_KEY) et référencez-la dans le workflow.
• Exécutez la tâche sur un runner Linux ou macOS. Sous Windows, définissez safety-strategy: unsafe.
• Récupérez votre code avant d’appeler l’action afin que Codex puisse lire le contenu du dépôt.
• Déterminez les prompts que vous souhaitez exécuter. Vous pouvez fournir du texte directement avec prompt ou indiquer un fichier versionné dans le dépôt avec prompt-file.

Exemple de workflow

L’exemple de workflow ci-dessous examine les nouvelles pull requests, récupère la réponse de Codex et la publie sur la PR.

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 votre propre fichier de prompt ou utilisez l’entrée prompt pour fournir du texte directement. L’exemple écrit également le dernier message de Codex dans codex-output.md afin de pouvoir l’examiner ultérieurement ou le charger comme artefact.

Configurer codex exec

Ajustez précisément l’exécution de Codex en définissant les entrées de l’action qui correspondent aux options de codex exec :

• prompt ou prompt-file (choisissez-en une) : instructions fournies directement ou chemin dans le dépôt vers un fichier Markdown ou texte décrivant votre tâche. Envisagez de stocker les prompts dans .github/codex/prompts/.
• codex-args : options supplémentaires de la CLI. Fournissez un tableau JSON (par exemple ["--ephemeral"]) ou une chaîne shell (--profile ci) pour configurer les sessions, les profils ou les paramètres MCP.
• model et effort : choisissez la configuration de l’agent Codex souhaitée ; laissez ces champs vides pour utiliser les valeurs par défaut.
• sandbox : adaptez le mode sandbox (workspace-write, read-only, danger-full-access) aux autorisations dont Codex a besoin pendant l’exécution.
• output-file : enregistrez le dernier message de Codex sur le disque afin que les étapes suivantes puissent le charger ou le comparer.
• codex-version : épinglez une version précise de la CLI. Laissez ce champ vide pour utiliser la dernière version publiée.
• codex-home : indiquez un répertoire d’accueil Codex partagé si vous souhaitez réutiliser des fichiers de configuration ou des installations MCP entre plusieurs étapes.

Gérer les privilèges

Codex dispose d’un accès étendu sur les runners hébergés par GitHub, sauf si vous le limitez. Utilisez les entrées suivantes pour contrôler son exposition :

• safety-strategy (valeur par défaut : drop-sudo) supprime sudo avant d’exécuter Codex. Cette opération est irréversible pour la tâche et protège les secrets en mémoire. Sous Windows, vous devez définir safety-strategy: unsafe.
• unprivileged-user associe safety-strategy: unprivileged-user à codex-user pour exécuter Codex sous un compte précis. Assurez-vous que l’utilisateur peut lire et modifier le dépôt récupéré (consultez l’exemple unprivileged-user pour corriger les droits de propriété).
• read-only empêche Codex de modifier des fichiers ou d’utiliser le réseau, mais Codex s’exécute toujours avec des privilèges élevés. Ne comptez pas uniquement sur read-only pour protéger les secrets.
• sandbox limite l’accès au système de fichiers et au réseau dans Codex lui-même. Choisissez l’option la plus restrictive permettant tout de même de terminer la tâche.
• allow-users et allow-bots limitent les personnes autorisées à déclencher le workflow. Par défaut, seuls les utilisateurs disposant d’un accès en écriture peuvent exécuter l’action ; répertoriez explicitement les autres comptes de confiance ou laissez le champ vide pour conserver le comportement par défaut.

Récupérer les sorties

L’action expose le dernier message de Codex via la sortie final-message. Associez-la à une sortie de tâche (comme dans l’exemple ci-dessus) ou traitez-la directement lors d’étapes ultérieures. Associez output-file à la fonctionnalité de chargement d’artefacts si vous préférez récupérer la transcription complète depuis le runner. Lorsque vous avez besoin de données structurées, transmettez --output-schema au moyen de codex-args afin d’imposer une structure JSON.

Liste de contrôle de sécurité

• Limitez les personnes autorisées à démarrer le workflow. Privilégiez les événements de confiance ou les approbations explicites plutôt que d’autoriser tout le monde à exécuter Codex sur votre dépôt.
• Nettoyez les entrées de prompt provenant des pull requests, des messages de commit ou du contenu des issues afin d’éviter les injections de prompt. Examinez les commentaires HTML ou le texte masqué avant de les transmettre à Codex.
• Protégez votre OPENAI_API_KEY en maintenant safety-strategy sur drop-sudo ou en exécutant Codex sous un utilisateur sans privilèges. Ne laissez jamais l’action en mode unsafe sur des runners mutualisés.
• Exécutez Codex comme dernière étape d’une tâche afin que les étapes suivantes n’héritent d’aucun changement d’état inattendu.
• Renouvelez immédiatement les clés si vous pensez que les journaux du proxy ou la sortie de l’action ont exposé des données secrètes.

Résolution des problèmes

• Vous avez défini à la fois le prompt et le fichier de prompt : supprimez l’entrée en double afin de ne fournir qu’une seule source.
• responses-api-proxy n’a pas écrit les informations du serveur : vérifiez que l’API key est présente et valide ; le proxy ne démarre que lorsque vous fournissez openai-api-key.
• Vous attendiez la suppression de sudo, mais sudo a réussi : assurez-vous qu’aucune étape antérieure n’a restauré sudo et que le système d’exploitation du runner est Linux ou macOS. Relancez une nouvelle tâche.
• Erreurs d’autorisation après drop-sudo : accordez l’accès en écriture avant l’exécution de l’action (par exemple avec chmod -R g+rwX "$GITHUB_WORKSPACE" ou en utilisant le modèle d’utilisateur sans privilèges).
• Déclenchement non autorisé bloqué : ajustez les entrées allow-users ou allow-bots si vous devez autoriser des comptes de service en plus des collaborateurs disposant par défaut d’un accès en écriture.