/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-6-astra` at `high`.

• **Model** — default `gpt-6-astra`:
• *GPT-6:* `gpt-6-astra` (frontier / most capable — **default**), `gpt-6.1-sol` (latest workhorse for coding and everyday work), `gpt-6-sol` (previous-generation workhorse), `gpt-6-luna` (fast & affordable, easier tasks)
• *GPT-5.6:* `gpt-5.6-sol` (reliable agentic workhorse), `gpt-5.6-terra` (balanced, everyday), `gpt-5.6-luna` (fast & affordable)
• *Legacy (rejected as unsupported when Codex is signed in with a ChatGPT account):* `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-6 or GPT-5.6 model; `ultra` is only on `astra`/`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-6 / GPT-5.6 models; ultra only on astra/sol/terra — see step 1)
• `--sandbox <read-only|workspace-write|danger-full-access>`
• `-C, --cd <DIR>`
• `--skip-git-repo-check` (only when permitted by step 4)
• `"your prompt here"` (as final positional argument)

4. Determine whether the effective target directory is inside a Git repository, including any explicit working directory such as `-C <DIR>`.

• Unknown Git context is unresolved, not consent; resolve it before invoking.
• Inside Git, omit `--skip-git-repo-check` by default; include it only for an applicable explicit request for that flag.
• Outside Git, include it only with applicable approval or an explicit flag request. If permission is missing, ask using `AskUserQuestion` and do not invoke until permission is given.
• Applicable previous approval satisfies the gate; a later denial overrides any previous approval or request. A general request to use Codex or a sandbox mode is not skip-flag approval.
• If denied inside Git, omit the flag and continue only if the remaining task is authorized. If denied outside Git, stop and explain the blocked invocation.
• Do not use an unapproved retry, fallback, or Git initialization to bypass this gate.

5. When continuing a previous session, use `codex exec resume --last` via stdin. Resuming does not authorize `--skip-git-repo-check`; apply step 4 before each resume and add the flag only when permitted. 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 inside Git by default: `echo "your prompt here" | codex exec 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 2>/dev/null` | | Permit network or broad access | `danger-full-access` | `--sandbox danger-full-access 2>/dev/null` | | Resume recent session | Inherited from original | `echo "prompt" \| codex exec resume --last 2>/dev/null` (inside Git by default; no configuration flags unless explicitly requested; apply step 4 to the skip flag) | | 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