Automation and CI/CD: Let Codex Work While You Are Away

📚 Series Navigation: The previous article [26 Git and GitHub Integration] taught you how to let Codex manage branches, write commits, and open PRs locally—actions you execute while sitting at your computer with Codex next to you. This article transitions to "unattended" workflows: once configured, Codex automatically reviews opened PRs, posts bugfix patches when CI fails, and generates daily commit summaries, all without you having to watch it. The next article [28 Non-Interactive Mode with codex exec] focuses on the core command that drives this system.

People often say: "The biggest value of AI programming tools is pair programming, chatting while coding"—but to be honest, that's only half true.

Having used Codex for over half a year, I realize: the place where it truly unlocks productivity is when you are not active. In pair programming, you must be present, monitor steps, and review outputs—meaning "you lead, and it helps," stopping when you step away. But software development contains tedious, structured tasks—scanning every PR, reviewing failed CI runs at midnight, and compiling weekly summaries of what changed. These tasks share traits: repetitive, structured, and tedious to maintain manually.

These tasks are ideal for automation. By integrating Codex into CI pipelines or scheduling it as background tasks, it shifts from "an assistant you must watch" to "the sentinel checking your repository while you sleep." This article covers two paths: integrating Codex into GitHub Actions (on the CI/CD side), and scheduling recurring background tasks using Automations in the Desktop App (on the local side). Setting both up establishes a 24-hour automation layer for your repositories.

By reading this article, you will get:

• The difference between the two automation paths—openai/codex-action in CI/CD vs. Automations running scheduled local background tasks
• A minimal, working GitHub Action workflow YAML, detailing what each line does to review your PRs
• Key codex-action inputs (prompt-file, sandbox, safety-strategy, final-message, etc.), aligned with official documentation
• How to configure OpenAI keys securely in GitHub, and the safety rules to keep in mind
• Setting up Automations in the Desktop App, checking scheduled run results, and running them locally vs. in Worktrees
• A hands-on guide to automate and schedule a "Daily Summary" task

⚠️ Specific commands, action inputs, configuration options, and default values mentioned below are subject to the official Codex documentation (GitHub Action / Automations); versions and model names are subject to your active installation.

---

01 Two Automation Paths: Do Not Mix Them Up

Let's trace the map first—Codex automation divides into two paths running in different locations and targeting different tasks:

• Path 1: GitHub Action (openai/codex-action). Runs on GitHub-hosted runners (cloud machines), triggered by repository events (opening PRs, pushing code, CI steps failing), representing the CI/CD (Continuous Integration / Continuous Delivery) side. It manages team-wide collaboration tasks: reviewing PRs, checking quality gates, and posting automated fixes.
• Path 2: Automations (Scheduled Tasks). Runs on your local machine where the Codex Desktop App is open, triggered by time (scheduling, cron intervals), representing the "personal background" side. It manages tasks aligned with your schedule: compiling daily summaries, checking projects, or monitoring long-running tasks.

Why distinguish them? Because beginners often apply the wrong path to their needs—trying to set up team-wide PR reviews by configuring Automations in the Desktop App (which stop running when your computer shuts down); or attempting to notify yourself about local branch changes by writing a GitHub workflow (which runs in the cloud and cannot access your local drive). Choosing the wrong path prevents tasks from executing.

Analogy: A security guard vs. a housekeeper. A GitHub Action is a security guard hired for a public office building (the repository)—he doesn't live in your home, he stays in the guardhouse (the GitHub runner). When activity occurs in the building (a PR is opened or CI alerts fire), he works according to the schedule, managing company-wide checks. Automations are a housekeeper hired for your home (your local project)—working on your local machine. You set a schedule like "compile yesterday's package list every morning at 9 AM," and if the house is closed (your computer is off), he rests. The guard manages public office collaboration, while the housekeeper manages your private schedules—different roles, locations, and tasks. Do not expect the guard to collect your packages at home.

Comparing the two systems:

	GitHub Action (codex-action)	Automations (Desktop App)
