Codex as a Thinking Partner

codex exec provides independent perspective from a separate AI agent. Runs locally, reads codebase, returns analysis to stdout.

Shell prerequisite: the recipes below use bash features (/tmp/ paths, source, heredocs, cygpath). Claude Code ships with bash on every platform (native on Linux/macOS, Git Bash on Windows) so this is usually a non-issue — but if you're running Codex commands from native Windows cmd or PowerShell outside Claude Code, adapt the syntax.

When to Use Codex

• Exploring design space — want alternatives before committing → Brainstorm
• Have a plan or design — want weaknesses flagged (failure modes + over-engineering + missed simplifications) before investing implementation time → Red-team
• Bug where local reasoning is stuck — obvious hypotheses ruled out, OR unfamiliar stack where causes/instrumentation/repro are non-obvious → Debug
• Plan spans multiple subsystems or has non-trivial step ordering — want sequencing, gap, rollback review → Plan Review
• Have a diff or report — want factual claims verified, regressions found, or mismatch with the ticket/spec caught (prose optional) → Diff Review
• Ticket is prose with implicit requirements, or legacy code lacks clear contracts — need concrete acceptance checklist before coding → Spec Extraction
• Shipping risky change — schema update, API change, migration with operational impact → Rollout/Rollback
• Want independent tradeoff evaluation to pick among a handful of concrete approaches → Compare/Decide
• Want regression cases or edge conditions — whether before coding a risky refactor or after finishing an implementation → Test Gaps
• Careful reading leaves meaningful parts unclear — undocumented, complex algorithms, legacy code where the non-obvious logic needs surfacing → Explain
• Production incident or CI failure — have logs/traces, need root cause → Post-mortem
• Security-sensitive design or diff, OR obvious attack vectors exhausted in ongoing testing — auth, permissions, tenant boundaries, file upload, parser, secrets, untrusted input → Attack Surface
• Exhausted known hypotheses — all leads investigated, dead-ends recorded, want external model to find what pipeline systematically missed → Exhausted Hypotheses

When NOT to Use Codex

• Single-file mechanical edit (typo, rename, one-import change) with no new concepts
• Answer is already in context
• Conversation is active back-and-forth, or user indicated urgency — 1–5 min wait would break the flow
• Already used Codex (or Gemini) for this question this session, OR you're about to fire both on the same prompt — retry narrower prompt, or escalate to user
• No specific artifact or concrete question — just a topic or area to "think about"
• Prompt would contain secrets, credentials, or PII
• Question is about Claude Code internals (hooks, skills, MCP, settings) — /claude-code-docs knows, external CLIs don't
• Answer lives in library/tool docs — WebFetch, Context7, or man is cheaper
• Missing local facts — reproduce the issue, inspect logs, run rg/git/blame, or ask user for clarification — before outsourcing reasoning
• Decision depends on product priority, compliance, or release timing not in my context — ask the user (who owns this) first

Precedence

When multiple bullets match a single prompt:

• WNTU wins over WTU. If any When NOT to Use bullet matches, don't fire — even if a When to Use bullet also matches. If unsure, ask the user ("I'd skip Codex here because X; proceed anyway?") rather than firing.
• Among WTU, pick the most specific. "Shipping risky change" over "Have a plan or design." "Security-sensitive diff" over "Have a diff or report." The more specific mode carries more relevant context.
• Among WNTU, privacy beats cost. Privacy/confidentiality skips are hard (never fire). Session/cost skips are soft (can escalate to user). If a prompt would contain secrets, that overrides every other consideration.

Execution Reference

Basic Invocation

# Short prompt as argument
codex exec --ephemeral "<prompt>"

# Long prompt via stdin (preferred for multi-line)
codex exec --ephemeral -s read-only - <<'PROMPT'
Your long prompt here...
PROMPT

Do not combine prompt argument with piped stdin — use one or the other. When both provided, argument takes precedence and stdin content is lost.

Backtick safety: Never use $(cat file) inside unquoted heredocs (<<PROMPT) when file may contain backticks (markdown, code) or the delimiter word. Bash interprets backticks as command substitution and delimiter words as heredoc terminators → "unexpected EOF" errors. Safe patterns:

