Help us improve
Share bugs, ideas, or general feedback.
From claude-leverage
Sets up Codex CLI sandbox configuration with dev, prod, or custom profiles via `.codex/config.toml`. Interactive, idempotent, preserves unmanaged config.
npx claudepluginhub filip-podstavec/claude-leverage --plugin claude-leverageHow this skill is triggered — by the user, by Claude, or both
Slash command
/claude-leverage:codex-sandbox [target-dir] [--profile dev|staging|prod|custom] [--noninteractive][target-dir] [--profile dev|staging|prod|custom] [--noninteractive]This skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Codex CLI runs each agent inside a sandbox with a configurable
View and configure settings for coding agents like Claude Code (JSON), Codex CLI (TOML), OpenCode (JSONC): permissions, sandbox, models, profiles, hooks, subagents, skills. Restart agent after edits.
Guides deployment workflows with CI/CD patterns, rolling/blue-green/canary strategies, multi-stage Dockerfiles for Node.js, health checks, rollbacks, and production checklists for web apps.
Share bugs, ideas, or general feedback.
Codex CLI runs each agent inside a sandbox with a configurable
permission model (filesystem, network, dangerous commands). The
defaults are conservative; per-project overrides live in
.codex/config.toml at the project root.
This skill asks 3–5 questions, recommends a profile, and writes the file. Re-running on an already-configured project detects the managed block (marker comments) and offers update-in-place.
.codex/config.tomlThe skill writes only the policy-relevant sections (and leaves room for the user to add unrelated config below):
# <!-- claude-leverage:codex-sandbox START -->
# Managed by /codex-sandbox. Edit between markers and re-run the skill
# to update; do not delete the markers.
[project_doc]
max_bytes = 32768 # explicit; matches Codex default
[sandbox]
mode = "<workspace-write | read-only | full>"
[approval]
mode = "<on-request | on-failure | never>"
# <!-- claude-leverage:codex-sandbox END -->
| Profile | Sandbox | Approval | Use for |
|---|---|---|---|
dev | workspace-write | on-request | Local development. Agent can write inside the project but asks before risky actions (network, package install, shell commands outside cwd). |
prod | read-only | never | Production / CI runs. Agent can only read; any write requires running outside the sandbox. |
custom | (asks) | (asks) | Anything else; skill walks you through each field. |
Earlier drafts proposed a
stagingprofile with "audit logging" — that claim was incorrect (Codex config has no audit-log field). For CI / staging behavior, usedevif you want approvals orprodif you want the safer read-only sandbox, and pipe Codex's own stderr to your log aggregator if you need an audit trail.
Field names below are what Codex currently documents. If the spec
evolves, this skill will need a refresh — /stack-check does not yet
verify Codex spec freshness (v1.1 candidate).
Resolve target dir. Default cwd. If $ARGUMENTS has a path,
use that. Verify it's a git repo or ask "this isn't a git repo;
proceed anyway?".
Detect existing config. If .codex/config.toml exists:
.codex/config.toml
exists; prepend a managed block above it, replace, or skip?".Choose profile (unless --profile <name>):
Pick a profile:
1. dev — workspace-write, on-request approvals (recommended for local)
2. prod — read-only sandbox, no approvals (CI / production)
3. custom — answer each question individually
Unless --noninteractive, wait for a choice. With
--noninteractive and no --profile, default to dev.
For custom, walk the user through:
project_doc.max_bytes: keep default 32768 or set higher
(warns this exceeds Codex's silent-drop cap if user picks higher).Write the managed block.
.codex/config.toml exists: create file with managed
block as the only content.Edit (markers stay byte-identical).Report. Print the resolved config + a one-line summary.
Suggest the user runs codex --version or starts a fresh Codex
session to pick up the change.
read-only without explicit
acknowledgement. If the user picks full, surface a one-line
reminder: "full sandbox lets the agent do anything in the
filesystem; only use for trusted scripts."/init-repo — protect against random-dir foot-guns.--profile dev|prod|custom — skip the picker. Default is dev.--noninteractive — confirm nothing, use profile (default dev).--dry-run — print what would be written, write nothing.~/.codex/config.toml (global). Global Codex config
is a user-level decision; this skill only writes the per-project
.codex/config.toml. For global, edit by hand.~/.codex/hooks.json or ~/.codex/AGENTS.md. Those are
owned by scripts/install-codex.sh (and its uninstall path).npm i -g @openai/codex); this skill just configures it.If you invoke /codex-sandbox from a Claude Code session, the skill
will note up front:
This skill writes
.codex/config.toml, which only affects how Codex CLI behaves in this project. Claude Code does not read Codex config; your Claude Code experience is unchanged.
The skill still runs (it's a file-writer; the file just happens to be Codex-relevant). This is useful when setting up a fresh project in Claude Code that you also plan to work on from Codex.