Claude codex-cli skill: 10 ways to bridge Claude Code and OpenAI Codex CLI
Ten real bridges between Claude Code and OpenAI Codex CLI — codex exec wrappers, second-opinion review slash commands, parallel git worktrees, MCP and skill reuse, cost-based routing, and codex resume handoffs — each as one Claude prompt with the exact shell it produces.
Already know what skills are? Skip to the cookbook. First time? Read the explainer then come back. Need the install? It’s on the /skills/codex-cli page.

On this page · 21 sections▾
- What this skill does
- The cookbook
- Install + README
- Watch it built
- 01 · Wrap a Claude prompt as a one-shot codex exec command
- 02 · Run Codex CLI as a subprocess from Claude Code for second-opinion review
- 03 · Reuse a Claude Code skill from inside Codex CLI
- 04 · Side-by-side benchmark: same prompt, both CLIs, diffed outputs
- 05 · Hand off a long-running task: Claude plans, Codex implements
- 06 · Route by cost: Codex CLI for simple bugs, Claude for hard ones
- 07 · Run both agents in parallel via git worktree
- 08 · Codex CLI for refactor; Claude Code for tests
- 09 · Pipe Codex CLI output through Claude for critique
- 10 · Resume a Codex session from inside a Claude Code agent loop
- Community signal
- The contrarian take
- Real bridges shipped
- Gotchas
- Pairs well with
- FAQ
- Sources
What this skill actually does
Sixty seconds of context before the cookbook — what the codex-cli skill is, what Claude returns when you invoke it, and the one thing it does NOT do for you.
What this skill actually does
“Orchestrate OpenAI Codex CLI for parallel task execution. As orchestrator, analyze tasks, inject context, manage sessions, and coordinate parallel instances.”
— kingkongshot, the skill author (data/skills.json description) · /skills/codex-cli
What Claude returns
You ask Claude to delegate or orchestrate a coding task; Claude returns a runnable shell wrapper around `codex exec` (one-shot non-interactive runs that stream JSONL events to stdout and write the assistant's last message via `--output-last-message`), or `codex resume --last` (continue the most recent session by id), with explicit `--sandbox` (read-only / workspace-write / danger-full-access), `-m gpt-5.3-codex`, and `--full-auto` choices. For multi-task work it returns a Makefile or bash loop that fans out one Codex call per atomic task.
What it does NOT do
It does not install Codex CLI for you (`npm install -g @openai/codex` or `brew install --cask codex` first), does not log you in (`codex login` is on you), and does not replace Claude Code — it pairs them.
How you trigger it
delegate this refactor to Codexrun a second-opinion review with codex execorchestrate a parallel Codex run alongside Claude CodeCost when idle
~120 tokens at idle (the skill name + description in the system prompt). The body and references load only when triggered.
The cookbook
Each entry below is a working bridge between Claude Code and OpenAI Codex CLI. They run in the order I’d teach them — the early ones (one-shot wrapper, second-opinion review, skill reuse) are reusable on every repo, the later ones lean on Codex CLI features you only need when the shape gets specific (parallel worktrees, plan/implement splits, session resume). Every entry pairs with one or two skills or MCP servers you already have on mcp.directory.
One frame worth naming up front: this is not “Codex CLI vs Claude Code.” The two CLIs have different strengths and the codex-cli skill exists because the right answer is usually both. Claude Code is the better long-context planner; Codex CLI’s non-interactive codex exec mode is the better disposable subagent and ChatGPT Plus quota is hard to beat for cheap edits. The cookbook codifies the routing decisions so you stop re-deciding them per task.
Install + README
If the skill isn’t on your machine yet, here’s the one-liner. The full install panel (Claude Code, Codex, Copilot, Antigravity variants) lives on the skill page. The README below is the SKILL.md from kingkongshot — the same source the install pulls from. You also need the Codex CLI binary itself: npm install -g @openai/codex or brew install --cask codex, then codex login.
One-line install · by kingkongshot
Open skill pageInstall
mkdir -p .claude/skills/codex-cli && curl -L -o skill.zip "https://mcp.directory/api/skills/download/373" && unzip -o skill.zip -d .claude/skills/codex-cli && rm skill.zipInstalls to .claude/skills/codex-cli
Watch it built
A practical side-by-side from a dev who shipped real work with both CLIs — useful before the cookbook because it anchors which strengths the routing decisions exploit.
Wrap a Claude prompt as a one-shot codex exec command
Take a prompt you would have typed into Claude Code and run it non-interactively under Codex CLI so the output is a file you can diff in CI.
ForSolo devs and small teams who want a reproducible scratch lane for refactor prompts.
The prompt
Write me a shell wrapper scripts/codex-task.sh that takes a prompt file and runs `codex exec` with --json, --output-last-message, --sandbox workspace-write. Save the assistant's last message to .codex-out/<timestamp>.md. The wrapper should also log the JSONL events to .codex-out/<timestamp>.jsonl so I can grep tool calls later. Pin gpt-5.3-codex via -m. Skip git-repo-check off (we want it on). Bonus: a Makefile target `make codex` that reads .codex/prompt.md.What slides.md looks like
#!/usr/bin/env bash
# scripts/codex-task.sh
set -euo pipefail
PROMPT_FILE="${1:-.codex/prompt.md}"
TS="$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p .codex-out
codex exec \
-m gpt-5.3-codex \
--sandbox workspace-write \
--json \
--output-last-message ".codex-out/${TS}.md" \
"$(cat "$PROMPT_FILE")" \
| tee ".codex-out/${TS}.jsonl"One-line tweak
Swap `--sandbox workspace-write` for `--sandbox read-only` when the prompt should plan but never patch. The codex-cli skill teaches Claude this exact substitution.
Run Codex CLI as a subprocess from Claude Code for second-opinion review
Have Claude open a PR diff, then shell out to `codex exec` for an adversarial review, and merge both verdicts before replying.
ForTeams who treat one model as an under-the-line reviewer and want both votes on risky diffs.
The prompt
I'm in Claude Code. Add a slash command /second-opinion that: (1) runs `git diff origin/main...HEAD > /tmp/diff.patch`, (2) shells out to `codex exec --sandbox read-only -m gpt-5.3-codex 'Review this diff for SQL injection, missing auth checks, and race conditions: \\n\\n' \"$(cat /tmp/diff.patch)\" -o /tmp/codex.md`, (3) reads /tmp/codex.md back into context, (4) prints the union of Claude's review and Codex's review with disagreements flagged.What slides.md looks like
# .claude/commands/second-opinion.md
---
description: Adversarial review by OpenAI Codex CLI on the current branch diff
allowed-tools: Bash(git diff:*), Bash(codex exec:*), Read
---
Run `git diff origin/main...HEAD > /tmp/diff.patch` then:
!`codex exec --sandbox read-only -m gpt-5.3-codex \
"Review this diff for SQL injection, missing auth, race conditions:" \
"$(cat /tmp/diff.patch)" \
-o /tmp/codex-review.md`
Read /tmp/codex-review.md and reconcile with your own review. Flag every disagreement.One-line tweak
If Codex's review keeps disagreeing on the same axis (e.g. error handling), promote that axis into a checklist item in CLAUDE.md so both agents start from the same prior next time.
Reuse a Claude Code skill from inside Codex CLI
Take a SKILL.md you already use in Claude Code and surface it inside Codex CLI's AGENTS.md so both agents follow the same conventions.
ForTeams that have invested in skill authoring and don't want to fork rules per CLI.
The prompt
I have ~/.claude/skills/<slug>/SKILL.md files that I want Codex to honor too. Generate scripts/sync-skills-to-codex.sh that (1) finds every SKILL.md under ~/.claude/skills, (2) writes a single ~/.codex/AGENTS.md whose body lists each skill's name + description + trigger phrases, plus a one-line `When the user asks for X, follow ~/.claude/skills/<slug>/SKILL.md`. Keep it idempotent (overwrite, don't append). Print a count.What slides.md looks like
#!/usr/bin/env bash
# scripts/sync-skills-to-codex.sh
set -euo pipefail
SRC="${HOME}/.claude/skills"
DST="${HOME}/.codex/AGENTS.md"
mkdir -p "$(dirname "$DST")"
{
echo "# Skills (auto-synced from ~/.claude/skills)"
echo
for f in "$SRC"/*/SKILL.md; do
slug="$(basename "$(dirname "$f")")"
desc="$(awk '/^description:/{$1=""; print substr($0,2); exit}' "$f")"
echo "## ${slug}"
echo "- description: ${desc}"
echo "- on match, follow: ${f}"
echo
done
} > "$DST"
echo "Wrote ${DST} with $(grep -c '^## ' "$DST") skills."One-line tweak
If a skill is Claude-only (uses Anthropic-specific tool names like AskUser), skip it in the loop. Codex's AGENTS.md is markdown the model interprets — same as SKILL.md, so most skills port 1:1.
Side-by-side benchmark: same prompt, both CLIs, diffed outputs
Run an identical prompt through Claude Code and `codex exec`, save both transcripts, and let a reviewer see the disagreement.
ForAnyone evaluating which CLI to standardize on for a specific repo or task class.
The prompt
Generate scripts/bench-cli.sh that takes a prompt file and runs it under both Claude (`claude -p` headless mode with --output-format=json) and Codex (`codex exec --json -o`). Save both last-messages to bench/<timestamp>/{claude.md,codex.md} and write a bench/<timestamp>/diff.md that runs `diff -u` on the two files. Print the wall-clock for each run.What slides.md looks like
#!/usr/bin/env bash
# scripts/bench-cli.sh
set -euo pipefail
PROMPT="${1:?prompt file required}"
RUN="bench/$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p "$RUN"
time claude -p --output-format=json "$(cat "$PROMPT")" \
| jq -r '.result' > "$RUN/claude.md"
time codex exec --json -o "$RUN/codex.md" \
--sandbox read-only "$(cat "$PROMPT")"
diff -u "$RUN/claude.md" "$RUN/codex.md" > "$RUN/diff.md" || true
echo "$(wc -l < "$RUN/diff.md") differing lines — see $RUN/"One-line tweak
Run the same prompt 5x on each side; cheap LLM variance means a single comparison will mislead. Pipe both transcripts into a third pass that asks Claude to summarize the systematic differences.
Hand off a long-running task: Claude plans, Codex implements
Use Claude Code to write the spec + test list, then have Codex CLI execute the implementation under workspace-write sandbox.
ForTeams that find Claude better at decomposition and Codex faster at write-heavy edits.
The prompt
In Claude Code: produce a SPEC.md for the change I'm asking for, plus a TASKS.md with 6-10 atomic tasks (each one file, ~50 LOC). Then write a Makefile target `make codex-implement` that loops over TASKS.md and runs `codex exec --full-auto --sandbox workspace-write -o .codex-out/task-N.md` once per task, passing the SPEC.md + the single task body as the prompt. After the loop, run `pytest` and feed any failures back to Claude.What slides.md looks like
# Makefile
codex-implement:
@mkdir -p .codex-out
@n=0; while IFS= read -r task; do \
n=$$((n+1)); \
echo "→ task $$n: $$task"; \
codex exec --full-auto --sandbox workspace-write \
-m gpt-5.3-codex \
-o .codex-out/task-$$n.md \
"Spec: $$(cat SPEC.md)\n\nTask: $$task" ; \
done < TASKS.md
@pytest -x || (echo "Failures — feed .codex-out/*.md back to Claude" && exit 1)One-line tweak
If a task touches more than one file, split it. The whole win of the plan/implement split is that each Codex run sees ONE atomic task and the spec — not a moving target.
Route by cost: Codex CLI for simple bugs, Claude for hard ones
Use Codex CLI's ChatGPT Plus quota ($20/mo, generous limits) for cheap fixes; reserve Claude credits for multi-file design work.
ForSolo devs and bootstrapped teams who feel both bills.
The prompt
Write scripts/route-by-size.sh that: (1) computes the patch size from `git diff --stat`, (2) if files-touched <= 2 AND lines-changed < 80, run `codex exec --full-auto`, (3) otherwise hand off to `claude -p`. Print which CLI ran and why. Read the prompt from .ai/prompt.md so I can iterate without retyping.What slides.md looks like
#!/usr/bin/env bash
# scripts/route-by-size.sh
set -euo pipefail
PROMPT="$(cat .ai/prompt.md)"
files="$(git diff --stat | tail -n1 | awk '{print $1}')"
lines="$(git diff --shortstat | awk '{print $4+$6}')"
if [[ "${files:-0}" -le 2 && "${lines:-0}" -lt 80 ]]; then
echo "→ codex (small: ${files}f / ${lines}l)"
codex exec --full-auto --sandbox workspace-write \
-m gpt-5.3-codex -o .codex-out/last.md "$PROMPT"
else
echo "→ claude (large: ${files}f / ${lines}l)"
claude -p --output-format=json "$PROMPT" \
| jq -r '.result' > .claude-out/last.md
fiOne-line tweak
Tighten the routing once you have data. After 20-30 routed tasks, log success/failure into bench/route.csv and recompute the cutoff (the right threshold is repo-specific).
Run both agents in parallel via git worktree
Spawn one Claude Code session and one Codex CLI session against separate worktrees of the same repo, so the two agents can't step on each other's edits.
ForAnyone trying to keep two coding agents busy on a Saturday afternoon.
The prompt
I want to run Claude on feature/auth-refactor and Codex on feature/migrations from the same repo, in two terminals, no merge conflicts. Generate scripts/dual-worktree.sh that creates ../wt-claude (Claude branch) and ../wt-codex (Codex branch), prints the cd commands, and writes a tiny .codex/config.toml in the Codex worktree pinning gpt-5.3-codex with sandbox=workspace-write.What slides.md looks like
#!/usr/bin/env bash
# scripts/dual-worktree.sh
set -euo pipefail
git worktree add ../wt-claude -b feature/auth-refactor
git worktree add ../wt-codex -b feature/migrations
mkdir -p ../wt-codex/.codex
cat > ../wt-codex/.codex/config.toml <<'TOML'
model = "gpt-5.3-codex"
sandbox_mode = "workspace-write"
approval_policy = "on-request"
TOML
cat <<EOF
Open two terminals:
cd ../wt-claude && claude
cd ../wt-codex && codex
Merge later with: git switch main && git merge feature/auth-refactor feature/migrations
EOFOne-line tweak
Add a third worktree and a third CLI (Cursor agent or Gemini CLI) when you want to A/B/C-test the same prompt in isolation. The codex-claude-cursor-loop skill ships exactly that.
Codex CLI for refactor; Claude Code for tests
Let Codex's gpt-5.3-codex grind through the mechanical edit; Claude writes the test that proves the refactor preserved behaviour.
ForRepos with sparse test coverage where the refactor would be unsafe without new tests written first.
The prompt
I want to rename `User.email_address` to `User.primary_email` across 40+ files. Sequence: (1) ask Claude to write a pytest that captures the externally visible behaviour I care about (one test per public method that returns email); commit. (2) Ask Codex CLI: `codex exec --full-auto --sandbox workspace-write 'Rename User.email_address to User.primary_email everywhere it's referenced. Update SQL columns, fixtures, factories. Don't touch tests.'`. (3) Run pytest. If green, commit. If red, hand the failure back to Claude.What slides.md looks like
# scripts/refactor-with-tests.sh
set -euo pipefail
echo "→ Claude: write characterization tests"
claude -p "Write pytest tests/test_user_email_behaviour.py that locks in current externally-visible behaviour of User.email_address. One test per public getter."
git add tests/ && git commit -m "test: characterize User.email behaviour"
echo "→ Codex: do the rename"
codex exec --full-auto --sandbox workspace-write \
-m gpt-5.3-codex \
"Rename User.email_address to User.primary_email everywhere it's referenced. Update SQL columns, fixtures, factories. Don't touch tests."
echo "→ Pytest gate"
pytest tests/test_user_email_behaviour.pyOne-line tweak
If Codex's rename touches a file Claude wrote a test for, run the test from that file FIRST as a sanity check before letting Codex go further. Bisect with `--include` if it doesn't.
Pipe Codex CLI output through Claude for critique
Let Codex emit a draft, but let Claude polish, lint, and challenge it before it lands as a PR.
ForTeams that find Codex's drafts fast but rough, and Claude's prose-and-review work the better second pass.
The prompt
Build scripts/codex-then-claude.sh that: (1) runs `codex exec --json --output-last-message /tmp/codex.md '<task>'`, (2) pipes the output into `claude -p 'Critique this draft. Find logic errors, untested edge cases, and style violations. Rewrite if you can do better.'`, (3) saves Claude's reply to /tmp/final.md and prints a one-line stat (lines changed by the critique pass).What slides.md looks like
#!/usr/bin/env bash
# scripts/codex-then-claude.sh
set -euo pipefail
TASK="${1:?task required}"
codex exec --json -o /tmp/codex.md \
--sandbox read-only -m gpt-5.3-codex "$TASK"
claude -p --output-format=json \
"Critique this draft. Find logic errors, untested edge cases, style. Rewrite if better:\n\n$(cat /tmp/codex.md)" \
| jq -r '.result' > /tmp/final.md
delta="$(diff /tmp/codex.md /tmp/final.md | grep -c '^[<>]' || true)"
echo "critique pass changed ~${delta} lines"One-line tweak
Reverse the chain (Claude drafts, Codex critiques) when the task is creative-writing-shaped. The directionality matters more than which CLI is 'better' in the abstract.
Resume a Codex session from inside a Claude Code agent loop
Make the Claude orchestrator stateful by handing it `codex resume --last` so a multi-step Codex run can continue across turns.
ForLong-horizon work (migrations, integrations) where Codex's session memory is doing real work.
The prompt
Add a slash command /codex-continue that runs `codex resume --last "$ARGUMENTS"` — i.e. lets me append a follow-up to the most recent Codex session without leaving Claude Code. Save the new last-message to .codex-out/resumed.md. Print the session id Codex resumed.What slides.md looks like
# .claude/commands/codex-continue.md
---
description: Resume the most recent Codex CLI session and append $ARGUMENTS as the next turn
allowed-tools: Bash(codex resume:*), Read
---
Run:
!`codex resume --last "$ARGUMENTS" --json -o .codex-out/resumed.md 2>&1 | tee .codex-out/resumed.jsonl`
Then read .codex-out/resumed.md and summarize what Codex did. Print the resumed SESSION_ID from the JSONL header.One-line tweak
Pair with `codex fork SESSION_ID` when you want to branch the session into an experiment without losing the main thread. The transcript stays intact on the original.
Community signal
Three voices from Hacker News on running both CLIs in anger. The first is the long-context endorsement of Codex’s session memory; the second is the cost lever the cookbook turns into use case 6; the third is the migration story Cursor users tell when they pick this dual-CLI lane instead.
“On long conversations opus in Claude code will for me lose memory of what we were working on earlier, whereas one of my codex chats is already at >1B tokens and is still very coherent and remembers things I asked of it at the beginning of the convo.”
radicality · Hacker News
Long-context performance comparison from an HN commenter running both CLIs against the same long-running session. Anchors use case 10 (codex resume).
“The usage limits for Codex CLI vs Claude Code aren't even in the same universe. You get vastly more usage at highest reasoning level for GPT 5.3 on the $20/mo Codex plan, I can't even recall the last time I've hit a rate limit.”
toraway · Hacker News
The cost-routing argument (use case 6) in one paragraph. ChatGPT Plus quota is the unbeatable lever for small fixes.
“I was a heavy Cursor user, and I've completely switched to Codex CLI or Claude Code. I don't have to deal with an older, potentially buggier version of VS Code, and I also have the option of not using VS Code at all.”
nsingh2 · Hacker News
Migration framing — both CLIs win against IDE-bundled agents on the same axis. Pairs with the dual-worktree pattern in use case 7.
The contrarian take
Not every dev should run two CLIs. The most honest pushback on the dual-CLI lane comes from codazoda:
“I can't get Codex CLI or Claude Code to use small local models and to use tools. This is because those tools use XML and the small local models have JSON tool use baked into them. No amount of prompting can fix it.”
codazoda · Hacker News
From the HN thread on running coding agents with smaller local models.
He's right — both CLIs are tightly coupled to their first-party models, and a swap-in OSS model is not a free lunch. The bridge patterns in this cookbook ASSUME both gpt-5.3-codex and the Anthropic API are reachable. If you must run local-only, drop to a single-CLI setup with an OSS-friendly harness; the dual-CLI loop only earns its keep when both providers are doing real work. The bridges in this cookbook ASSUME both codex and claude resolve to first-party, hosted models. If you’re running local-only on a 64GB MacBook, drop to a single OSS-friendly harness (Aider, Open Codex, Qwen CLI) and ignore this skill until you’re back on hosted models. Don’t fight the tooling.
The other honest critique: even when both providers are reachable, two CLIs is two failure surfaces. Each codex exec call is a fresh process with its own sandbox, its own auth, and its own potential for prompt injection through README content or fixture files. Pin the binary version, audit ~/.codex/config.toml, and treat the wrapper scripts in this cookbook as you would treat any subprocess that runs untrusted text — never feed them prompts assembled from web search results without a review step.
Real bridges shipped
Concrete examples of teams or open-source projects running Claude Code + Codex CLI as a coordinated pair. None of these are pure-marketing — each cites the dual-CLI surface and its visible artifacts.
- GuardClaw — public-beta security middleware that explicitly supports both Codex CLI and Claude Code as upstream agents
- Agent Workstation (Show HN) — task scheduler + git-worktree + skills manager for running Codex CLI and Claude Code in parallel
- Codex Kaioken — community fork of OpenAI's Codex CLI adding subagents, memory, and live settings
- Open Codex — Show HN of an open-source rewrite of Codex CLI that runs against any local OSS model
- kingkongshot/Pensieve — the codex-cli skill author's broader project: a SKILL.md-driven memory layer that both Claude Code and Codex CLI can read
- OpenAI Codex CLI Cheatsheet (codeaidirectory.com) — a community reference for the exact `codex exec` flag surface this cookbook leans on
Gotchas (the four that bite)
Sourced from the openai/codex issue tracker and HN threads where devs reported running both CLIs in production.
`--full-auto` + `--dangerously-bypass-approvals-and-sandbox` is rope
The Codex CLI reference explicitly warns against combining these flags outside isolated environments. Use --full-auto on its own (workspace-write + on-request approvals) for normal work; reach for danger-full-access only inside an ephemeral container.
ANSI escape injection has been reported in Codex CLI output
An HN thread (item 46987031) documented an ANSI escape code injection vector in earlier Codex CLI versions. Pin to a recent release, never `cat` raw JSONL transcripts into a TTY without sanitization.
`codex resume --last` resumes the wrong session in a worktree setup
If you run Codex in two worktrees, --last picks the most recent session globally, not per-directory. Pass an explicit SESSION_ID, or pair with `--all` and a session picker, when working across multiple worktrees (use case 7).
AGENTS.md drift between repos breaks skill reuse
Use case 3 syncs SKILL.md content into ~/.codex/AGENTS.md globally. If you edit AGENTS.md by hand for one repo, the next sync overwrites it. Either commit a per-repo `.codex/AGENTS.md` (Codex reads project-local first) or move project-specific rules to .codex/config.toml profiles.
Pairs well with
Curated to match the cookbook’s actual integrations: the Codex-bridge family (codex-claude-loop, codex-cli-bridge, codex-skill, codex-subagent), the planning skills (subagent-driven-development, pair-programming), and the worktree skills the parallel use case leans on. The natural cross-link is Claude Code best practices — the headless claude -p patterns there pair directly with the codex exec patterns here.
Related skills
Related MCP servers
Two posts that compose well with this cookbook: What are Claude Code skills? covers the underlying mechanism, and Claude Code best practices covers the orchestration patterns the longer use cases (5, 7, 9) lean on.
Frequently asked questions
What is the codex-cli skill, and how is it different from running OpenAI Codex CLI directly?
The codex-cli skill is an orchestrator SKILL.md that teaches Claude how to drive `codex exec` as a subprocess — when to delegate, what sandbox mode to pick, how to fan out parallel runs, when to use `codex resume`. Running Codex CLI directly is fine; the skill matters when Claude is the planner and Codex is one of several agents Claude can hand work to. It is not a replacement for either CLI; it is a bridge.
Can I use my MCP servers from Codex CLI? (codex mcp skill query)
Yes. Codex CLI ships `codex mcp` for registering Model Context Protocol servers (stdio or HTTP). Add a server once in `~/.codex/config.toml` and Codex calls its tools the same way Claude Code does. So if you've already wired GitHub, Linear, or Playwright as MCPs for Claude, the same servers work inside Codex. The codex-cli skill leans on this — many of the cookbook entries assume MCP parity between the two CLIs.
Codex skill pptx / codex confluence skill / codex playwright skill — do Claude Code skills work in Codex?
Mostly yes. A SKILL.md is markdown a model interprets — Codex reads `~/.codex/AGENTS.md` the same way Claude reads `CLAUDE.md`. Use case 3 in this cookbook syncs every SKILL.md you have into AGENTS.md so Codex picks them up. The exception: skills that call Anthropic-specific tool names (e.g. `AskUser`) won't port; rewrite those to a CLI-agnostic shell command first.
What's the difference between `codex exec` and `codex` (interactive)?
`codex` opens an interactive terminal UI. `codex exec` (alias `codex e`) runs Codex non-interactively — it streams results to stdout or JSONL and exits. The cookbook leans on `codex exec --json --output-last-message <path>` because it's scriptable, diffable, and pipeable. Reach for interactive `codex` for exploration; reach for `codex exec` whenever you want Claude (or a Makefile) to drive the call.
Which sandbox should I pick — read-only, workspace-write, or danger-full-access?
Default to `read-only` for review and planning, `workspace-write` for implementations on the current repo (this is what `--full-auto` selects with on-request approvals), and `danger-full-access` only inside ephemeral containers. The codex-cli skill's job is partly to pick this for you per task — security review = read-only, refactor = workspace-write, never touch full-access from a developer machine.
Is the ChatGPT Plus quota actually enough to run Codex CLI seriously?
For most solo work, yes — multiple HN commenters report rarely hitting the rate limit on the $20/mo plan at gpt-5.3-codex's highest reasoning level. The cookbook's use case 6 is the explicit play: route small bugs to Codex (free under your existing ChatGPT subscription), keep Claude's metered tokens for the multi-file design work where it shines. Switch to API key billing only when Plus quota becomes the bottleneck.
Does the codex-cli skill replace the existing Codex CLI, or do I still need to install it?
You still need to install Codex CLI yourself: `npm install -g @openai/codex` or `brew install --cask codex`, then `codex login`. The skill is a thin orchestration layer on TOP of that binary — it teaches Claude the right flags to pass and when to fan out parallel runs. Without the binary on $PATH, the skill produces shell snippets that fail to execute.
Sources
Primary
- kingkongshot/Pensieve (the codex-cli skill author’s repo)
- openai/codex — OpenAI Codex CLI (Rust)
- OpenAI Codex CLI documentation
- OpenAI Codex CLI command-line reference (codex exec, resume, fork, mcp)
- OpenAI help center — Codex CLI overview
- OpenAI Codex CLI cheatsheet (community reference)
Community
- radicality — Hacker News
- toraway — Hacker News
- nsingh2 — Hacker News
- gamegoblin — Hacker News
- edg5000 — Hacker News
- lostmsu — Hacker News
Critical and contrarian
- codazoda on Codex CLI / Claude Code coupling to first-party models
- HN: ANSI Escape Code Injection in OpenAI’s Codex CLI
- Why I think my OpenAI Codex CLI had an “end stop” meltdown
Internal