Codex Second Opinion

• You want a second opinion on a plan, diff, or architecture decision.
• You need a fresh pass for bugs, edge cases, or missing requirements.
• You want a quick sanity check before sharing with users or stakeholders.

Invocation

codex exec

# Direct prompt
codex exec "Read the files in src/ and review them for bugs"

# Pipe via stdin
git diff main..HEAD | codex exec "Review this diff for issues"

Key Options

• -m MODEL

  : Select model (always use the most capable available:

  gpt-5.2-codex

  )

• -c key=value

  : Override config values inline (e.g.,

  -c model="gpt-5.2-codex"

  )

• -p PROFILE

  : Use a config profile from

  ~/.codex/config.toml

  to avoid repeating flags

• -C DIR

  : Set working directory

• --full-auto

  : Automatic execution with workspace-write sandbox (fewer approval pauses)

• -s SANDBOX_POLICY

  : Sandbox policy (

  read-only

  ,

  workspace-write

  )

• --skip-git-repo-check

  : Skip repo detection (saves time outside git)

Workflow

1. Gather context: Identify the files, plans, or diffs Codex needs
2. Define the objective: What does “good” look like? Include constraints and acceptance criteria
3. Compose a focused prompt: Be specific about what to review and what feedback you want
4. Invoke Codex: Use

   codex exec

   with appropriate options
5. Report findings: Present Codex's feedback to the user with your own assessment of which points are valid

Model Policy

• Prefer

  gpt-5.2-codex

  ; if unavailable, use

  gpt-5.2

  .
• If neither is available in this environment, select the strongest model supported by

  codex

  and note the fallback.

Safety and Scope

• Default to

  -s read-only

  for review-only tasks.
• Use

  workspace-write

  only when Codex needs to run tests or inspect generated artifacts.
• Never pass secrets, tokens, or private customer data.

Prompt Guidelines

• State the review goal explicitly (e.g., "find logical errors", "evaluate scalability", "check for missing edge cases")
• Include constraints or requirements Codex should check against
• Ask for structured output (numbered issues, severity levels) for actionable feedback
• Ask for concrete references (file:line) when reviewing code or diffs

Interpreting Results

• Treat Codex feedback as a second opinion, not authority.
• Verify any claims that seem uncertain or conflict with known constraints.
• Prefer actionable items: bugs, regressions, missing tests, and unclear requirements.

Prompt Examples

Plan Review

cat plan.md | codex exec -m gpt-5.2-codex -s read-only \
"Review this plan for risks, missing steps, and unclear assumptions.
Return:
1) Critical issues
2) Medium risks
3) Suggested improvements
4) Questions to clarify"

Diff Review

git diff main..HEAD | codex exec -m gpt-5.2-codex -s read-only \
"Review this diff for bugs, regressions, security issues, and missing tests.
Return numbered findings with severity and file:line references."

Architecture Review

cat design.md | codex exec -m gpt-5.2-codex -s read-only \
"Evaluate this architecture for scalability, fault tolerance, and operational risk.
Call out assumptions and suggest alternatives where applicable."

Large Codebase Review

codex exec -m gpt-5.2-codex -s read-only \
"Review the codebase with focus on correctness, edge cases, and missing tests.
Read these folders: src/, scripts/, and packages/.
Return numbered findings with severity and file:line references."