Can Codex scheduled tasks run when my computer is off?

Not when the task needs a local project. Official guidance says the computer must remain powered on, the desktop app must remain running, and the selected project must remain available on disk.

Should a recurring QA task use the main checkout or a worktree?

Prefer an isolated worktree for a Git project when the task might inspect or change files. It separates background activity from unfinished local work, though permissions and review gates are still required.

Does a scheduled Codex pass result prove a release is safe?

No. The report must preserve the real deterministic test result and artifacts, and a QA engineer should independently review important findings and retain defect and release decisions.

Why did a local scheduled task not run?

Check whether the host was powered on, the desktop app was running, the project path was available, required permissions and network access were allowed, and the task was active at the expected local time.

Codex Scheduled Tasks for QA: Automate Recurring Regression Checks

bajpaiprashant

3 days ago

Codex Scheduled Tasks for QA: Automate Recurring Regression Checks featured image

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.