Codex

Codex Skill Guide

Running a Task

• For a new session (resumes inherit the prior model/effort — see step 5), ask the user (via AskUserQuestion) which model AND which reasoning effort to use, in a single prompt with two questions. When the user expresses no preference, default to gpt-5.6-sol at high.
• Model — default gpt-5.6-sol:
• *GPT-5.6:* gpt-5.6-sol (frontier / most capable — default), gpt-5.6-terra (balanced, everyday), gpt-5.6-luna (fast & affordable)
• *Legacy (kept for compatibility):* gpt-5.5, gpt-5.4, gpt-5.4-mini, gpt-5.3-codex-spark, gpt-5.3-codex
• Reasoning effort — default high: low, medium, high, xhigh, max, ultra.
• max/ultra require a GPT-5.6 model; ultra is only on sol/terra (luna caps at max); legacy models cap at xhigh.
• ultra = maximum reasoning with automatic task delegation (slowest and most expensive — reserve for the hardest jobs).
• If the chosen effort exceeds the chosen model's maximum, fall back to that model's highest supported effort and tell the user.
• Select the sandbox mode required for the task; default to --sandbox read-only unless edits or network access are necessary.
• Assemble the command with the appropriate options:
• -m, --model <MODEL>
• --config model_reasoning_effort="<low|medium|high|xhigh|max|ultra>" (max/ultra only on GPT-5.6 models; ultra only on sol/terra — see step 1)
• --sandbox <read-only|workspace-write|danger-full-access>
• --full-auto
• -C, --cd <DIR>
• --skip-git-repo-check
• "your prompt here" (as final positional argument)
• Always use --skip-git-repo-check.
• When continuing a previous session, use codex exec --skip-git-repo-check resume --last via stdin. When resuming don't use any configuration flags unless explicitly requested by the user e.g. if he species the model or the reasoning effort when requesting to resume a session. Resume syntax: echo "your prompt here" | codex exec --skip-git-repo-check resume --last 2>/dev/null. All flags have to be inserted between exec and resume.
• IMPORTANT: By default, append 2>/dev/null to all codex exec commands to suppress thinking tokens (stderr). Only show stderr if the user explicitly requests to see thinking tokens or if debugging is needed.
• IMPORTANT (stdin): codex exec always reads stdin and concatenates it with the positional prompt -- even when the prompt is fully supplied as a positional argument. If stdin is not closed, codex blocks forever. When invoking from a harness (background tasks, hooks, scripts where stdin is not a TTY but also not closed), explicitly redirect stdin: append </dev/null to the command, e.g. codex exec ... "prompt" </dev/null 2>/dev/null. Symptom of getting this wrong: zero bytes of stdout, zero CPU accumulated, process appears hung indefinitely.
• Run the command, capture stdout/stderr (filtered as appropriate), and summarize the outcome for the user.
• After Codex completes, inform the user: "You can resume this Codex session at any time by saying 'codex resume' or asking me to continue with additional analysis or changes."

Quick Reference

| Use case | Sandbox mode | Key flags |

| --- | --- | --- |

| Read-only review or analysis | read-only | --sandbox read-only 2>/dev/null |

| Apply local edits | workspace-write | --sandbox workspace-write --full-auto 2>/dev/null |

| Permit network or broad access | danger-full-access | --sandbox danger-full-access --full-auto 2>/dev/null |

| Resume recent session | Inherited from original | echo "prompt" \| codex exec --skip-git-repo-check resume --last 2>/dev/null (no flags allowed) |

| Run from another directory | Match task needs | -C <DIR> plus other flags 2>/dev/null |

Execution timeouts

Codex produces no intermediate output — it writes the result only at completion. If the process is killed before finishing, the output file is silently empty (no error).

Preferred approach: run synchronously — eliminates timeout risk entirely and the conversation waits for the result anyway.

If running in background, set the execution timeout based on reasoning effort:

| Reasoning effort | Timeout |

|---|---|

| low | 150s |

| medium | 300s |

| high | 600s |

| xhigh | 1200s |

| max | 1800s |

| ultra | 1800s |

Following Up

• After every codex command, immediately use AskUserQuestion to confirm next steps, collect clarifications, or decide whether to resume with codex exec resume --last.
• When resuming, pipe the new prompt via stdin: echo "new prompt" | codex exec resume --last 2>/dev/null. The resumed session automatically uses the same model, reasoning effort, and sandbox mode from the original session.
• Restate the chosen model, reasoning effort, and sandbox mode when proposing follow-up actions.

Critical Evaluation of Codex Output

Codex is powered by OpenAI models with their own knowledge cutoffs and limitations. Treat Codex as a colleague, not an authority.

Guidelines

• Trust your own knowledge when confident. If Codex claims something you know is incorrect, push back directly.
• Research disagreements using WebSearch or documentation before accepting Codex's claims. Share findings with Codex via resume if needed.
• Remember knowledge cutoffs - Codex may not know about recent releases, APIs, or changes that occurred after its training data.
• Don't defer blindly - Codex can be wrong. Evaluate its suggestions critically, especially regarding:
• Model names and capabilities
• Recent library versions or API changes
• Best practices that may have evolved

When Codex is Wrong

• State your disagreement clearly to the user
• Provide evidence (your own knowledge, web search, docs)
• Optionally resume the Codex session to discuss the disagreement. Identify yourself as Claude so Codex knows it's a peer AI discussion. Use your actual model name (e.g., the model you are currently running as) instead of a hardcoded name:

   echo "This is Claude (<your current model name>) following up. I disagree with [X] because [evidence]. What's your take on this?" | codex exec --skip-git-repo-check resume --last 2>/dev/null

• Frame disagreements as discussions, not corrections - either AI could be wrong
• Let the user decide how to proceed if there's genuine ambiguity

Error Handling

• Stop and report failures whenever codex --version or a codex exec command exits non-zero; request direction before retrying.
• Before you use high-impact flags (--full-auto, --sandbox danger-full-access, --skip-git-repo-check) ask the user for permission using AskUserQuestion unless it was already given.
• When output includes warnings or partial results, summarize them and ask how to adjust using AskUserQuestion.