OpenAI Codex in GitHub Actions: pull requests gecontroleerd beoordelen (2026)

Je kunt Codex een pull request in GitHub Actions laten beoordelen zonder het recht te geven om je repository te wijzigen of te mergen. Begin met een alleen-lezen reviewjob, beperk de trigger tot vertrouwde bijdragers en plaats feedback pas vanuit een aparte job met de minimaal noodzakelijke schrijfrechten.

Wanneer past Codex in GitHub Actions?

Deze route is voor een herhaalbare, geautomatiseerde review van een pull request in jouw CI. Dat is iets anders dan Codex lokaal gebruiken: daar stuur je een interactieve taak in een projectmap aan. Het is ook geen vervanging voor menselijke review, branch protection of tests.

Gebruik deze aanpak wanneer je een vaste tweede controle wilt op alleen de wijziging tussen de base- en head-ref. Voor een ontwikkeltaak die zelf bestanden mag aanpassen, begin je liever met ChatGPT voor code schrijven in een afgeschermde branch en review je de diff voordat je een workflow automatiseert.

Stappenplan: een veilige PR-review opzetten

Stap 1: kies een smalle trigger en leesrechten

Start met pull_request voor een interne testrepository en laat de job alleen de inhoud lezen. Vermijd een workflow die op onbetrouwbare commentaartekst of een fork automatisch met secrets draait. De officiële actie controleert standaard of de triggerende gebruiker schrijfrechten heeft; breid allow-users, allow-bots of allow-bot-users alleen uit met expliciet vertrouwde accounts.

name: Codex PR review

on:
  pull_request:
    types: [opened, synchronize]

permissions:
  contents: read

Maak eerst een test-PR met een bewust kleine wijziging. Controleer in de Actions-weergave welke event, actor en ref de workflow werkelijk ontvangt voordat je de trigger verbreedt.

Stap 2: checkout exact de PR-context

De officiële voorbeeldworkflow haalt de merge-ref op en haalt vervolgens expliciet de base- en head-ref binnen. Zo kan Codex de wijziging vergelijken in plaats van alleen de standaard shallow checkout te zien. Geef GitHub-expressies door via env en citeer de shellvariabelen, want direct ingevoegde branchnamen of PR-tekst kunnen shellinjectie veroorzaken.

- uses: actions/checkout@v5
  with:
    ref: refs/pull/${{ github.event.pull_request.number }}/merge
    persist-credentials: false

- name: Haal reviewrefs op
  env:
    PR_BASE_REF: ${{ github.event.pull_request.base.ref }}
    PR_NUMBER: ${{ github.event.pull_request.number }}
  run: |
    git fetch --no-tags origin "$PR_BASE_REF" "+refs/pull/$PR_NUMBER/head"

Laat de prompt expliciet vragen om alleen base...head te onderzoeken. Vermeld dat een opmerking alleen een bevinding is als de agent die met bestand en regel kan onderbouwen. Gebruik voor de inhoud van die opdracht de principes uit goede prompts maken.

Stap 3: bewaar de sleutel als secret en beperk Codex

Maak OPENAI_API_KEY als repository- of omgevingssecret in GitHub. Gebruik hem alleen in de input van openai/codex-action; plaats de waarde niet in env, een bestand of een prompt als dat niet nodig is. De actie gebruikt volgens OpenAI standaard workspace-write, dus zet voor een review uitdrukkelijk sandbox: read-only.

Kies op Linux of macOS daarnaast safety-strategy: drop-sudo. Dat verwijdert sudo-lidmaatschap voor de rest van deze job. Gebruik op een zelf-gehoste runner alleen unprivileged-user als je die gebruiker vooraf bewust hebt ingericht. unsafe is geen redelijke start voor een reviewworkflow.

- name: Beoordeel alleen de PR-diff
  id: codex
  uses: openai/codex-action@v1
  with:
    openai-api-key: ${{ secrets.OPENAI_API_KEY }}
    sandbox: read-only
    safety-strategy: drop-sudo
    prompt: |
      Review ONLY the changes introduced by this pull request.
      Cite file and line evidence for every finding.
      Do not suggest a merge. Report only concrete bugs, security issues, or regressions.

De read-only sandbox voorkomt geen elk geheimenrisico. Lees daarom de officiële beveiligingsrichtlijnen voor de actie en houd de Codex-stap als laatste stap van zijn job.

Stap 4: scheid analyse van het plaatsen van feedback

Maak de eindboodschap een job-output. Een tweede job kan die tekst als commentaar plaatsen en krijgt pas daar issues: write en pull-requests: write. Dat volgt de structuur van het officiële voorbeeld en voorkomt dat een job met Codex ook een GitHub-token met schrijfrechten gebruikt.

post_feedback:
  needs: codex
  if: needs.codex.outputs.final_message != ''
  permissions:
    issues: write
    pull-requests: write

