菜单
Route Codex CLI work across local CLI inspection, non-interactive exec/review automation, plugin and MCP management, doctor/debug/sandbox/app-server diagnostics, session log forensics, and Codex app local environment actions.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | codex-cli |
| description | Route Codex CLI work across local CLI inspection, non-interactive exec/review automation, plugin and MCP management, doctor/debug/sandbox/app-server diagnostics, session log forensics, and Codex app local environment actions. |
Bundled commands use $PLUGIN_ROOT ($env:PLUGIN_ROOT in PowerShell; same path suffix) for the plugin root. Set it once: use the host's plugin-root variable when defined (Claude Code: PLUGIN_ROOT="$CLAUDE_PLUGIN_ROOT"), otherwise the absolute path of this plugin's root directory.
Use this skill when the user asks to operate, diagnose, automate, wrap, or
explain the Codex CLI, including codex, codex exec, codex review,
codex doctor, codex mcp, codex plugin, codex sandbox, codex debug,
codex app-server, codex remote-control, codex resume, codex fork,
codex archive, or local Codex app Run actions.
Prefer live local facts over memory. Inspect the installed CLI before building commands or debugging version-sensitive behavior:
python3 "$PLUGIN_ROOT/scripts/codex_cli_inspector.py" --json
If the user supplies a Codex executable path, use it for the current run:
python3 "$PLUGIN_ROOT/scripts/codex_cli_inspector.py" --codex "$CODEX_CLI_PATH" --json
Do not commit personal absolute paths into source files, manifests, docs, or
examples. Use CODEX_CLI, PATH, ~/.codex, $CODEX_HOME, or user-provided
runtime arguments instead.
codex exec resume, or code review commands: use codex-exec-automation.codex-plugin-mcp-manager.codex-doctor-debugger.codex-log-reader..codex/environments/environment.toml, Codex app Run/Test/Preview actions, startup commands, long-running dev servers, or repeatable local project actions: use codex-environments.If several apply, start with health/surface inspection, then choose the narrow
workflow skill. For a failing non-interactive run, inspect the command with
codex-exec-automation, then use codex-log-reader only if session evidence is
needed.
--dangerously-bypass-approvals-and-sandbox, --dangerously-bypass-hook-trust, and --yolo as high-risk. Use them only when the user explicitly selected an external sandbox or hardened automation boundary.--sandbox workspace-write --ask-for-approval on-request for ordinary local coding work.--sandbox read-only --ask-for-approval never for read-only non-interactive checks.logout, destructive plugin/MCP removal, archive/unarchive, app-server listeners, remote-control start/stop, feature enable/disable, or marketplace upgrade/remove without a clear target and user intent.Use this precedence for current CLI behavior:
codex path or CODEX_CLI.codex --help and subcommand help.codex doctor --json or compact doctor output.openai/codex repository for implementation-level clues.When local help and docs disagree, trust local help for the installed binary and say that the docs may describe a different version.
A Codex CLI task is done when the answer includes the exact command or source
change, the safety mode chosen, the cwd/config assumptions, and proof appropriate
to the request: inspector output, --help evidence, doctor output, log-reader
summary, environment TOML parse, script syntax check, plugin/MCP list output, or
a clearly reported blocker.
Use when locating, summarizing, auditing, or debugging Codex session rollout JSONL logs by CODEX_THREAD_ID, cwd, query, issue key, project path, child or inherited-history symptoms, malformed or huge log symptoms, permission concerns, or "what happened in this Codex thread" questions.
Use when auditing agent skills or plugins for safety, coverage, duplicated logic, token/context cost, prompt-contract risk, validation readiness, marketplace visibility, dependencies, network behavior, or install/update risk. For structural split/merge/move/delete/router decisions across skills or plugins, use capability-portfolio-architect instead.
Use when auditing agent skill/plugin portfolio architecture for cross-plugin capability overlap, weak routing, duplicated or missing skills, split/merge/delete/move decisions, shared capability extraction, reference/script extraction, or plugin boundary redesign. For safety, coverage, or validation review of a single artifact without boundary changes, use capability-auditor instead.
Use when performing broad external-first discovery, vetting, scoring, distillation, or synthesis of agent skills or plugin packs from the public web, GitHub/public repositories, OpenClaw/ClawHub, marketplaces, research sources, community implementations, user references, or local skills. Use for well-vetted capability synthesis, cross-skill comparison, plugin-pack synthesis, global capability acquisition, skill strengthening, and adoption/rejection changelogs.
Route and orchestrate agent skill and plugin lifecycle work. Use when work involves agent skills, plugins, marketplace packages, capability acquisition, synthesis, creation, installation, packaging, audit, or context-density optimization.
Use when creating, updating, validating, optionally installing/cache-refreshing, or handing off marketplace-backed agent plugins. Use for plugin manifests, local marketplace entries, plugin-pack synthesis, triggerable skill bundles, install visibility gates, and Codex app deeplinks.