Scheduled Recurring Automations

Every morning you open Slack to find three new bug reports from overnight users. You spend the first hour of your day just triaging — reproducing issues, locating relevant code, and prioritizing fixes. Codex automations can do this triage for you while you sleep, presenting you with a curated inbox of findings (and sometimes fixes) when you sit down at your desk.

What You’ll Walk Away With

• A step-by-step guide to creating, testing, and scheduling automations in the Codex App
• Three production-ready automation recipes: bug fix triage, daily briefings, and skill creation
• Security configuration that keeps automations safe even when running unattended
• Cleanup strategies that prevent worktree sprawl from frequent automation runs

Thread automations are first-class in App v26.415 (April 2026)

The April 16, 2026 Codex App release promoted automations from a beta toggle to a top-level capability:

• Scheduled wake-ups preserve conversation context — the app resumes the same thread, so iterative automations (e.g. “re-run yesterday’s plan, apply what changed”) retain memory across runs.
• Task sidebar surfaces plans / sources / artifacts / summaries from each automation run without opening the thread.
• Memories carry across runs — Codex remembers what it learned in yesterday’s automation when today’s fires.
• Artifact viewer renders PDFs, spreadsheets, and diagrams inline, so your morning triage inbox shows what the automation produced without downloads.

On the CLI side, hooks are stable as of CLI v0.124.0 (April 23) — if you want to augment or gate automation prompts before they execute, add a UserPromptSubmit hook in config.toml or requirements.toml.

Persistent /goal Workflows (CLI v0.128+)

The April 30, 2026 release added persistent /goal workflows — a first-class API for long-running, stateful objectives that survive across sessions. Unlike Claude Code’s /goal (which is session-scoped and clears on /clear), Codex’s /goal round-trips through the app-server and can be paused, inspected, and resumed from a different machine.

/goal is behind a feature flag. Enable it once by adding [features] with goals = true to ~/.codex/config.toml (CLI v0.128.0+), or pass codex --enable goals per invocation:

~/.codex/config.toml

[features]
goals = true

# Set a goal that persists across resume
codex
> /goal every TODO in src/billing/ is resolved or stop after 25 turns

# Later, from a different terminal — resume is a subcommand, not a flag
codex resume <thread-id>      # or: codex resume --last
# Goal is still active; turn count, condition, evaluator history all preserved

TUI controls (CLI v0.128+):

Command	Action
/goal <cond>	Set or replace the active goal
/goal	Show status (condition, turns, tokens, evaluator’s last reason)
/goal pause	Pause without clearing; preserves state for codex resume
/goal resume	Resume a paused goal
/goal clear	Clear the active goal

Goals integrate with MultiAgentV2 (also v0.128+): a parent agent can set a goal that subagents work toward as a stable target rather than receiving per-turn directives.

Fit: Multi-step migrations, daily maintenance loops, long-running QA passes, content/docs pipelines, multi-agent work that needs a stable target.

/hooks Browser and Hook Execution

CLI v0.129.0 (May 7, 2026) added a /hooks browser inside the TUI — comprehensive plugin and hook management with workspace sharing, share access controls, source filtering, and local share-path tracking. Hooks also gained pre/post-compaction execution, so you can run cleanup or validation when the model compacts conversation context.

# Inside the TUI
/hooks

# Lists all configured hooks, lets you toggle/edit/share

Hooks are stable as of v0.124 and configurable inline in config.toml and requirements.toml.

MultiAgentV2 Configuration

CLI v0.128.0 made MultiAgentV2 explicit and configurable instead of silently unbounded. The [multi_agent_v2] table exposes settings such as a cap on parallel subagents, a minimum delay between dispatches, a maximum spawn depth, and hints for which roots and subagent classes prefer v2. Confirm the exact key names against the current config reference before you commit them, since the surface is still evolving:

# config.toml — keys are illustrative; verify against the config reference
[multi_agent_v2]
thread_caps = 8           # max parallel subagents
wait_time_ms = 250        # min delay between dispatches
max_depth = 3             # how deep subagents can spawn subagents

Pair with permission profiles (also v0.128) to give different subagent classes different sandbox profiles.

How Automations Work

