codex-cli-exec

Explain how Openclaw should use Codex CLI as a non-interactive coding engine. Use when Codex needs to document or answer questions about installing Codex CLI...

Security Scan

The skill is an instruction-only helper for using the Codex CLI and its requirements and instructions are consistent with that stated purpose.

Purpose & Capability

The name/description are to teach Openclaw how to use Codex CLI non-interactively; the SKILL.md contains only CLI usage guidance, workspace and auth guidance, and flags relevant to that purpose. No unrelated credentials, binaries, or installs are requested.

Instruction Scope

Instructions include commands that change working directories, add writable directories (via --add-dir), skip git checks, and recommend sandbox/approval flags. These are appropriate for automating CLI runs but do grant the agent guidance to operate on filesystem paths—the doc also advises sandboxing and approvals. The SKILL.md does not instruct the agent to read unrelated system files or secrets.

Install Mechanism

This is an instruction-only skill with no install spec and no downloads. Low install risk.

Credentials

The document shows example usage with OPENAI_API_KEY and model override flags (e.g., -m gpt-5.4) but the skill metadata lists no required env vars. Mentioning OPENAI_API_KEY is reasonable for a CLI that supports API-key auth, but the metadata could declare it if the skill expected to require it in practice.

Persistence & Privilege

always is false and the skill is user-invocable; it does not request permanent platform presence or system-wide configuration changes.

Assessment

This skill is essentially documentation for running the Codex CLI non-interactively and appears internally consistent. Before installing/using: (1) ensure you only run codex exec inside workspaces you trust and avoid granting broad write access with --add-dir unless necessary; (2) prefer approval/sandbox flags (e.g., -a on-request, -s workspace-write) instead of --full-auto or Always allow unless you fully trust the environment; (3) only provide your OPENAI_API_KEY when you understand the CLI will use it; (4) install the CLI from the official npm package (@openai/codex) to avoid supply-chain risk; and (5) verify your Openclaw policies for autonomous invocation if you plan to allow automatic runs. The skill is coherent but exercise normal caution around filesystem scope and credentials.

Openclaw Codex CLI

Overview

Use this skill to give short, practical instructions for codex-cli in Openclaw contexts. Keep answers concise and command-focused. For Openclaw integrations, prefer codex exec because Openclaw should call Codex non-interactively rather than trying to type into the interactive TUI.

Core Commands

Use these as the default examples:

npm install -g @openai/codex
codex --version
codex login
codex login --device-auth
codex exec "<prompt>"

Mention codex "<prompt>" only when the user explicitly wants a human-driven interactive session.

Install and Update

When asked about installation or update:

• Install with npm install -g @openai/codex.
• Check the version with codex --version.
• Update with the same package manager used for installation.
• If codex is not found, tell the user to check PATH and restart the terminal.

Login

When asked about login:

• Use codex login for the standard login flow.
• Use codex login --device-auth when device authentication is preferred.
• If needed, API key auth can be used with OPENAI_API_KEY.
• The user must complete the sign-in flow.
• If login succeeds and codex works normally, the user does not need to log in again on every launch.
• Log in again only if the session expires, credentials are cleared, or the CLI asks for authentication.

Examples:

codex login

codex login --device-auth

printenv OPENAI_API_KEY | codex login --with-api-key

codex login status

Authentication Errors

If codex exec returns 401 unauthorized or 500 internal server error, tell the user to reset authentication and log in again.

Use this recovery flow:

codex logout
codex login --device-auth

After login, run the codex exec command again.

Openclaw Integration Style

Use this distinction clearly:

• Preferred for Openclaw integration: codex exec "<prompt>"
• Interactive only when a human wants to work directly in the Codex UI: codex "<prompt>"

For Openclaw, prefer codex exec because the default Codex CLI interface is interactive and not ideal for another tool to control by typing into the chat window.

Use codex exec when Openclaw needs to send a task programmatically as a one-off run.

Workspace Folder

Recommend creating a dedicated workspace folder for each Openclaw task or project.

Use this guidance:

• Run Codex inside a dedicated workspace directory.
• Keep project files, generated files, and temporary outputs inside that workspace.
• Prefer workspace-write style execution in that workspace.
• If the workspace is not a git repository, add --skip-git-repo-check.
• Use --cd to point Codex at the intended working directory.
• Use --add-dir when Openclaw must allow writes in additional directories.

This makes file scope clearer and reduces the risk of changing unrelated files.

Examples:

codex exec --cd /path/to/workspace "<prompt>"

codex exec --cd /path/to/app --add-dir /path/to/shared "<prompt>"

Git Repository Check

If the target directory is not a git repository, mention --skip-git-repo-check.

Use this when Openclaw needs to run Codex in a folder that does not contain a .git directory.

Example:

codex exec --skip-git-repo-check "<prompt>"

Trust and Approvals

Explain these briefly:

• Trust this folder: use for a known safe Openclaw workspace.
• Allow once: use when the user wants one-time approval.
• Always allow: use only for safe, repeatable command patterns.

Preferred guidance:

• Trust only known folders.
• Prefer Allow once when unsure.
• Use Always allow carefully.

Approval and Sandbox Options

Mention these options when the user asks how Codex should run commands:

• -a, --ask-for-approval: controls when Codex asks for approval before running commands.
• -s, --sandbox: controls how restricted command execution is.
• --full-auto: convenience mode for lower-friction automatic execution.
• --skip-git-repo-check: skips the git repository check when the folder is not tracked by git.

Use this practical guidance:

• For Openclaw, prefer safer settings first.
• Use -a on-request when approvals should be requested as needed.
• Use -a never only when the environment is already controlled and non-interactive execution is intended.
• Use -s workspace-write as the normal default when Codex needs to edit files in the workspace.
• --full-auto is a shortcut for a lower-friction setup and is useful when the user wants more automation with workspace-limited writes.
• Add --skip-git-repo-check when the working folder is not a git repository.
• Avoid --dangerously-bypass-approvals-and-sandbox.
• Avoid --sandbox danger-full-access unless the user explicitly wants that risk.

Examples:

codex exec -a on-request -s workspace-write "<prompt>"

codex exec --full-auto "<prompt>"

codex exec --skip-git-repo-check "<prompt>"

Useful Exec Options

Mention these when relevant:

• --json: use when Openclaw needs machine-readable output.
• -i, --image: attach image inputs for UI or design tasks.
• -m, --model: override the model when the user specifies one.
• --search: enable web search when current information is needed.

Examples:

codex exec --json "<prompt>"

codex exec -i screenshot.png "Match this UI design."

codex exec -m gpt-5.4 "<prompt>"

Prompt Examples

Use short examples like these:

codex exec "Add a README section for local development."

codex exec "Implement a login retry feature with exponential backoff in the Openclaw client."

codex exec "Write a Python script that reads a CSV file and outputs a JSON summary by category."

codex exec "Modify the file upload endpoint to reject files larger than 10 MB and add a test for it."

codex exec --json "List all API endpoints in this workspace."

If the user explicitly wants an interactive chat, use:

codex "<prompt>"

Prompting Rule

Prefer prompts that include:

• The exact outcome
• The target file or component when known
• Important constraints
• Optional verification requests