Review the following diff for coding style violations. Check for:

1. Naming conventions: camelCase for variables/functions, PascalCase for classes/components
2. Function length: flag any function exceeding 30 lines
3. Import ordering: third-party imports first, then internal modules, then relative imports
4. Consistent use of const/let (never var)
5. Missing or inconsistent JSDoc/TSDoc comments on exported functions
6. Trailing whitespace or inconsistent indentation

Output format:

• File path and line number
• Rule violated
• Severity: ERROR or WARNING
• Suggested fix

Analyze the following diff for security vulnerabilities. Check for:

1. SQL injection: raw string concatenation in queries
2. XSS: unescaped user input rendered in HTML/JSX
3. Hardcoded secrets: API keys, passwords, tokens in source code
4. Path traversal: unsanitized file path inputs
5. Insecure dependencies: known vulnerable patterns
6. Missing input validation on API endpoints
7. Overly permissive CORS configurations
8. Unsafe deserialization of user input

Output format:

• File path and line number
• Vulnerability type (CWE ID if applicable)
• Severity: CRITICAL, HIGH, MEDIUM, or LOW
• Recommended remediation

Analyze the following diff for logical errors and potential bugs. Check for:

1. Off-by-one errors in loops and array indexing
2. Null/undefined handling: missing null checks before property access
3. Race conditions in async code
4. Uncaught promise rejections
5. Incorrect boolean logic or operator precedence
6. Dead code or unreachable branches
7. Missing error handling in try/catch blocks
8. Inconsistent return types within a function

Output format:

• File path and line number
• Issue description
• Severity: ERROR or WARNING
• Suggested correction

Configuration

BASE_BRANCH=”${BASE_BRANCH:-main}” REVIEW_DIR=“.codex/prompts” RESULTS_DIR=“review-results” EXIT_CODE=0

Create results directory

mkdir -p “$RESULTS_DIR”

Get the diff

echo “Fetching diff against $BASE_BRANCH…” DIFF=$(git diff “$BASE_BRANCH”…HEAD)

if [ -z “$DIFF” ]; then echo “No changes detected. Skipping review.” exit 0 fi

Save diff to a temporary file

DIFF_FILE=$(mktemp) echo “$DIFF” > “$DIFF_FILE”

Run each review pass

