CI/CD with Codex GitHub Action

Your CI pipeline runs lint, type-check, and tests. That catches syntax errors and regressions. But it does not catch architectural drift, security issues in new code, or the fact that someone just added a 500-line function with zero documentation. You want AI-powered quality checks running on every PR, automatically, without anyone installing extra tools. The Codex GitHub Action (openai/codex-action@v1) gives you exactly that — Codex in CI, with the same capabilities it has everywhere else.

What You’ll Walk Away With

• A working GitHub Actions workflow that runs Codex on every PR
• Prompt files for code review, security scanning, and release preparation
• Security configuration for running Codex safely in CI (drop-sudo, sandboxing)
• Techniques for capturing and posting Codex output back to PRs

The Workflow

Step 1: Set Up the Basic Action

The minimum viable Codex CI integration takes about ten lines of workflow YAML. Store your OpenAI API key as a GitHub secret, check out the code, and run the action.

Tip

Copy-paste workflow for PR review:

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

jobs:
  codex-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    outputs:
      final_message: ${{ steps.codex.outputs.final-message }}
    steps:
      - uses: actions/checkout@v5
        with:
          ref: refs/pull/${{ github.event.pull_request.number }}/merge

      - name: Fetch base and head refs
        run: |
          git fetch --no-tags origin \
            ${{ github.event.pull_request.base.ref }} \
            +refs/pull/${{ github.event.pull_request.number }}/head

      - name: Run Codex review
        id: codex
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          prompt-file: .github/codex/prompts/review.md
          sandbox: read-only
          safety-strategy: drop-sudo

  post-review:
    runs-on: ubuntu-latest
    needs: codex-review
    if: needs.codex-review.outputs.final_message != ''
    permissions:
      pull-requests: write
    steps:
      - name: Post review comment
        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_MESSAGE,
            });
        env:
          CODEX_MESSAGE: ${{ needs.codex-review.outputs.final_message }}

Step 2: Write Prompt Files

Store your Codex prompts in .github/codex/prompts/ so they are version-controlled and reviewable. The prompt file is Markdown — Codex reads it as instructions.

Create .github/codex/prompts/review.md:

Review this pull request. Focus on:

1. Correctness: Logic errors, off-by-one bugs, unhandled edge cases
2. Security: Input validation, auth checks, data exposure
3. Performance: N+1 queries, unnecessary computation, missing indexes
4. Maintainability: Overly complex functions, missing error handling, unclear naming

Rules:
- Flag only P0 (must fix before merge) and P1 (should fix before merge) issues
- Include the file path and line number for each finding
- Suggest a specific fix, not just "this could be better"
- If the PR is clean, say so explicitly

Do not flag:
- Style preferences (formatting, naming conventions) unless they violate project standards
- Test file structure choices
- Comment content or documentation style

Step 3: Add Security Scanning to CI

Create a separate workflow that runs security-focused analysis on PRs that touch sensitive paths:

name: Security scan
on:
  pull_request:
    paths:
      - 'src/routes/**'
      - 'src/middleware/**'
      - 'src/lib/db/**'
      - 'package.json'
      - 'package-lock.json'

jobs:
  security:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v5

      - name: Security scan
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          prompt-file: .github/codex/prompts/security.md
          sandbox: read-only
          safety-strategy: drop-sudo
          output-file: security-report.md

      - name: Upload security report
        uses: actions/upload-artifact@v4
        with:
          name: security-report
          path: security-report.md

With .github/codex/prompts/security.md:

Perform a security audit of the changes in this pull request:

1. Scan for SQL injection, XSS, command injection, and path traversal
2. Verify all new endpoints have authentication middleware
3. Check that error responses do not expose internal details
4. Flag any new dependencies with known CVEs (check npm audit)
5. Verify secrets are not committed in any file

Report only security findings. Format as a severity-sorted list.

Step 4: Automate Release Preparation

Use Codex in CI to prepare release notes when changes are merged to main:

Tip

Copy-paste workflow for release prep:

name: Release preparation
on:
  push:
    branches: [main]

