Codex

ACT supports all ACT skills and research agents in Codex by installing Codex-native generated skill copies and generated custom-agent TOML files. Supported hooks are also installed for logging and Dart formatting.

Workflow UI limitation

Codex does not have a built-in AskUserQuestion tool. Installed Codex workflow skills, such as act-interview and act-refine-spec, are generated with direct chat questions instead of structured question UI.

The generated Codex skill copies ask direct questions in chat and stop until you reply. The skills still work, but the clarification flow is simpler than in clients with a dedicated structured-question tool. For the best ACT UX, we recommend using OpenCode over Codex. OpenCode has full support for models from OpenAI and other providers, while preserving ACT’s richer interactive workflow behavior.

Install

cd ~/.agentic-coding-toolkit && ./scripts/install.sh --tool codex

What Gets Installed

Location	Includes
~/.codex/skills/	Generated Codex-compatible ACT skill copies, with auxiliary entries symlinked from canonical ACT skill directories
~/.codex/agents/	Generated TOML custom agents
~/.codex/hooks/	Copied ACT hook core scripts and Codex adapters
~/.codex/hooks.json	ACT-owned Codex hook entries merged with user hooks
~/.config/agentic-coding-toolkit/	Shared ACT settings and copied runtime helper

Canonical source skills remain shared with Claude Code, Cursor, and OpenCode. Codex gets generated copies so OpenCode does not discover Codex-transformed skill bodies.

Verify

Start or restart Codex after installing ACT, then use Codex skill discovery:

/skills

You can also mention an ACT skill directly where Codex supports skill mentions:

$act-help
$act-create-issues ai_specs/0001-feature/spec.md
$act-implement ai_specs/0001-feature/work-items/01-first-work-item.md

Skills

Codex skills are generated into:

~/.codex/skills/<skill-name>/SKILL.md

Generated Codex skills remove unsupported Claude/OpenCode tool wording where ACT’s transformer covers it. Re-run the Codex installer after updating ACT so these generated skill copies are refreshed.

Auxiliary skill entries other than SKILL.md are symlinked from the canonical ACT skill directory into the generated Codex skill directory.

If /skills shows stale ACT wording after reinstalling, restart Codex.

Hooks

ACT installs Codex hooks for:

• session logging through SessionStart
• prompt logging through UserPromptSubmit
• supported tool-use logging through PreToolUse and PostToolUse
• permission-request logging through PermissionRequest
• Dart formatting after supported Codex file edits

Codex hook support has limits:

• No ACT statusline support on Codex
• No SessionEnd, subagent lifecycle, compact, or full Claude hook-event parity
• No policy enforcement: ACT logs permission requests but does not approve or deny them
• Hook interception depends on which tools Codex reports to hooks

Session logging is controlled by the shared ACT setting enableLogging in ~/.config/agentic-coding-toolkit/act-settings.json.

Review hooks before use

Before Codex can run installed hooks, you need to manually review and approve them. Run /hooks in Codex and approve the ACT hooks you want to enable.

Permissions

For the strategy comparison, see Permissions & Safety.

ACT logs supported PermissionRequest hook events, but it does not approve or deny Codex permission requests.

Strategy 1: Permission rules

Codex permissions are configured with config.toml and command rules:

• Config basics — Codex
• Rules — Codex

Relevant files:

• User-level config: ~/.codex/config.toml
• Trusted project config: .codex/config.toml
• User-level rules: ~/.codex/rules/
• Trusted project rules: .codex/rules/

For a typical ACT setup, you can allow common commands in ~/.codex/rules/default.rules:

prefix_rule(pattern=["git"], decision="allow")
prefix_rule(pattern=["flutter"], decision="allow")
prefix_rule(pattern=["dart"], decision="allow")
prefix_rule(pattern=["node"], decision="allow")
prefix_rule(pattern=["gh"], decision="allow")

Project .codex/ config and rules only load for trusted projects. Rules files are loaded at startup, so restart Codex after editing them.

Strategy 2: DSP / yolo + non-sudo account

Codex supports yolo mode:

codex --yolo

Codex also supports the long-form bypass flag:

codex --dangerously-bypass-approvals-and-sandbox

Use either form only from a dedicated non-sudo account or another isolation boundary that does not contain personal files, broad SSH keys, production credentials, or unrelated project secrets.

Remote machines and containers

You can run Codex on a VPS or remote dev machine and use the same permission strategy there. Treat the remote host as the isolation boundary.

Codex is also a good fit for Docker/devcontainer workflows when you want stronger isolation or a reproducible environment. See Permissions & Safety for the full VPS and Docker tradeoffs.

Troubleshooting

• Restart Codex after editing .rules files.
• Check whether the project is trusted before relying on .codex/ config or rules.
• Review and approve ACT hooks with /hooks; permission logging does not grant approvals automatically.

Related

• Platform Support
• Installation
• Skill Map