Location	GitHub-hosted runners (Cloud)	Your local machine with Codex App active
Trigger	Repository events (PRs, commits, CI steps)	Time (schedule / cron intervals)
Requires You Present?	No, runs autonomously in the cloud	Machine must be on, Codex App running
Typical Tasks	Reviewing PRs, checking quality, automated fixes	Daily summaries, checking code, monitoring tasks
Scope	CI/CD (Team collaboration workflow)	Personal background utilities

We will walk through GitHub Actions (Sections 02–05), Automations (Section 06), and the hands-on exercise (Section 07). Keep this map in mind as we proceed.

💡 Summary in one sentence: Automation splits into two paths—GitHub Actions run in the cloud, triggered by repository events, managing team collaboration (the guard); Automations run on your local machine, triggered by schedules, managing personal tasks (the housekeeper). Match tasks to the correct location.

---

02 What is a GitHub Action: Running codex-action in Your Pipeline

Let's explore the first path. The bottom line: openai/codex-action is an official GitHub Action that handles installing the Codex CLI, setting up the API proxy to talk to OpenAI, and executing codex exec under your defined permissions on the runner. It saves you from manual setups on the runner.

Let's look at codex exec. This is Codex's non-interactive mode (non-interactive mode)—bypassing the interactive terminal UI to accept a prompt, run it, return results, and exit. For now, keep in mind that the GitHub Action runs codex exec under the hood—wrapping the installation, authentication, and execution steps into a package (Article 28 covers the command in detail).

The official docs state:

Use the Codex GitHub Action (openai/codex-action@v1) to run Codex, apply patches, or publish review feedback from your GitHub Actions workflows. The action installs the Codex CLI, starts the Responses API proxy when an API key is provided, and executes codex exec under your defined permissions.

Analogy: A pre-equipped toolbox for business trips. When working on a client's site (the GitHub runner), you could bring loose tools and configure them there (manually running npm install for Codex, running codex login to authenticate, and configuring keys)—or you can bring a pre-configured toolbox (codex-action) that provides the CLI and active proxies ready to use, leaving you to specify the task (the prompt). The value of the toolbox is setting up a secure environment on a remote system safely, especially regarding key security (detailed in Section 05).

The official docs list three main use cases for this action:

• Posting Codex feedback automatically on PRs or releases without manual CLI management;
• Using Codex checks to block builds, acting as a quality gate in your CI pipeline;
• Running repeatable Codex workflows (code reviews, release prep, migrations) defined in a workflow file.

Note that this setup is not triggered by comments. It is a standard GitHub Action—triggered by events defined under on: in your workflow (PR creations, pushes, CI successes). If you are used to other AI tools that trigger by commenting on a PR, set that expectation aside: Codex's action integrates into your CI pipeline, running automatically on repository events.

💡 Summary in one sentence: openai/codex-action is a pre-configured tool package that installs the Codex CLI, starts proxies, and runs codex exec in the CI pipeline; it is event-triggered (not comment-triggered), making it ideal for automatic PR reviews, quality gates, and repeatable tasks.

The overall flow of this path:

Diagram: A repository event (push, PR, cron) triggers the workflow; the workflow runs codex exec in non-interactive mode on a cloud runner, outputting PR comments, code changes, or reports.

---

03 A Minimal Workflow: Analyzing a PR Review YAML

Let's look at a working workflow—reviewing a PR automatically when it is opened and posting the feedback to the PR. We will break down what each block does.

Analogy: A shift schedule for security guards. This YAML uses two jobs in sequence: job 1 (codex) is the reviewing guard, who checks the PR and writes notes on a card (final-message output); job 2 (post_feedback) is the messenger, who posts the notes to the PR comments only if the card has text. Why separate them? It is a safety design (detailed in Section 05)—the reviewer has read-only permissions, while the messenger has write permissions.

The workflow configuration (minimal version, ready to copy and use):

