Consult Codex

Consult Codex

Multi-turn consultation with Codex CLI. Maintains a conversation across multiple turns using session persistence, unlike single-shot /codex-exec.

Step 1: Gather Context

Identify the 2-5 files most relevant to the problem. Formulate a clear, specific question. Include what has been tried and relevant constraints.

Step 2: Start Session

Run codex exec with -o to capture the response cleanly. Default to -s read-only for safety. Use -s workspace-write when the consultation requires running code or reading files outside the workspace.

All codex Bash calls require dangerouslyDisableSandbox: true (network access to OpenAI API). Use .turbo/ as the temp directory — it is in the working directory (sandbox-writable), gitignored, and avoids $TMPDIR path mismatches between sandbox and non-sandbox mode.

**Non-piped codex exec invocations require " : The concrete question and relevant context.

• ``: Desired output shape and brevity requirements.
• ``: Same purpose but for structured/schema responses.
• ``: When claims must be evidence-based (review, research, root-cause analysis).
• ``: Push past surface-level findings to check for second-order failures.
• ``: When correctness matters — ask Codex to verify before finalizing.

Example prompt for a diagnosis question:

Diagnose why the auth middleware rejects valid tokens after the session refactor.
Return: (1) most likely root cause, (2) evidence, (3) smallest safe next step.
Ground every claim in the provided context or tool outputs. Label hypotheses explicitly.

For correctness-critical questions, add `` asking Codex to verify its answer before finalizing.

Keep prompts compact, with tight output contracts. One clear task per Codex turn.

For long context that won't fit inline, write a context file and pipe it via stdin. The prompt stays as the argument, context pipes in as `` automatically:

cat > ".turbo/codex/$CODEX_TAG-ctx.txt" 
EOF
cat ".turbo/codex/$CODEX_TAG-ctx.txt" | codex exec -s read-only -o ".turbo/codex/$CODEX_TAG.txt" ""

Parse the session id: line from the CLI output. This UUID is needed for follow-up turns.

The session id: line appears only in stdout chrome, never in the -o file. When a follow-up turn may be needed, do not pipe codex exec stdout through head/tail or any filter that drops early lines — that silently discards the session id and makes resume impossible. If stdout must be truncated, also grep for session id: so the id is always retained.

Run via the Bash tool (timeout: 600000, do not set run_in_background) per turn.

Step 3: Read and Evaluate Response

The -o file contains only Codex's response (cleaner than stdout, which includes CLI chrome and tool-use logs). Read from .turbo/codex/$CODEX_TAG.txt. If the output is too large for the Read tool, read stdout from the Bash tool result instead.

Assess whether:

• The answer is sufficient and actionable
• Follow-up questions would improve the answer
• The response contradicts known project facts (verify before accepting)

If no follow-up is needed, skip to the Synthesize step.

Step 4: Follow Up

Resume the session with the parsed session ID (not --last, which is unsafe for parallel use):

codex exec resume  -o ".turbo/codex/$CODEX_TAG.txt" "" < /dev/null

The -s flag is not available for resume. It inherits sandbox settings from the original session.

Return to Step 3. Cap at 5 turns to prevent runaway conversations.

Step 5: Synthesize

Summarize the key insights from the consultation. Cross-reference suggestions with project documentation and conventions before applying. Codex suggestions are starting points, not guaranteed solutions.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: tobihagemann
• Source: tobihagemann/turbo
• License: MIT

Install and usage instructions live in the source repository linked above.