Scheduled Task Automation with Codex

It is Monday morning. Over the weekend, three dependency vulnerabilities were published, someone merged a commit with a console.log statement, and the test coverage on the payments module dropped from 85% to 72%. You find out about these during standup. But if you had set up Codex automations on Friday, you would have arrived to a prioritized inbox with each issue already identified, analyzed, and — in some cases — fixed.

What You’ll Walk Away With

• Ready-to-use automation prompts for the most common recurring development tasks
• A workflow for testing automations safely before scheduling them
• Techniques for combining automations with skills for complex multi-step workflows
• Security and sandbox configuration for unattended background tasks

The Workflow

How Automations Work

Automations run locally in the Codex App on a schedule you define. Each run:

1. Creates a new worktree (for Git repositories) so it never touches your main checkout
2. Executes the prompt with your default sandbox settings
3. Reports findings to your Automations inbox in the Codex App sidebar
4. Archives the run automatically if there is nothing to report

You need the Codex App running and the project available on disk for automations to execute.

Step 1: Test Before Scheduling

Never schedule an automation blindly. Test the prompt manually in a regular thread first.

1. Open the Codex App and create a new thread in the same project.
2. Choose Worktree mode (since automations use worktrees).
3. Paste your automation prompt and run it.
4. Review the results: Did it find the right things? Did it make appropriate changes? Did it stay within scope?

Iterate on the prompt until you are satisfied, then create the automation with the tested prompt.

Step 2: Set Up Core Automations

Here are the automations most teams should run from day one:

Daily: Code Quality Check

Tip

Copy-paste automation prompt for daily quality check:

Daily code quality check on the latest main branch:

1. Pull the latest from origin/main
2. Run the linter (npm run lint). Report any new warnings or errors.
3. Run the type checker (npm run type-check). Report any type errors.
4. Check for console.log, console.error, or debugger statements in src/ (excluding test files)
5. Check for TODO or FIXME comments added in the last 24 hours of commits
6. Run npm audit and report any new Critical or High severity vulnerabilities

If issues are found, report each one with the file path and a suggested fix.
If everything is clean, report that no issues were found.

Weekly: Dependency Health

Tip

Copy-paste automation prompt for weekly dependency update:

Weekly dependency health check:

1. Run npm outdated and list packages that are more than 1 major version behind
2. Run npm audit and categorize vulnerabilities by severity
3. For each Critical vulnerability, check if an update is available that fixes it
4. For packages with available minor or patch updates that fix vulnerabilities, update them
5. After updating, run the full test suite
6. If tests pass, report which packages were updated and why
7. If tests fail after an update, revert that specific update and report the failure

Do NOT update major versions automatically. Only report them for manual review.

Nightly: Bug Hunter

Tip

Copy-paste automation prompt for nightly bug detection:

Check my commits from the last 24 hours and look for bugs:

1. Use git log --since=1.day to find recent commits
2. For each commit, review the changed files for:
   - Off-by-one errors in loops or array operations
   - Unhandled promise rejections or missing error handling
   - Race conditions in concurrent operations
   - Missing null checks on values that could be undefined
3. If you find a potential bug, verify it by checking the surrounding code and any related tests
4. For confirmed bugs, propose a minimal fix and a regression test

Only report issues you are confident about. Do not flag style preferences or theoretical concerns.

This is similar to the $recent-code-bugfix skill pattern from the official Codex docs. You can also create a skill and invoke it from the automation:

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

Weekly: Architecture Drift Detection

Weekly architecture check:

1. Pull the latest from origin/main
2. Compare the current codebase structure against docs/ARCHITECTURE.md
3. Check for:
   - New directories or modules not documented
   - Documented modules that no longer exist
   - New cross-module dependencies that violate documented boundaries
   - New external service integrations not mentioned in the architecture doc
4. If drift is detected, update docs/ARCHITECTURE.md to match reality

Report what changed and whether it represents intentional evolution or accidental drift.

Daily: Team Activity Briefing

Tip

Copy-paste automation prompt for daily briefing:

Look at the latest remote origin/main. Produce a briefing for the last 24 hours of commits:

- Group by workstream rather than listing each commit
- Write a short narrative per workstream explaining the changes
- Include PR links inline (e.g., [#123](...)) without a "PRs:" label
- Bold contributor names
- Only include commits within the current cwd
- Use gh to fetch PR titles and descriptions

Format with Markdown headings, horizontal rules, and bullet points.

Step 3: Combine Automations with Skills

Skills let you encapsulate complex workflows that automations can invoke. Create a skill, save it to your personal or repo skills directory, and reference it with $skill-name in the automation prompt.

Example: Create a $test-coverage-report skill that knows how to run coverage, compare to baselines, and format the output. Then the automation becomes:

Run $test-coverage-report on the latest main branch. If coverage dropped on any module, investigate and propose tests to restore it.

Skills make automations more maintainable: update the skill once, and every automation that uses it gets the improvement.

Step 4: Configure Security for Background Tasks

Automations run with your default sandbox settings. Since they run unattended, security configuration matters.

Recommended sandbox settings for automations:

• workspace-write (default recommendation) — lets Codex read and modify files in the project. Tool calls that need network or access outside the workspace fail unless explicitly allowed.
• Use rules to selectively allow specific commands (for example, allow npm audit which needs network access).

# Example rule allowing npm audit in automations
[[rules]]
match = "npm audit"
action = "allow"

Caution

Avoid running automations with full access sandbox mode. Background tasks with full access can modify files, run arbitrary commands, and access the network without asking. If an automation prompt is too broad or ambiguous, this can lead to unintended changes. Start with workspace-write and selectively allow specific commands.

Approval policy:

Automations use approval_policy = "never" when your organization allows it, so they can run without waiting for manual approval. If your admin has restricted this, automations fall back to your selected approval mode — which may mean they pause and wait for approval, defeating the purpose. Check your organization’s requirements.

Step 5: Manage Your Automation Inbox

The Automations pane in the Codex App sidebar is your inbox. It has a Triage section where automation runs with findings appear. You can:

• Filter to show All runs or only Unread ones
• Click into a run to see the full conversation and any diffs
• Archive runs you have addressed
• Pin runs you want to keep (this also prevents the worktree from being cleaned up)

Build a routine: every morning, check your automation inbox before standup. Address findings, sync fixes to local, and archive completed items.

When This Breaks

Automation runs while you are not looking and makes unintended changes. If sandbox is set to full access and the prompt is vague, Codex might modify files in unexpected ways. Use workspace-write mode and review the first few runs of any new automation before trusting it. The worktree isolation protects your main checkout, but the worktree changes can still be synced or turned into PRs.

Worktree buildup from frequent automations. Daily automations create one worktree per run. Over a week, that is 7 worktrees just for one automation. Codex cleans up worktrees older than 4 days (when you have more than 10), but frequent automations can still accumulate. Archive runs promptly and do not pin them unless you need to keep the worktree.

Automation reports the same findings every day. If a linting error has been in the codebase for weeks and nobody fixes it, the daily automation keeps reporting it. Add an ignore mechanism: “Skip issues listed in .automation-ignore.json. Only report new findings since the last run.”

The Codex App must be running. Automations are local — they run on your machine in the Codex App. If you close the App or your machine is asleep, automations do not run. Enable “Prevent sleep while running” in the App’s settings if you want overnight automations to complete. For truly unattended automation, consider the Codex SDK or GitHub Action for server-side execution.

What’s Next

System Design with Codex Use automations alongside architectural planning for long-term codebase health

CI/CD with Codex GitHub Action Complement local automations with server-side CI automation