Recurring regression checks are valuable only when they produce evidence someone can trust. A scheduled AI task that merely says ?tests look good? creates noise; a useful task identifies the exact revision, runs an approved command, preserves the real exit result, and reports what a QA engineer should inspect next.

This tutorial shows how to use Codex scheduled tasks for QA to run a bounded regression-triage workflow. The design uses an isolated Git worktree, narrow permissions, deterministic tests, and human review. It also tests the operational failures that commonly explain a missed run: the computer was off, the desktop app was closed, the project disappeared, or the task lacked required access.

What Codex scheduled tasks can do

Official Codex guidance says scheduled tasks can run in the background from the desktop experience. For a Git repository, a task can run in the local project or in a dedicated worktree. Worktrees isolate scheduled changes from unfinished work in the main checkout, which is the safer default for recurring QA maintenance.

There are important boundaries. A local-project task needs the computer powered on, the desktop app running, and the selected project available on disk. The web Scheduled interface can use uploaded context and connected tools, but it cannot operate directly in a local folder. The Codex CLI and IDE extension can help prepare and test a workflow, but they do not provide the Scheduled management interface.

Choose a narrow QA outcome

Do not begin with ?test everything and fix failures.? Start with one repeatable outcome, such as triaging a stable API smoke suite after the latest approved change. Define the test command, time budget, evidence files, allowed edits, and stop conditions before adding a schedule.

  • Input: current repository state and a sanitized test environment.
  • Action: run one approved smoke or regression command.
  • Evidence: revision, command, exit code, failed test IDs, and artifact paths.
  • Allowed change: none during the first pilot; investigation is read-only.
  • Stop: report blocked when credentials, network, project files, or the test environment are unavailable.
  • Decision: a human owns defect creation, priority, code changes, and release approval.

Step 1: Make the regression command deterministic

Run the command manually from a clean checkout. Remove prompts that wait for keyboard input, confirm the environment name, and use a fixed test-data strategy. The command should return a non-zero status when tests fail and write machine-readable evidence such as JUnit XML, Playwright traces, screenshots, or API logs.

Test three controlled states before involving Codex: a passing build, a known product failure, and an unavailable dependency. If all three produce the same exit status or vague console output, scheduling will only automate ambiguity.

Step 2: Draft a durable task prompt

A scheduled run should not depend on instructions mentioned casually many messages earlier. Put the durable contract directly in the saved prompt. Here is a compact pattern:

Goal: triage the approved API smoke suite.
Scope: inspect this repository and run the documented smoke command only.
Before running: record branch, commit, environment, and clean/dirty state.
Do not modify source, tests, configuration, credentials, or remote systems.
Report: command, exit status, failed test IDs, artifact paths, likely category,
and one recommended human follow-up.
If prerequisites are missing, report BLOCKED and stop.
Never call a failed, skipped, or incomplete run a pass.

Test this prompt in a regular chat first. Official guidance recommends reviewing the first few scheduled runs and tightening the prompt, tools, or cadence when the output is too broad.

Step 3: Use an isolated worktree

Select a dedicated worktree for a Git project so background activity cannot overwrite unfinished local changes. Keep the first pilot read-only even inside the worktree. Isolation reduces collision risk, but it does not make an unsafe command safe or prove the agent selected the correct revision.

At the beginning of every run, capture the repository path, branch, commit hash, working-tree status, dependency lockfile state, and test-environment label. A report without revision identity cannot support regression comparison.

Step 4: Start with narrow permissions

Scheduled tasks run unattended under the configured sandbox and organization policy. Start with the smallest filesystem and network scope that lets the smoke suite run. Do not grant broad access merely to suppress a blocked run. A clear blocked report is safer and more useful than an unattended task that can change unrelated files or reach production systems.

Use synthetic accounts, least-privilege tokens, staging-only endpoints, and redaction. Keep secrets out of prompts, screenshots, logs, and social summaries. If the suite needs a new host or command, update the approved workflow deliberately and rerun the negative permission tests.

Step 5: Schedule for signal, not volume

Choose a cadence that matches how often the tested system changes. A smoke check after a nightly staging deployment may be useful; repeating an unchanged expensive suite every hour may not be. Include a no-change path that records the evaluated revision and exits cleanly without inventing work.

The desktop Scheduled view shows active, paused, and completed tasks and their recent runs. Treat it as an operational inbox. Review missed, blocked, and failing runs separately from product regressions so infrastructure issues do not inflate defect metrics.

Step 6: Test the scheduler itself

Scenario Expected result Evidence
Known passing revision Pass only after the approved command exits successfully Revision, command, exit status, report
Seeded test failure Failure is preserved; no automatic pass claim Failed ID, log, trace, screenshot
Dependency unavailable Blocked or infrastructure result Error category and bounded retry record
Computer or app unavailable No false run result; missed-run condition is visible later Scheduled history and host availability record
Project moved or removed Blocked without creating files elsewhere Missing-path message
No repository change Clean no-change report Compared revision identifiers
Permission expansion requested Task stops instead of silently widening access Denied action and human follow-up

Step 7: Review evidence before action

Separate observation from interpretation. ?Test checkout_returns_409 failed with exit code 1? is evidence. ?The payment service is broken? is a hypothesis until reproduced and correlated with application logs, network traces, or a controlled comparison.

A QA engineer should independently rerun high-impact failures, inspect artifacts, classify product versus test versus environment causes, and decide whether to file a defect. If future iterations allow Codex to edit tests, require a separate change review and deterministic CI gate; do not let a scheduled task approve its own repair.

Screenshot checklist

  • The official Scheduled tasks documentation and local-project requirement
  • The manually tested durable prompt
  • The selected project and isolated-worktree option
  • The narrow permission or sandbox configuration
  • The recurrence and next-run time in Scheduled
  • A known passing run with revision and exit status
  • A seeded failing run with artifact links
  • A blocked dependency or denied-access result
  • A no-change run comparing revision identifiers
  • The final human triage record and cleanup decision

Common mistakes to avoid

  • Scheduling a prompt before proving it manually.
  • Running against the main checkout when isolation is available.
  • Using broad network or filesystem access to prevent blocked results.
  • Reporting a skipped, timed-out, or partial suite as passed.
  • Keeping worktrees and old runs forever without an archive policy.
  • Allowing the same unattended workflow to detect, edit, verify, and approve a change.

Final takeaway

Codex scheduled tasks can make recurring regression triage more consistent, but the schedule is only the trigger. Reliability comes from a deterministic command, an explicit evidence contract, isolated execution, narrow permissions, operational failure tests, and independent human review. Build the smallest useful loop first, inspect its early runs, and expand only when its pass, fail, blocked, and no-change outcomes are all trustworthy.

Official sources