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 "" 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 ""
• Interactive only when a human wants to work directly in the Codex UI: codex ""

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