/codex

name: codex
description: Use when the user asks to run Codex CLI (codex exec, codex resume) or references OpenAI Codex for code analysis, refactoring, or automated editing

Codex Skill Guide

Running a Task

1. 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.

2. Select the sandbox mode required for the task; default to `--sandbox read-only` unless edits or network access are necessary. 3. 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)

4. Always use --skip-git-repo-check. 5. 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. 6. **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. 7. **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. 8. Run the command, capture stdout/stderr (filtered as appropriate), and summarize the outcome for the user. 9. **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

1. State your disagreement clearly to the user 2. Provide evidence (your own k