Codex MCP Dev

Use the local Codex installation through the wrapper script at {baseDir}/scripts/codex_mcp.py.
This gives a stable path:

OpenClaw → mcporter → codex-mcp-server → local INLINECODE1

Quick Setup

Install prerequisites first:

• - INLINECODE2
• local INLINECODE3
• INLINECODE4

Create the project MCP entry if config/mcporter.json does not exist yet:

CODEBLOCK0

This skill expects a workspace-local MCP server named codex-cli.

Workflow

1. 1. Use this skill for non-trivial coding tasks.
2. If it is the first use in a session or something looks broken, run:

1. 3. Choose a mode:

1. 4. Always set --cwd to the target repo or project directory.
2. Give Codex a concrete prompt with files, constraints, and acceptance criteria.
3. After Codex responds, inspect files and run local tests yourself when feasible instead of trusting the tool output blindly.
4. Summarize changes, tests run, and any remaining risks.

Good Uses

• - Implementing features across multiple files
• Fixing bugs with real repo context
• Refactoring with constraints
• Writing or updating tests
• Debugging failing commands or stack traces
• Asking local Codex for a second implementation pass or review

Command Patterns

Health check

CODEBLOCK1

Version info

CODEBLOCK2

Normal implementation

CODEBLOCK3

Read-only analysis

CODEBLOCK4

Long prompt from file

CODEBLOCK5

Prompting Rules

Include as many of these as possible:

• - Target files or directories
• Desired behavior
• Exact error messages or failing tests
• Constraints on scope
• Required test updates
• Expected output format

Prefer prompts like:

• - "Fix the failing test in tests/api.test.ts without changing public behavior. Run the relevant tests and summarize the root cause."
• "Refactor src/cache.py for readability, keep behavior identical, and add regression tests for TTL edge cases."
• "Review the auth flow in server/ and identify the top 3 correctness risks with concrete file references."

Guardrails

• - Prefer --full-auto for ordinary implementation work.
• Do not use --yolo unless the user explicitly wants aggressive execution.
• Use repo-specific --cwd; do not run against the wrong directory.
• Validate with local reads/tests when possible.
• If the task is tiny or surgical, skip this skill and edit directly.