for PROMPT_FILE in “$REVIEW_DIR”/review-*.md; do REVIEW_NAME=$(basename “$PROMPT_FILE” .md | sed ‘s/review-//’) echo "" echo ”=== Running $REVIEW_NAME review ===”

RESULT_FILE=“$RESULTS_DIR/$REVIEW_NAME.txt”

codex ”$(cat “$PROMPT_FILE”)

Here is the diff to review:

$(cat “$DIFF_FILE”)” > “$RESULT_FILE” 2>&1 || true

Check for failures

if grep -q “CRITICAL|ERROR” “$RESULT_FILE”; then echo “FAIL: $REVIEW_NAME review found issues” EXIT_CODE=1 elif grep -q “PASS” “$RESULT_FILE”; then echo “PASS: $REVIEW_NAME review clean” else echo “WARN: $REVIEW_NAME review produced unexpected output” fi

cat “$RESULT_FILE” done

Cleanup

rm -f “$DIFF_FILE”

scripts/codex-review-per-file.sh

set -euo pipefail

BASE_BRANCH=”${BASE_BRANCH:-main}” PROMPT_FILE=“$1” RESULTS_DIR=“review-results/per-file” mkdir -p “$RESULTS_DIR”

CHANGED_FILES=$(git diff —name-only “$BASE_BRANCH”…HEAD | grep -E ’.(ts|tsx|js|jsx|py|go)$’)

for FILE in $CHANGED_FILES; do echo “Reviewing: $FILE” FILE_DIFF=$(git diff “$BASE_BRANCH”…HEAD — “$FILE”)

SAFE_NAME=$(echo “$FILE” | tr ’/’ ’_’) codex ”$(cat “$PROMPT_FILE”)

security: max_low: 3 max_medium: 1 max_high: 0 max_critical: 0 fail_on: medium

logic: max_warnings: 3 max_errors: 0 fail_on: error

RESULTS_DIR=“review-results” GATE_CONFIG=“.codex/quality-gates.yaml” FINAL_STATUS=“PASS”

echo ”=== Quality Gate Evaluation ===“

Count issues by severity in each review

for RESULT_FILE in “$RESULTS_DIR”/*.txt; do REVIEW_NAME=$(basename “$RESULT_FILE” .txt) CRITICAL_COUNT=$(grep -c “CRITICAL” “$RESULT_FILE” 2>/dev/null || echo 0) ERROR_COUNT=$(grep -c “ERROR” “$RESULT_FILE” 2>/dev/null || echo 0) WARNING_COUNT=$(grep -c “WARNING” “$RESULT_FILE” 2>/dev/null || echo 0)

echo "" echo “$REVIEW_NAME: $CRITICAL_COUNT critical, $ERROR_COUNT errors, $WARNING_COUNT warnings”

if [ “$CRITICAL_COUNT” -gt 0 ]; then echo ” BLOCKED: Critical issues must be resolved” FINAL_STATUS=“FAIL” fi

if [ “$ERROR_COUNT” -gt 0 ]; then echo ” BLOCKED: Errors must be resolved” FINAL_STATUS=“FAIL” fi done

echo "" echo ”=== Final Verdict: $FINAL_STATUS ===”

on: pull_request: types: [opened, synchronize, reopened]

permissions: contents: read pull-requests: write

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

  - name: Setup Node.js
    uses: actions/setup-node@v4
    with:
      node-version: '22'

  - name: Install Codex CLI
    run: npm install -g @openai/codex

  - name: Run automated review
    env:
      OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
      BASE_BRANCH: ${{ github.event.pull_request.base.ref }}
    run: |
      chmod +x scripts/codex-review.sh
      ./scripts/codex-review.sh

  - name: Evaluate quality gates
    if: always()
    run: |
      chmod +x scripts/evaluate-gates.sh
      ./scripts/evaluate-gates.sh

  - name: Post review comment
    if: always()
    uses: actions/github-script@v7
    with:
      script: |
        const fs = require('fs');
        const resultsDir = 'review-results';
        let body = '## Codex Automated Code Review\n\n';

        const files = fs.readdirSync(resultsDir)
          .filter(f => f.endsWith('.txt'));

        for (const file of files) {
          const name = file.replace('.txt', '');
          const content = fs.readFileSync(
            `${resultsDir}/${file}`, 'utf8'
          );
          body += `### ${name} Review\n`;
          body += '```\n' + content + '\n```\n\n';
        }

        github.rest.issues.createComment({
          issue_number: context.issue.number,
          owner: context.repo.owner,
          repo: context.repo.repo,
          body: body
        });</code>

GitLab CI Integration

For GitLab CI, add the following to your .gitlab-ci.yml:

codex-review: stage: review image: node:22 before_script: - npm install -g @openai/codex script: - export BASE_BRANCH=$CI_MERGE_REQUEST_TARGET_BRANCH_NAME - chmod +x scripts/codex-review.sh - ./scripts/codex-review.sh - chmod +x scripts/evaluate-gates.sh - ./scripts/evaluate-gates.sh rules: - if: $CI_PIPELINE_SOURCE == “merge_request_event” artifacts: paths: - review-results/ when: always expire_in: 7 days

Workflow Diagram

The following diagram illustrates the complete automated review workflow:

Developer opens PR | v CI/CD pipeline triggers | v Checkout code + fetch full history | v Extract diff (base branch…HEAD) | +---> Style Review ------> results/style.txt | +---> Security Review ---> results/security.txt | +---> Logic Review ------> results/logic.txt | v Evaluate Quality Gates | +---> PASS —> Post summary comment, mark check green | +---> FAIL —> Post findings comment, block merge

Advanced Configuration

Custom Rule Sets Per Team

Different teams often need different review standards. Support team-specific overrides by organizing prompts into directories:

.codex/ prompts/ default/ review-style.md review-security.md review-logic.md frontend/ review-style.md # React/Next.js specific rules review-accessibility.md backend/ review-style.md # Go/Python specific rules review-performance.md

Modify the review script to detect which directories changed and select the appropriate prompt set:

# Detect team based on changed files CHANGED_DIRS=$(git diff —name-only “$BASE_BRANCH”…HEAD | cut -d’/’ -f1 | sort -u)

if echo “$CHANGED_DIRS” | grep -q “frontend”; then REVIEW_DIR=“.codex/prompts/frontend” elif echo “$CHANGED_DIRS” | grep -q “backend”; then REVIEW_DIR=“.codex/prompts/backend” else REVIEW_DIR=“.codex/prompts/default” fi

Test Coverage Validation

Integrate test coverage checks into the review pipeline by running tests first and then asking Codex to evaluate whether new code is adequately covered:

# Run tests with coverage npm test — —coverage —coverageReporters=text > coverage-report.txt

Coverage report: $(cat coverage-report.txt)“

Incremental Review for Large PRs

For PRs with more than 500 lines of changes, split the review into manageable chunks:

# scripts/codex-review-chunked.sh MAX_LINES=300 DIFF_FILE=$(mktemp) git diff “$BASE_BRANCH”…HEAD > “$DIFF_FILE” TOTAL_LINES=$(wc -l < “$DIFF_FILE”)

rm -f “$DIFF_FILE”

Handling False Positives

Automated review will occasionally flag code that is intentionally written a certain way. Manage false positives with inline suppression comments:

// codex-ignore: security/hardcoded-string — This is a public API endpoint, not a secret const API_BASE = “https://api.example.com/v1”;

// codex-ignore: style/function-length — Complex state machine requires sequential steps function processStateMachine(input) { // … 45 lines of intentionally sequential logic }

Update your review prompts to respect these suppression markers:

If a line contains a codex-ignore comment with a matching rule category, skip that finding and do not report it. The developer has intentionally accepted this pattern.

Cost Optimization

Running Codex on every PR can accumulate API costs. Consider these strategies:

• Use o4-mini instead of the full o3 model. For style and pattern matching, o4-mini is sufficient and significantly cheaper.
• Cache common patterns: Store frequently seen diffs and their review results. If a new diff is structurally similar, reuse the cached result.
• Gate by PR size: Only run the full review suite on PRs above a certain size. Small PRs (under 50 lines) can skip the logic review.
• Rate limit per repository: Set a daily budget cap per repository to prevent runaway costs from high-volume repositories.

Monitoring and Metrics

Track the effectiveness of automated review over time:

# Append metrics to a tracking file after each review echo ”$(date -u +%Y-%m-%dT%H:%M:%SZ),$PR_NUMBER,$STYLE_ISSUES,$SECURITY_ISSUES,$LOGIC_ISSUES,$FINAL_STATUS” >> metrics/review-log.csv

Key metrics to track:

• Issues caught per PR: Average number of findings across review types
• False positive rate: How often findings are dismissed or suppressed
• Time saved: Compare review turnaround time before and after automation
• Escape rate: Issues that reach production despite automated review

Frequently Asked Questions

Does Codex replace human code reviewers entirely?

No. Codex automates the repetitive, pattern-based aspects of code review such as style violations, common security pitfalls, and obvious logic errors. Human reviewers should focus on architecture decisions, business logic correctness, and design trade-offs that require domain knowledge.

How do I handle private repositories with sensitive code?

OpenAI processes the diff content through its API. If your organization has strict data policies, consider running Codex with a self-hosted model or using the API with enterprise data processing agreements. Review your organization’s security requirements before sending source code to any external API.

What is the typical API cost per PR review?

With o4-mini, a typical 200-line PR costs approximately $0.02 to $0.08 per review pass, depending on prompt complexity. Running all three passes (style, security, logic) on a medium-sized PR costs roughly $0.10 to $0.25. Monthly costs for a team generating 100 PRs per month would be approximately $10 to $25.

Can I use Codex review with monorepos?

Yes. The per-file review mode and team-specific prompt directories are designed for monorepo workflows. Use the directory detection logic to apply different review standards to different parts of the codebase.

How do I update review rules as coding standards evolve?

Review prompt templates are plain Markdown files checked into your repository. Update them through the same PR process as any other code change. This provides version history, peer review of rule changes, and automatic rollout to all branches.

What happens when the OpenAI API is down during a CI run?

Configure your CI pipeline with a timeout and a fallback. If the Codex review step fails due to an API error (not a code quality failure), mark the check as neutral rather than failed so it does not block the PR. Add a retry mechanism for transient errors:

# Retry logic for transient API failures MAX_RETRIES=3 RETRY_COUNT=0 until ./scripts/codex-review.sh || [ “$RETRY_COUNT” -ge “$MAX_RETRIES” ]; do RETRY_COUNT=$((RETRY_COUNT + 1)) echo “Review attempt $RETRY_COUNT failed. Retrying in 30 seconds…” sleep 30 done

Can I combine Codex review with existing linters?

Absolutely. Codex review complements tools like ESLint, Prettier, and SonarQube. Run deterministic linters first to catch formatting issues cheaply, then use Codex for the nuanced analysis that rule-based linters cannot perform, such as detecting incorrect business logic or identifying security patterns that span multiple files.

Conclusion

Automating code review with OpenAI Codex CLI transforms a manual bottleneck into a systematic quality gate. By separating concerns into distinct review passes, defining clear quality thresholds, and integrating with your existing CI/CD pipeline, you create a review system that catches issues consistently and frees human reviewers to focus on the decisions that truly require human judgment. Start with the style review pass, measure its effectiveness for two weeks, then gradually add security and logic passes as your team builds confidence in the automated findings.