# File path: .github/workflows/codex-review.yml
name: Codex pull request review
on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  codex:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    outputs:
      final_message: ${{ steps.run_codex.outputs.final-message }}
    steps:
      - uses: actions/checkout@v5
        with:
          ref: refs/pull/${{ github.event.pull_request.number }}/merge
          persist-credentials: false

      - name: Run Codex
        id: run_codex
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          prompt-file: .github/codex/prompts/review.md
          output-file: codex-output.md

  post_feedback:
    runs-on: ubuntu-latest
    needs: codex
    if: needs.codex.outputs.final_message != ''
    permissions:
      issues: write
      pull-requests: write
    steps:
      - name: Post Codex feedback
        uses: actions/github-script@v7
        with:
          github-token: ${{ github.token }}
          script: |
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.payload.pull_request.number,
              body: process.env.CODEX_FINAL_MESSAGE,
            });
        env:
          CODEX_FINAL_MESSAGE: ${{ needs.codex.outputs.final_message }}

Breaking down the blocks:

The on Block (When to run): triggers on pull_request events of types opened (PR created), synchronize (new commits pushed), and reopened. The workflow launches whenever a PR is created or updated.

The checkout Step (Checking out the code): the official guidelines state—you must check out the repository code before running the action so Codex can read your files. We configure persist-credentials: false (to avoid leaving Git credentials on the runner) and checkout ref: .../merge (the code state after merging the PR into the target branch) to run the review. (The official example includes a Pre-fetch base and head refs step before running Codex to fetch base and head branches; we omitted it here for simplicity, but including it adds stability.)

The Run Codex Step (The core Codex step):

- uses: openai/codex-action@v1
  with:
    openai-api-key: ${{ secrets.OPENAI_API_KEY }}
    prompt-file: .github/codex/prompts/review.md
    output-file: codex-output.md

Three inputs: openai-api-key passes the API key (detailed in Section 05); prompt-file points to a prompt file stored in the repository (recommended path is .github/codex/prompts/) containing instructions on how to review; output-file saves the output message to disk to serve as an artifact or history log.

The outputs and post_feedback Steps (Posting results back to the PR): the codex job exports the final message via outputs (reading steps.run_codex.outputs.final-message); the post_feedback job waits for the codex job, checks if: needs.codex.outputs.final_message != '' (running only if there is text), and uses GitHub script to post it as a comment.

Note the output variable: final-message. The official docs state:

The action outputs the final message generated by Codex via the final-message output. Map this to a job output (as shown above) or process it in subsequent steps.

Simply put, final-message holds Codex's output notes—which you can post to PR comments, send to Slack, or use in security checks. The data flow: Codex reviews → output saved to final-message → subsequent job reads it → posts to PR.

Diagram: An event triggers checkout; codex-action runs the review based on the prompt file, outputting results to final-message, which are posted to the PR if not empty.

To pass instructions, choose between prompt-file (pointing to a Markdown/text file in the repository) and prompt (inline text block). Define only one; setting both causes the action to throw an error. For long or versioned instructions, prompt-file is preferred.

💡 Summary in one sentence: The minimal workflow follows a single path—PR event → checkout repository → codex-action reviews via prompt-file → results save to final-message → second job posts it to PR; only the Run Codex block handles Codex, while the rest is standard GitHub Actions.

---

04 Configuring Runs: Key Action Inputs

The minimal skeleton can be adjusted by configuring action inputs—which map codex exec command options directly to YAML keys. The docs state: "Configure action inputs to fine-tune how Codex runs, mapping them to codex exec options."

The key inputs to recognize, verified against the official documentation:

Input	Role	Note
prompt / prompt-file	Task instructions (inline string / repository file path)	Specify only one; defining both throws an error
sandbox	Sandbox mode	workspace-write / read-only / danger-full-access
model & effort	Target model and reasoning effort	Defaults used if omitted; avoid hardcoding model names
output-file	Writes the final message to a file	Useful for artifacts or diff comparisons
codex-args	Passes extra CLI options	JSON array (e.g., ["--ephemeral"]) or shell string (e.g., --profile ci)
codex-version	Pins a specific CLI version	Defaults to the latest release if omitted
codex-home	Sets a shared Codex home directory	Useful for sharing configurations/MCP settings across steps

