# Codex Features and Practical Usage ⚙️ Review the moment a PR opens, ship a scheduled report every morning — run Codex as a single workflow step and the automation lives entirely in CI. 🏷️ Title: Actions Execution (Codex GitHub Action) 🔗 URL: 📘 Overview The Codex GitHub Action (`openai/codex-action@v1`) is the official action for running Codex from GitHub Actions workflows. It installs the Codex CLI, configures API access, and runs `codex exec` for you, keeping code review, quality gates, and scheduled reports entirely inside CI. ⚙️ How It Works Store your OpenAI key as a GitHub secret (e.g. `OPENAI_API_KEY`) and check out the code before invoking the action. Key inputs: ・`prompt` / `prompt-file`: inline instructions or a prompt file in the repo (pick one). ・`model` / `effort`: choose the model and the work intensity. ・`sandbox`: `read-only` / `workspace-write` / `danger-full-access` control filesystem and network access. ・`codex-args`: extra CLI flags as a JSON array or shell string. ・`output-file`: save the final message to upload as an artifact. The `safety-strategy` input defaults to `drop-sudo` (irreversibly removes sudo); other options are `unprivileged-user` and `unsafe`, which Windows runners require. Results are exposed via the `final-message` output. 🛠️ Practical Usage A minimal review workflow triggers on `pull_request` (types `opened`, `synchronize`), checks out the code with `actions/checkout@v5`, then runs `openai/codex-action@v1` with `openai-api-key` from secrets, a `prompt-file`, and an `output-file`. To post the result as a PR comment, pass the `final-message` output to `actions/github-script` in a downstream job (which needs `pull-requests: write`). 💡 Use Cases Use `pull_request` triggers for review and quality gates, `schedule` (cron) for periodic reports, `workflow_dispatch` for manual runs, and `issue_comment` for comment-driven automation. ⚠️ Caveats You cannot supply both `prompt` and `prompt-file`. If you ingest PR titles or comments, guard against prompt injection and restrict to trusted events or explicit approvals. Keep `safety-strategy` on `drop-sudo` or an unprivileged user, and place the action at the end of the job to avoid inheriting state. After `drop-sudo` you may need to grant write access (e.g. `chmod -R g+rwX`). #Codex# #GitHubActions#