Behandel ook de uitgaande tekst als niet-vertrouwd. Laat de tweede job alleen een commentaar plaatsen, zonder shellcommando's of verdere acties uit die tekst af te leiden. Een reviewcommentaar mag nooit een instructie worden om te deployen, secrets op te vragen of beveiliging uit te schakelen.

Stap 5: toets de workflow als productiecode

Controleer de eerste runs inhoudelijk. Lees iedere finding, vergelijk hem met de diff en markeer ruis of foutpositieven in je eigen reviewproces. Houd tests, linting, dependency-scans en menselijke goedkeuring onafhankelijk van Codex, zodat één fout oordeel geen merge blokkeert of toelaat.

Leg in een repository-instructiebestand vast wat buiten scope is, bijvoorbeeld gegenereerde bestanden, lockfiles of uitsluitend stijl. De beveiligingsbasis blijft hetzelfde als bij elke AI-agent: minimale toegang, kleine scope en menselijke verificatie. Zie ook veilig werken met AI.

Waarschuwingen vóór je dit breder inzet

• PR-tekst is invoer, geen instructie. Titel, body, branchnaam, code, AGENTS.md en screenshots kunnen sturende tekst bevatten. Laat ze nooit shellcode of rechten bepalen.
• Gebruik geen brede actorallowlist. Een wildcard of niet gecontroleerde bot vergroot het risico op misbruik van de API-sleutel.
• Verdeel privileges. Geef de analysejob geen commentaar-, push- of deploymentrechten.
• Houd secrets uit de checkout. Een secret kan via logs, processen of een fout geconfigureerde runner lekken, ook als de prompt hem niet noemt.
• Pin en onderhoud afhankelijkheden volgens je eigen CI-beleid. Beoordeel updates van actions en test ze eerst in een beperkte repository.

Veelgemaakte fouten

De reviewjob meteen schrijfrechten geven

Een agent die alleen analyseert heeft geen contents: write, pull-requests: write of deploymenttoken nodig. Scheid de analyse van het plaatsen van een commentaar.

GitHub-expressies rechtstreeks in een shellscript zetten

PR-titels, branchnamen en commentaren zijn niet veilig om ongeciteerd in run: te plakken. Geef ze via env door en gebruik gequote shellvariabelen.

Read-only verwarren met volledige isolatie

Read-only beperkt de bestandswijziging van Codex, maar is geen volledige sleutelbescherming. Verlaag privileges, beperk secrets en gebruik een wegwerpbare runner waar dat past.

Iedere finding als mergeblok behandelen

Een model kan een legitieme afweging missen. Laat branch protection steunen op tests en menselijke code review, en gebruik Codex-feedback als onderzoekspunt.

Een openbare trigger aan een geheime API-sleutel koppelen

Als onbekende gebruikers de workflow kunnen starten, kunnen zij de beschikbare capaciteit misbruiken of onbetrouwbare invoer aan de agent voeren. Begin met vertrouwde bijdragers en controleer elke uitbreiding.

Veelgestelde vragen

Wat doet de OpenAI Codex GitHub Action?

De officiële actie installeert de Codex CLI in een GitHub Actions-workflow, configureert een proxy naar de Responses API en geeft de einduitvoer terug aan je workflow. Je bepaalt zelf de trigger, de prompt, de sandbox en wat er met de uitvoer gebeurt.

Kan Codex een pull request automatisch mergen?

De voorbeeldworkflow van OpenAI plaatst reviewfeedback als commentaar; hij merge niet automatisch. Houd een mergebeslissing bij mensen en je bestaande branch protection, tenzij je zelf na een afzonderlijke risicoanalyse een veilige mergecontrole bouwt.

Welke GitHub-rechten heeft een reviewworkflow nodig?

De reviewtaak kan met alleen contents: read draaien. Een apart rapportagejob heeft alleen de schrijfrechten nodig om feedback op het pull request te plaatsen, zoals issues: write en pull-requests: write.

Waarom horen review en commentaar in afzonderlijke jobs?

Codex kan bestanden en processen in zijn job beïnvloeden. Door de onbetrouwbare uitvoer via een job-output naar een nieuwe job te sturen, beperk je het bereik van de reviewtaak en geef je de schrijfrechten pas aan de rapportagejob.

Moet ik OPENAI_API_KEY in de workflowtekst zetten?

Nee. Bewaar de sleutel als GitHub Actions-secret en geef hem alleen door via de openai-api-key-input van de actie. Plak nooit een sleutel in een prompt, YAML-bestand, log of pull-requestcommentaar.

Is read-only sandboxing voldoende om een API-sleutel te beschermen?

Nee. OpenAI waarschuwt dat read-only toegang en geen netwerk niet voldoende zijn wanneer de runner nog sudo-toegang heeft. Kies op Linux of macOS daarom een privilegeverlagende safety-strategy zoals drop-sudo of unprivileged-user.

Officiële bronnen

• OpenAI: Codex GitHub Action
• OpenAI: beveiliging van Codex GitHub Action
• OpenAI: Codex is algemeen beschikbaar