Key details:

sandbox requires careful consideration. As covered in Article 15, there are three sandbox levels—read-only (read-only), workspace-write (write permissions for the workspace), and danger-full-access (full access). In CI, the official guide recommends "matching sandbox permissions to the task's requirements, choosing the narrowest scope that allows execution." For reviews (read-only), use read-only; to let it write code or apply patches, use workspace-write. The minimal PR review workflow above omits sandbox because reviews run in read-only by default.

Note this default configuration: codex exec defaults to a read-only sandbox (the docs state: "By default, codex exec runs in a read-only sandbox"). If your workflow asks Codex to modify files (like auto-fixing a bug), you must explicitly configure sandbox: workspace-write; otherwise, write operations will fail. Do not assume it has write access by default in CI.

codex-args acts as a bypass. It passes options directly to the underlying CLI. A common use case: requesting structured JSON output by passing --output-schema (which forces the final response to match a defined JSON Schema, making it readable by downstream scripts). Use this to generate formatted security reports.

Leave model and effort blank. The docs state: "leave blank to use defaults." Model names and settings change frequently; avoid hardcoding model versions in your YAML—if you must specify them, ensure they match active models on your account.

How do these inputs map to CLI behaviors? For example, when using output-file: if I omit output-file and want to review what Codex outputted, I have to scroll through long runner console logs. Configuring output-file: codex-output.md paired with a upload-artifact action saves the Markdown output, allowing easy inspection. This is the recommended configuration: save via output-file and upload as an artifact to preserve logs.

A security detail: codex-action starts a Responses API proxy to forward your OpenAI key (only when openai-api-key is defined). This proxy reduces key exposure on the runner—which is why the docs recommend using codex-action rather than manually installing the CLI and passing keys.

💡 Summary in one sentence: Action inputs map directly to CLI options—sandbox sets permissions (defaults to read-only; write operations require workspace-write), prompt/prompt-file are mutually exclusive, leave model fields blank to use defaults, use codex-args to pass raw arguments (like --output-schema), and save outputs to files for artifact tracking.

---

05 Keys and Permissions: Security in CI Automations

Every workflow contains this line:

openai-api-key: ${{ secrets.OPENAI_API_KEY }}

This section covers key security—where errors in CI configuration carry high risks. It involves two aspects: how keys are stored, and what permissions Codex holds on the runner.

Rule 1: Store Keys in GitHub Secrets; Never Hardcode

The official guide states:

Save your OpenAI key as a GitHub secret (like OPENAI_API_KEY) and reference it in your workflow.

Why is this critical? GitHub repositories—especially public ones—are publicly visible. Hardcoding a key in your YAML is equivalent to posting a photo of your house keys online. Scraper bots scan repositories constantly, and once a key is exposed, they run API queries charging your account.

Analogy: Locking keys in a safe, and referencing a keycard name in YAML. GitHub Secrets is that safe—encrypting and storing your keys without exposing them in logs or code. The code ${{ secrets.OPENAI_API_KEY }} is not the key; it is an instruction to "fetch the key named OPENAI_API_KEY from the safe." You can share the YAML file publicly because it contains no sensitive data.

To save keys: go to your repository Settings → Secrets and variables → Actions, click New repository secret, name it OPENAI_API_KEY, paste your API key (fetched from OpenAI, Article 04), and save. Reference it in your workflow using ${{ secrets.OPENAI_API_KEY }}.

Rule 2: Do Not Define Keys as Job-Level Environment Variables

This is a subtle detail flagged in the non-interactive mode docs:

Do not set OPENAI_API_KEY or CODEX_API_KEY as a job-level environment variable in workflows that checkout or run untrusted code. Build scripts, tests, dependency lifecycle hooks, or compromised actions in the same job can read these environment variables.

