sending-to-codex

Delegate tasks or ask questions to OpenAI's Codex CLI from within Claude Code. Use this skill when the user says "ask codex", "send to codex", "delegate to codex", "have codex do this", "get codex's opinion", "run this in codex", or wants to offload a coding task or question to the Codex agent. Supports both fire-and-forget coding tasks (fix bugs, add features, refactor) and research questions (analyze code, explain behavior, get a second opinion).

6 stars

bytdhopper

View on GitHub Installation ↓

Best use case

sending-to-codex is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Teams using sending-to-codex should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

You only need a quick one-off answer and do not need a reusable workflow.
You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/sending-to-codex/SKILL.md --create-dirs "https://raw.githubusercontent.com/tdhopper/dotfiles2.0/main/.claude/skills/sending-to-codex/SKILL.md"

Manual Installation

Download SKILL.md from GitHub
Place it in .claude/skills/sending-to-codex/SKILL.md inside your project
Restart your AI agent — it will auto-discover the skill

How sending-to-codex Compares

Feature / Agent	sending-to-codex	Standard Approach
Platform Support	Not specified	Limited / Varies
Context Awareness	High	Baseline
Installation Complexity	Unknown	N/A

Frequently Asked Questions

What does this skill do?

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

Related Guides

Best AI Skills for Claude

Explore the best AI skills for Claude and Claude Code across coding, research, workflow automation, documentation, and agent operations.

Cursor vs Codex for AI Workflows

Compare Cursor and Codex for AI coding workflows, repository assistance, debugging, refactoring, and reusable developer skills.

AI Agents for Coding

Browse AI agent skills for coding, debugging, testing, refactoring, code review, and developer workflows across Claude, Cursor, and Codex.

SKILL.md Source

# Sending Tasks and Questions to Codex CLI

Delegate coding tasks or ask questions to OpenAI's Codex CLI (`codex exec`) from within Claude Code. Codex runs non-interactively and returns its output.

## Choosing the Right Mode

| Intent | Approach | Key Flags |
|--------|----------|-----------|
| **Coding task** (fix, build, refactor) | `codex exec` with task prompt | `--full-auto`, `-C <dir>` |
| **Question / analysis** | `codex exec` with question prompt | `--ephemeral`, `-o <file>` |
| **Code review** | `codex review` | `--uncommitted`, `--base <branch>` |

## Constructing the Command

### Coding Tasks

For tasks where Codex should modify files:

```bash
codex exec --full-auto -C <working-dir> "<task description>"
```

- `--full-auto` enables sandboxed automatic execution (no approval prompts)
- `-C <dir>` sets the working directory (use the relevant repo/worktree path)
- The task description should be specific and actionable

**Example:**
```bash
codex exec --full-auto -C /Users/thopper/c/my-project "Fix the broken import in src/utils.py that causes a NameError when calling parse_config()"
```

### Questions and Analysis

For questions where you want Codex's analysis without file changes:

```bash
codex exec --ephemeral -o /tmp/codex-response.md -C <working-dir> "<question>"
```

- `--ephemeral` avoids persisting the session to disk
- `-o <file>` writes Codex's final response to a file for easy reading
- After the command completes, read the output file to relay the answer

**Example:**
```bash
codex exec --ephemeral -o /tmp/codex-response.md -C /Users/thopper/c/my-project "Explain how the converter DAG in diffusify_core/converters works and identify any potential circular dependencies"
```

### Code Review

For reviewing changes:

```bash
# Review uncommitted changes
codex review --uncommitted -C <working-dir>

# Review changes against a base branch
codex review --base main -C <working-dir>

# Review with custom instructions
codex review --base main -C <working-dir> "Focus on security vulnerabilities and error handling"
```

## Optional Flags

| Flag | Purpose |
|------|---------|
| `-m <model>` | Override the model (e.g., `-m o3`, `-m gpt-5.3-codex`) |
| `-s read-only` | Sandbox to read-only (good for questions, prevents file changes) |
| `--add-dir <dir>` | Add extra writable directories |
| `-i <file>` | Attach an image to the prompt |

## Workflow

1. **Understand the user's intent**: Is this a coding task (Codex should change files) or a question (Codex should analyze and respond)?

2. **Formulate the prompt**: Write a clear, specific prompt for Codex. Include:
   - What to do or what to answer
   - Relevant file paths or context
   - Any constraints (e.g., "don't modify tests", "use the existing pattern in X")

3. **Pick the working directory**: Use the repo root or the specific worktree where changes should land. Default to the current working directory if appropriate.

4. **Run the command**: Execute via Bash tool. For long-running tasks, consider running in the background.

5. **Report results**:
   - For coding tasks: summarize what Codex did, check `git diff` in the target directory
   - For questions: read the output file (`-o`) and relay the answer
   - For reviews: present the review findings