Automations are scheduled Codex threads that run locally in the background. The Codex App must be running and the selected project must be available on disk. For Git repositories, each automation run starts in a dedicated worktree so it never interferes with your main checkout.

Results appear in the Triage section of your sidebar inbox. If an automation finds nothing to report, it auto-archives. If it finds something actionable, it lands in your inbox as an unread item.

1. Create the automation by clicking the Automations section in the sidebar and defining a schedule and prompt.

2. Test the prompt manually first. Start a regular thread with the same prompt and verify the results are useful and scoped correctly.

3. Configure the schedule — hourly, daily, weekly, or custom cron-style intervals.

4. Review the first few runs closely. Adjust the prompt or cadence based on the quality of results.

5. Combine with skills by using $skill-name in your automation prompt for structured, repeatable workflows.

Production-Ready Automation Recipes

Recipe 1: Automatic Bug Fix from Your Own Commits

First, create a skill that finds and fixes bugs from your recent changes:

---
name: recent-code-bugfix
description: Find and fix a bug introduced by the current author
  within the last week. Root cause must map directly to the
  author's own changes.
---

# Recent Code Bugfix

1. Use git log --since=1.week --author=<author> to find recent changes
2. Look for failures in tests, lint, or runtime errors tied to those changes
3. Implement a minimal fix following project conventions
4. Run the smallest relevant verification step
5. Report the root cause, fix, and verification

Then create an automation with this prompt:

Check my commits from the last 24h and submit a $recent-code-bugfix.

Prompt: Daily executive briefing automation

“Look at the latest remote origin/main. Produce an executive briefing for the last 24 hours of commits that touch src/. Group by workstream rather than listing each commit. Write a short narrative per workstream that explains the changes in plain language. Include PR links inline. Use gh to fetch PR titles and descriptions. Only include the last 24h of commits.”

Recipe 2: Dependency and Security Scan

Scan package.json, Cargo.toml, and requirements.txt for dependencies
with known CVEs. For each vulnerable dependency, check if a patched
version exists that is compatible with our version constraints. If a
safe upgrade path exists, update the dependency and run the test suite.
Report all findings with severity levels.

Recipe 3: Automatic Skill Creation

Scan all of the ~/.codex/sessions files from the past day. If there
have been any issues using particular skills, update the skills to be
more helpful. If we've been doing something often that we should save
as a skill, create it. Only update skills if there's a good reason.
Let me know if you make any.

Security Configuration

Automations run unattended, so security settings matter more than for interactive threads:

Sandbox Mode	Risk Level	Recommendation
Read-only	Lowest	Good for reporting and analysis automations
Workspace-write	Medium	Recommended for most automations; allows file edits within the project
Full access	Highest	Avoid for automations; the agent can modify files, run arbitrary commands, and access the network without asking

Automations use approval_policy = "never" when your organization allows it. If your admin has restricted this, automations fall back to the approval behavior of your selected mode.

Full access warning

Full access sandbox with automations is dangerous. The agent runs commands and accesses the network without asking. Use workspace-write mode and selectively allowlist specific commands with rules if your automation needs to run something outside the sandbox.

Worktree Cleanup for Automations

Frequent automations create many worktrees. Without cleanup, this eats disk space fast. Best practices:

• Archive automation runs you have already reviewed
• Do not pin automation runs unless you intend to keep the worktree permanently
• Codex auto-cleans worktrees older than 4 days or when you exceed 10 total
• A snapshot is saved before cleanup so you can restore later if needed

When This Breaks

• Automation does not run: The Codex App must be running and your computer must be awake. Enable “Prevent sleep while running” in App settings for overnight automations.
• Results are too noisy: The prompt is too broad. Narrow the scope — specify exact directories, file patterns, or timeframes.
• Automation modifies wrong files: Check your sandbox mode. Read-only mode prevents accidental edits. Use workspace-write with explicit rules for what the automation should be allowed to change.
• Worktrees pile up: Archive old runs and unpin automations that are no longer needed. Check $CODEX_HOME/worktrees for orphaned directories.

What’s Next

• Worktrees — Understand the worktree system that automations rely on
• App Mastery — Skills, multi-project management, and the full App workflow
• Cost Management — Automations consume credits; learn to budget them effectively