Simply put: even if you store your key in Secrets, declaring it under env: at the job level (making it visible to the entire job) exposes it to any script running in that job—including tests, install scripts, or compromised third-party actions. The correct approach is passing the key exclusively to the codex-action step (as shown in our example under with:), keeping it out of the job-level environment.

This is why the docs recommend using codex-action rather than manually installing the CLI—its Responses API proxy minimizes key exposure.

Rule 3: Restrict Codex Permissions on the Runner

The docs state: "On a GitHub-hosted runner, Codex holds broad access permissions unless you restrict it." It provides inputs to manage exposure:

Input	Role	Default / Note
safety-strategy	Drops sudo privileges before running Codex, protecting keys in memory	Defaults to drop-sudo; must set to unsafe on Windows
unprivileged-user	Sets codex-user to run Codex as a low-privilege user account	The account must have read/write access to the checkout path
read-only	Prevents Codex from modifying files or using networks	It still runs with elevated privileges, so do not rely on it alone to secure keys
sandbox	Restricts file system and network access within Codex	Use the narrowest mode that allows execution
allow-users / allow-bots	Restricts which users can trigger the workflow	Defaults to users with write access to the repository

Key settings:

safety-strategy defaults to drop-sudo; keep it enabled. It drops sudo privileges before running Codex, and this action is irreversible for the job—adding a barrier to protect keys on the runner. On Windows runners, this fails and requires safety-strategy: unsafe; however, the docs state: never use unsafe on multi-tenant runners.

read-only is not a complete safety boundary. The docs warn: read-only blocks file writes and network calls, but Codex still runs with elevated system privileges; "do not rely on read-only alone to protect keys." Protect keys using drop-sudo or low-privilege users.

allow-users / allow-bots govern triggers. By default, only users with write permissions to the repository can trigger the action; list trusted service accounts here explicitly if needed. In public repositories, restrict this to avoid letting arbitrary users trigger Codex executions on your repo.

The security checklist:

❌ Risky	✅ Secure
Hardcoding keys in YAML files	Storing keys in GitHub Secrets, referencing them in steps
Setting keys as job-level env variables	Passing keys exclusively to the codex-action step
Setting safety-strategy: unsafe on multi-tenant runners	Retaining drop-sudo or configuring low-privilege user scopes
Allowing anyone to trigger workflows	Restricting triggers via events, approvals, or allow-users
Feeding PR descriptions or commits directly as prompts	Sanitizing inputs to check for prompt injection

The "sanitize inputs" check targets prompt injection (prompt injection)—where users write malicious instructions inside PR descriptions, commits, or issue bodies to trick Codex. The docs warn: inspect external texts for HTML comments or hidden text before passing them to Codex. This is critical in CI environments where external users can open PRs. Another tip: execute Codex in the final step of a job to prevent subsequent steps from inheriting unintended state changes.

💡 Summary in one sentence: CI security involves three layers—1. Store keys in Secrets; 2. Pass keys exclusively to the action step, avoiding job-level env blocks; 3. Retain drop-sudo (default) and use allow-users to manage triggers; sanitize inputs to block injection and run Codex in the final step of the job.

---

06 Scheduled Tasks: Automations in the Desktop App

Having covered GitHub Actions, let's explore the second path—Automations (Automations) running in the Codex Desktop App, triggered by schedules to manage background tasks.

The bottom line: Automations run tasks in the background on a schedule, placing findings in your inbox and archiving runs if there is nothing to report. The docs state:

Automate periodic tasks in the background. Codex adds findings to your inbox, automatically archiving the run if there is nothing to report.