## Tips

- **Long prompts**: For complex tasks, pipe the prompt from stdin:
  ```bash
  codex exec --full-auto -C <dir> <<'EOF'
  Your detailed multi-line prompt here.
  Include specific files, constraints, and expected outcomes.
  EOF
  ```

- **Background execution**: For tasks that may run long, use Bash with `run_in_background: true` and check back later.

- **Combining outputs**: After a coding task, inspect the changes with `git diff` in the target directory before reporting back.

- **Read-only for safety**: When asking questions, add `-s read-only` if you want to guarantee Codex won't modify any files.

Related Skills

stop-slop

from tdhopper/dotfiles2.0

Use this skill when writing or editing prose to eliminate predictable AI writing patterns. Helps make writing more direct, authentic, and human.

sonos-control

from tdhopper/dotfiles2.0

Control Sonos speakers on Tim's home network. Use when the user wants to (1) play, pause, or stop music on Sonos speakers, (2) change volume on speakers, (3) skip tracks, (4) check what's playing, (5) see speaker status, (6) group or ungroup speakers, (7) any Sonos or music/audio playback task involving home speakers. Triggers on "sonos", "speakers", "play music", "what's playing", "volume", "turn up", "turn down", "pause music", "stop music".

slack-message

from tdhopper/dotfiles2.0

Draft and send Slack messages in Tim's natural voice. Use when the user wants to (1) post an update to a channel, (2) draft a Slack message, (3) share something on Slack, (4) send a DM, (5) reply in a thread. Applies Tim's Slack writing style and prose principles automatically.

skill-creator

from tdhopper/dotfiles2.0

Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.

reviewing-writing

from tdhopper/dotfiles2.0

Review and critique writing using Michael Nielsen's principles on craft. Analyzes text for purpose focus, brevity, danger words, opening strength, originality, reader psychology, truthfulness, and title impact. Use when the user says "review my writing", "nielsen review", "writing review", "review this writing", "critique my writing", or asks for feedback on prose quality.

reviewing-code

from tdhopper/dotfiles2.0

Review pull requests, branch changes, or code diffs. Triggers on "review this PR", "review my changes", "code review", "review branch", or GitHub PR URLs. Focuses on bugs, tests, complexity, and performance - not linting.

resend-email

from tdhopper/dotfiles2.0

Send emails via Resend.com API. Use when the user wants to (1) send an email, (2) email someone, (3) send a message to an email address, (4) send email with attachments, (5) schedule an email for later. Requires RESEND_API_KEY environment variable.

refresh-dotfiles

from tdhopper/dotfiles2.0

Full sync of personal (yadm) and work (yadm-work) dotfiles. Pulls remote changes, commits and pushes local changes, and audits for untracked files that should be tracked. Use when the user says 'refresh yadm', 'sync dotfiles', 'dotfiles sync', or 'update dotfiles'.

omnifocus

from tdhopper/dotfiles2.0

Interact with OmniFocus task manager via the command-line interface (@stephendolan/omnifocus-cli). Use when the user wants to: (1) Add tasks or projects to OmniFocus, (2) List, view, or search tasks/projects, (3) Update or complete tasks, (4) Manage inbox items, (5) Work with tags and analyze tag usage, (6) Process or organize their OmniFocus database from the command line.

omnifocus-triage

from tdhopper/dotfiles2.0

Interactively process OmniFocus inbox items using AskUserQuestion. Use when the user wants to (1) triage their inbox, (2) process inbox items, (3) organize their OmniFocus inbox, (4) clear out their inbox, (5) do a GTD-style inbox review. Triggers on "triage inbox", "process inbox", "organize inbox", "clear inbox", "inbox zero".

Nightshift

from tdhopper/dotfiles2.0

Manage and interact with Nightshift, an AI-powered development automation tool that runs coding tasks during off-hours.

modal

from tdhopper/dotfiles2.0

Run code on Modal's cloud infrastructure via `uvx modal run`. Use whenever the user wants to (1) validate handbook tutorial shell commands on a fresh Debian container from scratch (uv, pip, build tooling, etc. with no cached state from Tim's laptop), (2) test GPU-specific Python code (torch, CUDA, cupy, transformers, CUDA wheels) on real hardware, or (3) reproduce a "does this actually work from zero?" check. Trigger on phrases like "run this on modal", "test on a fresh machine", "try this on a GPU", "validate from scratch", "does the tutorial work end-to-end", "test this without my venv state", or any mention of modal.com / cloud GPUs / ephemeral containers for verification. Also trigger when the user is writing a handbook tutorial that involves GPU installs (PyTorch, CUDA wheels) and they want to confirm the commands work.