mcpbeat Sign in

Codex Exec Skill for Codex

Run autonomous task execution using the codex CLI. Use when the user asks to \"codex exec\", \"run codex exec\", \"execute a task with codex\", or \"delegate to codex\".

2k tokens
context cost
the whole folder, loaded on every use
2
files
instructions only
0
copies elsewhere
how many repositories repackaged it
398
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/tobihagemann/turbo --skill codex-exec

The instruction itself

10 sections, as written by the author

Codex Exec

Autonomous task execution via the codex CLI. Runs non-interactively. Progress streams to stderr; final result on stdout.

codex exec "task description" < /dev/null

For large context, pipe it via stdin. The prompt stays as the argument, context is passed as <stdin> automatically:

cat context.txt | codex exec "question about the context"

Route text you did not author through this channel whatever its size — a diff, file contents, a code comment, a plan or spec, third-party feedback, command output. Keep backticks and $ out of the quoted argument even in text you wrote, since both stay live inside it. Write the context file with the Write tool so nothing is interpreted on the way in.

Sandbox

All codex Bash calls require dangerouslyDisableSandbox: true (network access to OpenAI API). Without it, codex crashes with an Operation not permitted panic from the system-configuration crate before the model runs.

Stdin Gotcha

Codex reads from stdin whenever stdin is non-TTY (per codex exec --help: "If stdin is piped and a prompt is also provided, stdin is appended as a <stdin> block"). In subagent and subprocess contexts the harness leaves stdin connected to a pipe that never EOFs, so a bare codex exec "..." hangs forever, printing only Reading additional input from stdin....

Always redirect stdin on non-piped invocations:

codex exec "task description" < /dev/null

The piped form (cat context.txt | codex exec "...") is safe — cat closes the pipe after the file, sending EOF.

Synchronous Execution

Run codex via the Bash tool as a foreground call (do not set run_in_background). Set timeout: 600000, the Bash maximum. A larger value is not honored: the harness backgrounds the call immediately and hard-kills codex at 600s, truncating its output. Within a valid timeout, codex runs foreground and returns its result synchronously when it finishes in time.

Capture the session id: from the run's stderr chrome as it starts; it never appears in the -o file, and recovery depends on it. Do not pass --ephemeral when the run may need recovery, since it persists no session files.

A run that outlives the timeout is normally force-backgrounded: the result carries a task ID and an output file path, and the run continues to completion. Recover it by reading the output file: Read the path, then Read it again once the <task-notification> reports completion.

Rarely the run is hard-killed instead, giving an error exit (code 143) reading Command timed out after <duration> with no task ID and no -o file. Do not re-run the prompt from scratch; that discards the work already done and hits the same ceiling. Resume the session with a fresh output path, asking for the findings as the final message rather than as a file write:

codex exec -o <fresh-output-path> resume <session-id> \
  "Reply now with your complete findings as your final message." < /dev/null

resume inherits the original session's sandbox, so pass --sandbox only to change it. When the kill left no session id in hand, recover it from the newest ~/.codex/sessions/<YYYY>/<MM>/<DD>/rollout-<timestamp>-<session-id>.jsonl (the id is the UUID in the filename), listing a single day directory so the ordering is right. codex exec resume --last also works when no other codex run is in flight. Do not consult ~/.codex/session_index.jsonl; it lags behind the rollout files.

Never wait with Monitor (it returns immediately, and events that arrive after your final text are dropped), and never return the task ID, an interim file snapshot, or "Waiting for codex to finish" as the result — each is a false-empty return.

Transient Crash Retry

Re-run the command once when the Bash call returned an error exit with no stdout and no task ID. A timeout is not a crash: when the error text reads Command timed out after <duration>, resume the session per Synchronous Execution rather than re-running. Recover a force-backgrounded run per Synchronous Execution rather than retrying it. Keep the same prompt; when the run writes to an -o file, point the retry at a fresh path. Treat a second failure as final.

Treat models-manager and cache-TTL errors as non-fatal warnings. Read the error text for usage-limit and authentication signatures and report those without retrying.

Permission Levels

| Level | Flag | When to Use |

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

| Read-only | --sandbox read-only | Analysis, code reading, generating reports |

| Workspace write | --sandbox workspace-write | Editing files within the project |

| Full access | --sandbox danger-full-access | Installing packages, running tests, system operations |

| Full auto | --full-auto | Combined with a sandbox level for unattended execution |

Omitting --sandbox falls back to the codex config and project trust level (trusted projects run workspace-write), so always pass the flag explicitly.

For fix or implementation tasks, default to --sandbox workspace-write --full-auto so Codex can edit files without confirmation prompts. Use --sandbox read-only for analysis or research tasks.

Options

| Option | Description |

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

| --full-auto | Allow file edits without confirmation prompts |

| --sandbox <level> | Permission level: read-only, workspace-write, danger-full-access |

| --json | JSON Lines output (progress + final message) |

| -o <path> | Write final message to a file |

| --output-schema <path> | Enforce JSON Schema on the output |

| --ephemeral | No persisted session files |

| --skip-git-repo-check | Bypass git repository requirement |

Prompt Shaping

Codex uses XML tags in its own context scaffolding, so the model parses them natively. Structure prompts with XML tags for clearer responses:

  • <task>: The concrete job and relevant context.
  • <structured_output_contract>: Required output shape, ordering, and format.
  • <compact_output_contract>: Same purpose but for concise prose responses.
  • <grounding_rules>: When claims must be evidence-based.
  • <dig_deeper_nudge>: Push past surface-level findings to check for second-order failures.
  • <verification_loop>: When correctness matters — ask Codex to verify before finalizing.

Keep prompts compact, with tight output contracts. One clear task per exec call. For a large scope, instruct codex to report findings as it goes rather than verifying exhaustively before reporting, so a run that hits the timeout ceiling still yields usable output.

Parallel Execution

Codex supports parallel sub-agents via spawn_agent / wait_agent. The model will not fan out unless the prompt explicitly requests it. See references/parallel-execution.md for patterns and limitations.

Interpreting Results

  • Exec output is a starting point, not a guaranteed solution
  • Cross-reference suggestions with project documentation and conventions
  • Test incrementally rather than applying all changes at once
  • For file-editing tasks, always review the diff before committing

Other skills for the same job

different authors, same section of the catalogue
MCP Builder
by anthropics
vendor ×13

Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).

30k tokens scripts
Changelog Generator
by frostant
×9

Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.

774 tokens
Finishing A Development Branch
by ZhanlinCui
×7

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

1k tokens
MCP Builder
by JayZeeDesign
×7

Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).

37k tokens scripts
Vercel React Native Skills
by vercel-labs
vendor ×6

React Native and Expo best practices for building performant mobile apps. Use when building React Native components, optimizing list performance, implementing animations, or working with native modules. Triggers on tasks involving React Native, Expo, mobile performance, or native platform APIs.

39k tokens
Vercel React Best Practices
by ratacat
×5

React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.

34k tokens
Next Best Practices
by vercel-labs
vendor ×4

Next.js best practices - file conventions, RSC boundaries, data patterns, async APIs, metadata, error handling, route handlers, image/font optimization, bundling

20k tokens
Using Git Worktrees
by ZhanlinCui
×4

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification

1k tokens

How to use it

Copy the folder

Take tobihagemann/codex-exec from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.