• Pipe pattern (preferred): cat file | codex exec --ephemeral -s read-only -
• Temp file pattern: write full prompt to temp file, then cat tmpfile | codex exec --ephemeral -
• Quoted heredoc: use <<'PROMPT' (prevents ALL expansion — no $() inside, but safe)

Windows sandbox limitation: On affected Windows installs, sandboxed tool calls under both -s read-only and --full-auto (workspace-write) depend on the helper codex-windows-sandbox-setup.exe. If stderr shows windows sandbox: spawn setup refresh or OS error 740, the helper failed to launch (Windows returns ERROR_ELEVATION_REQUIRED, likely from installer-detection of the "setup" helper name) and the command dies before PowerShell starts. --full-auto is not a workaround — it uses the same failing helper. (Reproduced locally; upstream: openai/codex#25362, #23965.)

What works on affected installs:

• For prompt-complete modes (red-team, diff-review, compare-decide, etc.), embed the needed file contents in the prompt and run `-s read-only` (preferred — zero config, no backend change). Note: piping a prompt that merely tells Codex to go inspect the repo still fails — the file contents themselves must be in the prompt. This is why the read-only modes work: their content is already supplied.
• When Codex must inspect files itself (Debug, Plan Review, Test Gaps, Explain, Attack Surface, Exhausted Hypotheses), prefer the unelevated sandbox backend over RUNASINVOKER or danger-full-access: add -c 'windows.sandbox="unelevated"' to that invocation (correct as a standalone Git Bash/PowerShell argument; re-quote if embedding inside an already single-quoted string). Verified on one affected Win11 install (codex 0.136.0): under -s read-only, file reads worked and a write probe was blocked by policy; under --full-auto, an in-workspace write landed and a probe write to the user profile was denied. Limits: the unelevated backend cannot enforce deny-read rules or split writable-root sets, so do not use it for runs that depend on those — reads are not isolated beyond what the OS account allows. Prefer the per-run flag; persist [windows] sandbox = "unelevated" in ~/.codex/config.toml only after a smoke test on the target machine or explicit user choice. If Codex rejects the key or still logs windows sandbox: spawn setup refresh, treat the workaround as unavailable and fall back to embedded contents or a disposable environment.
• Last resorts: a user-applied RUNASINVOKER AppCompatFlags workaround for the helper is described in openai/codex#25362 (do not apply registry changes automatically — it also breaks on codex updates since it keys on the exact exe path). Use -s danger-full-access only after explicit current-run user approval, preferably in a throwaway checkout or VM, because it removes sandboxing entirely: Codex can read, write, or delete anything the current OS account can access.

Keep including in prompts: "Use PowerShell-compatible commands (Get-Content, Select-String). Codex's internal shell on Windows is PowerShell, not Git Bash."

Key Flags

Code Review

Prefer codex exec review over codex review — supports full flag surface (-m, --json, -o). Top-level codex review works but has fewer options:

codex exec review --uncommitted          # Review working tree changes
codex exec review --base main            # Review changes against a branch
codex exec review --commit abc123        # Review a specific commit
codex exec review "Focus on security"    # Custom review instructions

Mode-to-Sandbox Table

This mapping is the default for non-Windows and for Windows installs with a working sandbox helper. Windows caveat: on affected installs (stderr shows windows sandbox: spawn setup refresh), the --full-auto rows fail the same as read-only — add -c 'windows.sandbox="unelevated"' to the invocation, or embed the needed file contents in the prompt and use -s read-only. See the Windows sandbox limitation above.

Execution Rules

• Set generous Bash timeout, or omit when using run_in_background: true
• Use run_in_background: true so user is not blocked waiting
• Always use `-o <temp>/codex-<descriptive-slug>.txt` to write final analysis to clean file, where <temp> is `c:/tmp` on Windows (create once via mkdir -p c:/tmp) and `/tmp` on Linux/macOS. Do NOT use /tmp/... for the -o path on Windows — Bash in Git Bash resolves it to %TEMP% (the -o path is translated by Git Bash before Codex receives it) and the write succeeds, but Claude's Read tool treats the path literally and fails with File does not exist when you try to read the output back. Using c:/tmp/... on Windows makes both Codex's write and Claude's Read resolve to the same Windows-native location. Separates output from shell noise. Read the -o file for analysis, not the background task output file.
• When running in background, also use 2>&1 to capture stderr — background output file serves as debug log if -o file is empty or missing
• Add --skip-git-repo-check when running outside a git repository
• Cleanup: after reading -o file, delete it (rm -f <temp>/codex-<slug>.txt, where <temp> is the same c:/tmp (Windows) / /tmp (Linux/macOS) location used for the -o write above). Temp files accumulate otherwise.
• Wait for completion: NEVER read or delete -o file until you receive <task-notification> confirming background task completed. File may be 0 bytes or missing before Codex finishes — does NOT mean it failed. Premature reads produce false "empty output" conclusions; premature deletes destroy results the process is about to write.
• Re-launch safety: if re-launching a Codex invocation, use a DIFFERENT output slug (e.g., <temp>/codex-redteam-auth-v2.txt). Never reuse -o path of still-running or recently-launched invocation — two processes will collide on output file.
• Chase down all output: if -o file is empty but task completed successfully, check background task output file for actual analysis or paths where Codex wrote results. Never skip or dismiss review output because it ended up somewhere unexpected.
• Passing `-o` paths to subagents: subagents launched via Task/Agent run in an isolated tool environment with the same /tmp/ blind spot as the main-session Read tool on Windows — they do NOT resolve Git Bash's /tmp/ to C:\Users\<user>\AppData\Local\Temp\. If you followed the Windows rule above and wrote -o c:/tmp/codex-<slug>.txt, subagents resolve it natively with no conversion needed — this is the preferred path. For legacy /tmp/... outputs (pre-fix invocations or Linux/macOS), two fallback patterns: (1) inline content — cat /tmp/codex-<slug>.txt in the parent shell and paste the output directly into the subagent prompt; works on every platform; preferred for outputs ≤ ~50KB. (2) convert path — on Windows + Git Bash, pass $(cygpath -w /tmp/codex-<slug>.txt) which yields C:\Users\...\Temp\codex-<slug>.txt, resolved natively by the subagent's Read tool.

Base Prompt Template

One unified template. Adapt per mode by filling relevant fields and appending mode-specific instruction.

Mode: {brainstorm|red-team|debug|plan-review|diff-review|spec-extraction|rollout-rollback|compare-decide|test-gaps|explain|post-mortem|attack-surface|exhausted-hypotheses}
Question: {what you want Codex to decide or critique}
Context:
{relevant plan, diff, logs, or summary — use the smallest useful artifact}
Current belief: {your current approach or hypothesis, if any}
Constraints: {time, risk, compatibility, scope — omit if none}

Return:
- verdict or recommendation
- top risks / hypotheses / objections
- missing evidence
- concrete next step

Be direct and concrete. If evidence is insufficient, say exactly what is missing.

Response style: compress prose. Drop fillers, hedges, connectives unless load-bearing. Prefer short active sentences. Keep verbatim: code blocks, diffs, file:line citations, log entries, numbers, names, paths, quoted context, and tables (headers, cells, and structure). Never compress code. If compression would obscure a finding, write normal prose.

Smallest useful artifact rule: prefer the smallest useful artifact — only include what Codex needs to form a judgment.

Omit empty sections rather than forcing every field.

Mode-Specific Additions

Append one of these to the base template:

• Brainstorm: "Generate 3-5 alternatives with tradeoffs. End with a recommendation and why."
• Red-team: "Find weaknesses. Structure response under two explicit headings:

Breakage

Failure modes, edge cases, wrong assumptions. What could break. Attack assumptions. Give the strongest counterargument.

Prioritize the classes of failure that are expensive, dangerous, or hard to detect:

• auth, permissions, tenant isolation, and trust boundaries
• data loss, corruption, duplication, and irreversible state changes
• rollback safety, retries, partial failure, and idempotency gaps
• race conditions, ordering assumptions, stale state, and re-entrancy
• empty-state, null, timeout, and degraded-dependency behavior
• version skew, schema drift, migration hazards, and compatibility regressions
• observability gaps that would hide failure or make recovery harder

Default to skepticism. Do not give credit for good intent, partial fixes, or likely follow-up work. If a code path only works on the happy path, treat that as a real weakness. Prefer depth over breadth: one fully-evidenced finding beats three speculative ones.

Simplifications

Over-engineering (unnecessary abstractions, dead config, layers that don't earn their keep) and missed reductions (what could be flatter, fewer, smaller). For each: what to cut/merge/flatten, why safe, expected impact. Do NOT strip defensive code at system boundaries, WHY comments, or anything whose removal sacrifices clarity for brevity.

Do not agree just to be agreeable."

• Debug: "Rank hypotheses by likelihood. Suggest the cheapest diagnostic step for each. Focus on hypotheses I am likely to have missed."
• Plan Review: "Find missing steps, sequencing issues, rollback gaps, and operational risks. Cite file names and line numbers when pointing out issues."
• Diff Review: "For each claim, verify from code or docs. Flag assumptions stated as facts. Check for stale information. Include a blast-radius note: touched surfaces, downstream callers, and any migration or test surface the diff pulls into scope."
• Spec Extraction: "Extract invariants, edge cases, non-goals, and a test checklist. Output a concrete acceptance criteria list, not prose."
• Rollout/Rollback: "Propose a phased rollout, observability checks, feature-flag strategy, and rollback plan. Identify the point of no return. Map the blast radius up front: touched surfaces, downstream callers, migrations, and operational impact."
• Compare/Decide: "Evaluate each option against the stated constraints. For each, list strengths, weaknesses, and hidden risks. Pick one and explain why."
• Test Gaps: "Identify untested edge cases, missing error paths, and boundary conditions. Output a concrete test checklist, not general advice. Map the blast radius first — touched functions, downstream callers, and the test surface that should cover them — so the checklist reaches beyond the directly changed code."
• Explain: "Read the code and explain what it does, why it's structured this way, and what the non-obvious parts are. Flag anything that looks like a bug or anti-pattern."
• Post-mortem: "Analyze the timeline, identify the root cause, distinguish contributing factors from the trigger, and suggest preventive measures. Cite specific log entries as evidence."
• Attack Surface: "Identify overlooked attack vectors, underexplored entry points, and non-obvious vulnerability classes for this target. Consider logic flaws, trust boundaries, race conditions, and chained weaknesses — not just OWASP top 10. Prioritize by likelihood and impact. For each finding, note the blast radius: the tenant isolation broken and the data or actions exposed."
• Exhausted Hypotheses: "You are reviewing a codebase that has already been through extensive security analysis. All obvious and semi-obvious hypotheses have been investigated. Your job is to find what was missed — not what was already tried. Generate 5-10 novel vulnerability hypotheses NOT listed in the dead-ends or existing hypotheses. For each: (1) exact file:line, (2) attack scenario with concrete steps, (3) why a systematic review pipeline would miss this, (4) impact if exploitable, (5) what makes this esoteric or non-obvious."

Shell Pipeline Recipes

Ready-made patterns for common workflows:

# -o paths below use /tmp (Linux/macOS); on Windows use c:/tmp instead, per the
# <temp> convention in Execution Rules (Claude's Read tool can't resolve /tmp on Windows).

# Review staged changes adversarially
codex exec --ephemeral -s read-only -o /tmp/codex-red-team.txt - <<PROMPT
Mode: red-team
Question: Find the most likely regressions in this diff.
Context:
$(git diff --staged)
Return: top 3 risks, the invariant each threatens, and missing tests.
PROMPT

# Cluster test failures by root cause
codex exec --ephemeral -s read-only -o /tmp/codex-debug.txt - <<PROMPT
Mode: debug
Question: Cluster these failures by likely root cause.
Context:
$(cargo test 2>&1)
Return: failure clusters, most likely shared cause per cluster, which single test to isolate first.
PROMPT

Note: recipes use unquoted <<PROMPT (not <<'PROMPT') so $(...) command substitutions expand inside heredoc.

Session Management

Session resume lets you continue a prior Codex conversation instead of starting fresh. Useful for multi-round review of the same artifact (plan v1 → v2), iterative debugging, or sustained brainstorming.

Session Arguments

Slug Rules

• Accepts [a-z0-9-]. Uppercase input is normalized to lowercase.
• Max 64 characters. Rejects Windows reserved names (CON, PRN, NUL, etc.).
• Choose descriptive slugs: review-auth-migration, brainstorm-caching-layer.

Flag Validation

These combinations are errors — hard-fail with a message before invoking Codex:

Session Workflow

The -o /tmp/codex-slug.txt paths in the snippets below are the Linux/macOS form. On Windows, write to c:/tmp/codex-slug.txt instead, per the <temp> convention in Execution Rules — Claude's Read tool resolves a literal /tmp/... path and fails on Windows.

Source the session manager before any session operation:

source "${CLAUDE_PLUGIN_ROOT}/skills/codex/session-mgr.sh"
smgr_init_dir codex

Stderr handling: Session calls redirect stderr to a temp file (2>"$STDERR_FILE") to capture the session ID. This replaces the existing 2>&1 or 2>/dev/null patterns used in one-shot calls. Do NOT combine 2>"$STDERR_FILE" with 2>&1 — they are mutually exclusive. One-shot calls (with --ephemeral) keep existing stderr handling unchanged.

Resume sandbox limitation: codex exec resume defaults to workspace-write regardless of the original session's sandbox setting. The -s flag is not supported on resume. This means sessions created with -s read-only (brainstorm, red-team, diff-review, etc.) silently widen on resume. Mitigation: session resume is most valuable for --full-auto modes (debug, plan-review, test-gaps) which already have write access. For read-only modes, one-shot with fresh piped content is preferred anyway.

Creating a new session (`--new-session <slug>`):

# 1. Validate slug
SLUG=$(smgr_validate_slug "<user-slug>")

# 2. Validate artifact if provided
if [[ -n "$ARTIFACT_PATH" ]]; then
  ARTIFACT_PATH=$(realpath "$ARTIFACT_PATH")
  if [[ ! -f "$ARTIFACT_PATH" ]]; then
    echo "ERROR: Artifact not found: $ARTIFACT_PATH" >&2; exit 1
  fi
fi

# 3. Acquire lock (with cleanup trap)
smgr_lock "$SLUG"
trap 'smgr_unlock "$SLUG"' EXIT

# 4. Run codex (NO --ephemeral), capture session ID from stderr
STDERR_FILE=$(mktemp)
codex exec [flags] -o /tmp/codex-slug.txt [prompt] 2>"$STDERR_FILE"
# [flags] and [prompt] follow the existing invocation patterns in the skill
# (Mode-to-Sandbox table, Base Prompt Template, Shell Pipeline Recipes).
# The session workflow wraps around those — it does not replace them.

# 5. Extract session ID from stderr, strip CRLF, validate UUID
SESSION_ID=$(sed -n 's/^session id: //p' "$STDERR_FILE" | tr -d '\r' | head -1)
rm -f "$STDERR_FILE"
if [[ -z "$SESSION_ID" ]]; then
  smgr_unlock "$SLUG"
  echo "ERROR: Could not capture Codex session ID from stderr." >&2; exit 1
fi
if [[ ! "$SESSION_ID" =~ ^[0-9a-f-]+$ ]]; then
  smgr_unlock "$SLUG"
  echo "ERROR: Invalid session ID format: '$SESSION_ID'" >&2; exit 1
fi

# 6. Create record (only after CLI session confirmed)
smgr_create "$SLUG" "$SESSION_ID" "$ARTIFACT_PATH"

# 7. Release lock
smgr_unlock "$SLUG"

Resuming a session (`--session <slug>`):

# 1. Validate slug
SLUG=$(smgr_validate_slug "<user-slug>")

# 2. Acquire lock (with cleanup trap)
smgr_lock "$SLUG"
trap 'smgr_unlock "$SLUG"' EXIT

# 3. Look up CLI session ID
SESSION_ID=$(smgr_lookup "$SLUG")

# 4. Resume codex
codex exec resume "$SESSION_ID" [flags] -o /tmp/codex-slug.txt [prompt]
# If resume fails with "session not found" → zombie. Hard-fail.

# 5. Update last-used timestamp
smgr_update "$SLUG"

# 6. Update artifact path if --artifact provided on resume
if [[ -n "${ARTIFACT_PATH:-}" ]]; then
  ARTIFACT_PATH=$(realpath "$ARTIFACT_PATH")
  if [[ ! -f "$ARTIFACT_PATH" ]]; then
    echo "WARNING: Artifact not found: $ARTIFACT_PATH (path not updated)" >&2
  else
    smgr_update_artifact "$SLUG" "$ARTIFACT_PATH"
  fi
fi

# 7. Release lock
smgr_unlock "$SLUG"

One-shot (default, no session flags):

codex exec --ephemeral [flags] -o /tmp/codex-slug.txt [prompt]
# No session management needed.

List sessions:

source "${CLAUDE_PLUGIN_ROOT}/skills/codex/session-mgr.sh"
smgr_init_dir codex
smgr_list

Delete session:

source "${CLAUDE_PLUGIN_ROOT}/skills/codex/session-mgr.sh"
smgr_init_dir codex
smgr_delete "<slug>"

Review-Mode Gating

When the mode is red-team or diff-review and --session is passed without --reuse-session, hard-fail:

"Review modes (red-team, diff-review) default to fresh sessions to prevent self-consistency bias. Pass --reuse-session to resume, or use --new-session for a new session."

This prevents asking the model to attack its own prior reasoning.

Zombie Detection

A zombie is a session where the CLI returns a definitive error on resume (session not found, invalid ID, auth mismatch). Transient errors (429, 503, network timeout) are retryable — do not treat as zombie.

On zombie detection: hard-fail with message "Session '<slug>' is a zombie (CLI session no longer exists). Use delete <slug> to remove the record."

Claude/Codex Collaboration Loop

Sequence for best results:

1. Claude gathers facts locally — grep, read files, run tests, collect logs
2. Claude sends focused artifact + question to Codex — smallest useful excerpt, not raw dumps
3. Codex synthesizes, critiques, or generates options — independent analysis
4. Claude validates Codex's output against actual codebase — check cited files exist, claims are accurate
5. Claude presents synthesis to user — both perspectives if disagreement exists

Never delegate raw repo exploration to Codex when Claude can do it faster with local tools. Codex adds value through independent reasoning, not file reading.

Convergence Mode (iterative review)

Some review tasks converge rather than conclude. When reviewing an evolving artifact — a spec, plan, or design that will go through multiple revisions — prefer running Codex in a convergence loop: repeat review → fix → re-review until the reviewer gives an affirmative verdict, the user stops, or scope drift is detected.

When to use

• Reviewing an iterating artifact (spec, plan, design) that likely needs several revisions.
• User has signaled iterative review; one-shot is insufficient.
• There is time for multiple rounds (2-5 min per round typical; larger artifacts or deep analysis can run longer).

Loop shape

1. Invoke Codex with the full artifact and a clear Question:.
2. Parse findings; summarize to the user; propose fixes.
3. Gate 1 — apply fixes. Ask yes-all / per-finding / skip. Apply as selected.
4. Gate 2 — continue or stop. Re-state the original one-sentence brief in your prompt. Ask continue / stop / switch-mode. If continue, loop to (1).
5. Terminate when the reviewer's verdict_text is affirmative for the mode ("approve" / "no redesign-class problem" / "no regressions" for red-team; "Yes." / "executable as-is" for compare-decide; "READY TO EXECUTE" / "approve" / "ready" for plan-review; "no regressions" / "approve" for diff-review) AND no findings remain open; OR user stops; OR scope drift detected (see below).

Across-round prompt construction

• Round 1: full artifact + question + (if using) structured directive.
• Round N > 1: also include a Previously identified findings: block listing prior findings (title, severity, status: addressed / skipped). This gives the reviewer drift-detection context and prevents re-finding the same issues by luck.
• After context compaction: if the user resumes a cycle that lost context, they paste the current findings list back into the conversation. No persistent on-disk state is required; findings fit in the conversation.

Anti-pattern: the scope-drift spiral

The convergence loop is excellent at deepening a design and terrible at questioning its direction. Each round's findings are individually valid, but the cumulative effect can pull the artifact into a regime the user never asked for. Signs of drift:

• The artifact has grown by hundreds of lines per round.
• New rounds are finding issues in fixes you added in prior rounds rather than in the original artifact.
• Routine "yes-all" user responses with no pushback — either the user trusts the process (fine) or you're not surfacing options honestly (not fine).
• Codex Simplifications findings get absorbed as refactors ("merge X and Y") rather than used as stop signals ("did we need X or Y in the first place?").
• Per-finding drift detection (exact-title / evidence-overlap) shows zero drift — because brief-level drift does not show up as finding recurrence.

What to do:

1. At every Gate 2, re-state the original one-sentence brief in your presentation. Don't just ask "continue?" — ask "given the original goal, does this next round of fixes make sense?"
2. Weight Simplifications at least as heavily as Breakage. The default bias is toward addition; correct for it by actively looking for "remove this" opportunities.
3. Monitor artifact size growth. If a round grows the artifact by >50%, that is a signal to stop and re-confirm scope before continuing.
4. Treat routine user "yes-all" as a warning, not a go-ahead. Add friction on purpose. Present simplify-first and remove-this options alongside add-machinery options.

Handling Output

• Never relay raw Codex output to user. Extract disagreements, key risks, best next step.
• If Codex disagrees with your approach, present both perspectives and let user decide.
• If Codex finds clear errors, fix them before presenting. Flag debatable ones for user.
• Structure alternatives as comparison table when presenting multiple options.
• Retry rule: if Codex returns generic advice, rerun with narrower question and better-scoped artifact. Do not retry more than once.

Summarization Fidelity

Codex summaries are a recurring source of QA errors. The failure mode is compression-with-punch: turning measured verbs into rhetorical ones and skimming past inline prose citations. Three rules, ordered by frequency of violation:

1. Quote evaluative language verbatim, never paraphrase it

Codex's verbs are calibrated. "I disagree" ≠ "rejects". "too narrow" ≠ "misses an entire class". "targets the pattern class" ≠ "highest-leverage". If Codex used a measured verb, quote it — do not substitute a stronger rhetorical synonym when compressing.

• Bad: "Codex rejects the plan in 7 of 7 dimensions."
• Good: Codex restructures 6 phases and says "I disagree with the belief that Phase 1 is highest-leverage" on the 7th.

2. Do not add explanatory bridges that are not in source

When Codex makes a bare claim ("X is too narrow") without giving an example, do not add a parenthetical that supplies one from elsewhere in your context. The connection between two true facts is fabrication if Codex did not make it.

• Bad: "Column 3 is too narrow (misses the platform-failure class — the InboundNonce+UsedHash bundle died on this)"
• Good: "Column 3 is too narrow." [no example given by Codex]

3. Count inline citations in prose, not just bullet lists

Codex sometimes cites file:line inside an explanatory sentence rather than in a bullet. When counting call sites or references, scan the prose, not just the list markers. Undercounts happen when you enumerate bullets and miss inline citations.

Mandatory QA for high-stakes modes

After summarizing Codex output for plan-review, red-team, diff-review, exhausted-hypotheses, or attack-surface modes, run the reviewer agent on your summary before presenting it to the user. These modes produce the longest outputs and the highest-consequence summaries. Three of three session-observed summarization errors occurred in these modes. The QA step is non-optional for them.

Low-stakes modes (brainstorm, spec-extraction, explain, test-gaps, compare-decide, debug, post-mortem, rollout-rollback) do not require the QA step — rely on the three rules above.

Short-output exception: If the Codex output is under ~200 words AND contains no bullet lists, numbered findings, or file:line citations, the mandatory QA step can be skipped. Short prose responses leave little room for strength amplification or undercounts — the three failure modes all require enough surface area to happen. A one-paragraph Codex verdict does not need a reviewer pass.

Reviewer-unavailable fallback: If the reviewer agent is unavailable (tool failure, subagent budget exhausted), fall back to self-review against the three rules: re-read the source Codex output, quote every evaluative verb verbatim in the summary, and count inline citations in prose as well as in bullets. Flag the fallback explicitly in the presented summary: "(self-reviewed against fidelity rules — no reviewer agent pass)".

The QA check runs against the source Codex output and your summary, flagging strength amplification, fabricated bridges, undercounts, and line-number hallucinations. Errors caught in QA must be corrected in the summary before presentation, not annotated afterward.

Anti-Patterns

Do NOT do these when prompting Codex:

• Vague prompts — "What do you think?" or "Any ideas?" → Always give constraints, desired output shape, concrete question
• Dumping entire files — sending 2000 lines when 80 lines of relevant diff would do → Use smallest useful artifact
• Asking Codex to execute — Codex adds value through independent reasoning, not running commands → Use for analysis and critique
• Skipping "Current belief" (in red-team/debug modes) — Codex can't challenge what it doesn't know you believe → State your hypothesis so it can attack it. Brainstorm mode is fine without one.
• Trusting without validating — Codex may hallucinate file names, functions, or line numbers → Always verify cited artifacts against actual codebase

Troubleshooting