Analogy: A recurring reminder alarm that filters notifications. You configure a reminder on your phone to "take medicine at 9 AM daily"—it alarms every day. Automations are smarter: they evaluate if there is anything to report—pushing findings to your inbox if there are issues (like the alarm ringing), and archiving the run silently if there are none (like realizing you don't need medicine today and staying quiet). Scheduled execution paired with noise filtering is the value of Automations.

Typical Scenarios

Common use cases:

• Generating a "Daily Project Summary": the docs list a practical example—"review commits on origin/master or origin/main over the past 24 hours, group them by workflow, and compile a summary." I run this daily to review what changed yesterday before starting work, saving me from digging through commits manually.
• Running periodic code audits: "scan my recent commits daily to check for introduced bugs and write fixes."
• Monitoring long-running tasks: covered under thread automations below.

Two Types: Standalone Runs vs. Thread Automations

Automations divide into two types:

	Standalone / Project Automation (standalone)	Thread Automation (thread automation)
Execution	Launches a new run from scratch	Returns to the same conversation thread
Context	Fresh context on every run	Retains thread context across runs
Output	Listed in the Triage inbox as a run	Appended to the conversation thread
Best For	Independent summaries, cross-project audits	Monitoring long-running tasks on a schedule

Standalone automations are suited for daily summaries—each run starts clean, and results land in your inbox. Thread automations act as periodic checks—like checking if a long process has finished, or checking GitHub periodically for PR updates and replying. The docs suggest: write "durable" prompts for thread automations—specifying what to check on wake-up, how to evaluate if there is something to report, and when to pause or prompt for input.

Running Locally vs. in Worktrees

For Git repositories, configure automations to run either in your local project workspace or in a background worktree (Worktree, Git's multiple checkout system covered in Article 25). The tradeoffs:

• Worktree mode: isolates automation changes from your active edits—the docs state: "use worktree to isolate automation changes."
• Local mode: runs directly in your active workspace, risking overwriting active edits—the docs state: "use local mode to run directly in the active checkout, but be aware it can modify files you are editing."
• For non-version-controlled paths: runs in the project directory.

I recommend using Worktree mode by default for Git automation to avoid letting background runs overwrite your active edits. However, Worktrees consume disk space; archive completed runs to clean them up.

Creation and Permissions

To create an automation easily, instruct Codex in a standard chat session: "describe the task, set the schedule, specify whether to run it as a standalone task or link it to the thread, and Codex draft the automation prompt and configure the schedule." You can trigger a skill (Article 22) inside the automation by referencing $skill-name.

Permissions rules:

First: Automations use your default sandbox configurations. If your default is read-only, tools attempting to write files or use networks will fail—the docs suggest setting the default to workspace-write to let them modify files. Conversely, running automations with full access carries security risks (as they run unattended); restrict them to workspace-write and use rules to manage permissions.

Second: Automations run with approval_policy = "never" (if permitted by organization policies). This allows them to run unattended without prompts. However, the sandbox boundary becomes more critical—unattended runs must be governed by sandbox rules. If administrators disable approval_policy = "never" in requirements.toml, automations fall back to prompt behaviors.

A tip: test the prompt manually in a chat session before scheduling it. This verifies if instructions are clear and output formats are correct. Testing prompts first avoids cluttering your inbox with poorly formatted daily reports.

⚠️ Prerequisite: your local machine must be on, Codex running, and the project path accessible for local automations to trigger. The housekeeper must be home to work.

💡 Summary in one sentence: Automations are scheduled local background tasks that run periodically and notify you only when there are findings (saving runs to your inbox and archiving empty ones); they split into standalone and thread types; use Worktree mode for Git isolation, and test prompts manually first while relying on sandboxing for safety.

---

07 Hands-on: Scheduling a Daily Summary Task

Below, we configure and schedule a daily summary task in the Codex Desktop App. It runs locally, does not require admin write access, and is quick to verify.

Prerequisite: Install the Codex Desktop App (Article 07), verify you are logged in, and open a local project (a Git repository is preferred to check commits). GUI layouts may change with versions.

Step 1: Test the prompt manually (recommended)

Open the project, start a chat session, and send the prompt manually to verify output:

Check commits in this repository over the past 24 hours and write a brief summary in Chinese:
- Group by change topics (do not list commits individually)
- Write one or two sentences per group summarizing what changed
- If there are no commits in the past 24 hours, output "过去 24 小时没有新提交"

Expected: Codex checks the Git logs and returns a summary (or reports no commits). This verifies if the prompt returns the desired format. Adjust the prompt if needed.

Step 2: Instruct Codex to schedule it

In the same thread, ask Codex to schedule it:

Schedule this summary task as a standalone automation running daily at 9 AM.
Run it in a worktree to avoid touching my local files. If there are no commits, archive the run silently.

Expected: Codex drafts the automation prompt, sets the schedule, and configures it to run in a Worktree. It may ask you to confirm details; click confirm. You can also configure this manually under the automations panel in the sidebar.

To use custom schedules, use cron syntax (e.g., "every Monday at 9 AM") by selecting custom schedule on creation.

Step 3: Verify the automation in the panel

Open the automations panel in the Codex App sidebar.

Expected: The list displays your scheduled automation, showing its schedule (daily at 9 AM), type (standalone), and target environment (worktree). This confirms the task is scheduled.

Step 4: Trigger the task manually

Do not wait until 9 AM. Select the automation in the panel and click run now to trigger a manual run (the docs suggest: "review the first few runs to verify outputs").

Expected:

• The task runs in the background (status updates in the panel).
• Once finished, if commits exist, the summary appears in your Triage (inbox); if no commits exist, the run archives silently without alerting you.
• Verifying the report (or the silent archive) confirms the workflow.

Step 5: Review and clean up

Open the summary in your inbox and review the layout. If needed, adjust the automation prompt. If you no longer need the task, archive it—which prunes associated Worktrees to save disk space.

This walks you through the flow: testing prompts → scheduling automations → verifying setup → manual run → cleanup. All background tasks follow this process.

💡 Summary in one sentence: The hands-on workflow has five steps—test prompt in chat → ask Codex to schedule it as a daily Worktree automation → verify in the automations panel → trigger manually to test → review output and archive if no longer needed; verifying local scheduling.

---

08 Summary

We have explored Codex automation—using GitHub Actions for CI/CD integrations and Automations for local scheduled tasks, establishing background layers to manage tasks while you are away.

Let's review the key points:

Automation Path	Execution	Key Takeaway
Understanding paths	Action (Cloud) vs. Automations (Local)	Event-triggered for collaboration vs. time-triggered for background utilities
CI integrations	openai/codex-action@v1	Runs codex exec under the hood, event-triggered (not comment-triggered)
Managing workflows	.github/workflows/ YAML	Data flow: event → checkout → review → final-message → post feedback
Configuring runs	Action inputs	sandbox defaults to read-only; write tasks require workspace-write
Securing keys	Secrets + permissions settings	Store in Secrets, avoid job-level env variables, keep drop-sudo active
Scheduled tasks	Desktop App Automations	Runs periodically, posts to inbox only on findings; Worktree isolation recommended

You should now be able to: choose between GitHub Actions and local Automations; write and customize a codex-action workflow; manage sandbox permissions in CI; secure keys using Secrets and step-level scopes; and schedule Worktree-isolated automations in the Desktop App. This automation setup shifts Codex from an interactive assistant to a round-the-clock teammate.

Once the guards and housekeepers are configured, you can delegate recurring chores and focus on core tasks.

---

The next article [28 Non-Interactive Mode with codex exec]—we mentioned that GitHub Actions and Automations run codex exec under the hood. This non-interactive command accepts prompts and returns results without entering the terminal UI. The next article covers it: managing stdout/stderr output pipes, parsing --json event streams, and piping input/output to git, gh, or Slack. Once you customize inputs and outputs for custom scripts, mastering codex-action requires digging into codex exec.

---

Recommended Reading

• Memory Systems (Memories & Chronicle): Help Codex Remember You Across Sessions
• Writing Prompts: Communicating Effectively with Codex
• IDE Extensions (VS Code etc.)