jobs:
  prepare:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v5
        with:
          fetch-depth: 0

      - name: Generate release notes
        id: codex
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          prompt: |
            Analyze commits since the last git tag. Generate:
            1. A changelog in Keep a Changelog format
            2. A suggested semver version bump (major/minor/patch)
            3. A release summary for GitHub Releases

            Group changes into: Added, Changed, Fixed, Security.
            Write user-facing descriptions, not commit messages.
          sandbox: read-only
          safety-strategy: drop-sudo
          output-file: release-notes.md

Step 5: Configure Security and Permissions

The Codex GitHub Action runs with whatever permissions your workflow grants. Follow the principle of least privilege.

Safety strategies:

• drop-sudo (default, recommended) — removes sudo access before running Codex. Irreversible for the job.
• unprivileged-user — runs Codex as a non-root user. Most restrictive.
• unsafe — no restrictions. Only for Windows runners. Never use on shared runners with secrets.

Sandbox modes:

• read-only — Codex can read files but not modify them or access the network. Best for reviews.
• workspace-write — Codex can edit files in the repository. Needed for fix-and-commit workflows.
• danger-full-access — Full filesystem and network access. Use only when absolutely necessary (for example, running tests that need network access).

Restrict triggers:

• Use allow-users to limit who can trigger the workflow
• Use allow-bots to control which bots can invoke it
• Filter by file paths to avoid running on irrelevant changes

Caution

Never run the Codex action with safety-strategy: unsafe on runners that have access to production secrets. The action’s safety strategy only protects the Codex subprocess — other steps in the same job can still access secrets normally.

Advanced: Structured Output and Artifact Collection

For workflows that need structured results (not just a comment), use --output-schema through the codex-args input to enforce a JSON response shape:

- uses: openai/codex-action@v1
  with:
    openai-api-key: ${{ secrets.OPENAI_API_KEY }}
    prompt: "Analyze this PR and categorize each finding by type and severity."
    codex-args: '["--output-schema", "{\"findings\": [{\"type\": \"string\", \"severity\": \"string\", \"file\": \"string\", \"line\": \"number\", \"description\": \"string\"}]}"]'
    sandbox: read-only
    output-file: findings.json

This lets downstream steps parse the findings programmatically — for example, to create GitHub check annotations or fail the build only when Critical findings exist.

Combine output-file with artifact upload to preserve full transcripts for audit trails:

- name: Upload Codex transcript
  if: always()
  uses: actions/upload-artifact@v4
  with:
    name: codex-review-transcript
    path: codex-output.md
    retention-days: 30

Combining CI and Local Automations

The GitHub Action runs server-side on GitHub’s infrastructure. Codex App automations run locally on your machine. These complement each other:

• GitHub Action: runs on every PR, catches issues before merge, visible to the whole team
• Local automations: run on a schedule (daily, weekly), catch drift in the main branch, feed into your personal inbox

A robust setup uses both: the GitHub Action reviews incoming changes, and local automations monitor the health of the codebase between PRs. The GitHub Action ensures quality on the way in; automations ensure quality does not degrade over time.

When This Breaks

Codex review takes too long and blocks PR merging. Set a timeout on the workflow job and make the review non-blocking: change the workflow to run as a separate check that is not required to pass. Teams should treat Codex review as advisory, not a gate, until they trust the accuracy.

Both prompt and prompt-file are set. The action requires exactly one prompt source. Remove the duplicate. Prefer prompt-file for version-controlled prompts and prompt for one-off inline instructions.

The API key is exposed in logs. The action uses the Responses API proxy which should not log the key, but if safety-strategy is unsafe and an earlier step stored the key in an environment variable, it could leak. Always use drop-sudo and check that no step echoes OPENAI_API_KEY.

Codex posts a review on every push, creating noise. If multiple commits are pushed quickly (rebasing, fixup), you get multiple review comments. Add a concurrency group to cancel in-progress runs:

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

What’s Next

PR Automation Workflow Automate the entire PR lifecycle beyond just code review

Scheduled Task Automation Complement CI checks with scheduled local automations