ChatGPT scheduled tasks can run recurring work in the background: monitor a source, prepare a report, check a repository or produce a daily operations receipt. For marketers, the feature is useful when the job has a stable trigger, repeatable inputs, a bounded output and a clear reviewer. It is a poor fit for vague “find something interesting and publish it” prompts.
OpenAI’s current automation documentation distinguishes standalone tasks, tasks created in an existing chat, local projects and isolated Git worktrees. Those choices determine what context the run sees, whether the computer must remain on, what files can change and how failures accumulate. This guide focuses entirely on operating scheduled work; DMT’s ChatGPT Work, Codex and Plugins guide covers the broader system.
Choose the right scheduled-task shape
| Task shape | Context at each run | Machine requirement | Best marketing use |
|---|---|---|---|
| Standalone scheduled task | Starts fresh from its saved prompt/configuration | Depends on whether it uses remote-only capabilities or a local project | Stateless reminders, source checks and reports with explicit inputs |
| Task created in an existing chat | Uses the chat’s existing context | As above | Continuing a well-defined analysis where the prior conversation is intentional state |
| Local project task | Reads/works in the selected local project | Computer on and ChatGPT app running | Local reports, source ledgers and website/repository QA |
| Git worktree task | Runs in an isolated worktree | Computer on and app running | Repository changes that need branch isolation and a reviewable diff |
The default choice for a content radar is a standalone task that writes a bounded local receipt or queue item. Choose a chat task only when conversation history is deliberately part of the specification. Choose a worktree only when the task must edit a Git repository and isolation is worth the cleanup overhead.
What should a marketer schedule?
| Candidate | Good scheduled task? | Reason |
|---|---|---|
| Check official release feeds and write a candidate ledger | Yes | Clear sources, cursor, output schema and no external publication required |
| Publish three articles every day | No | Quota encourages filler; research, duplication, rights and rendered QA cannot be guaranteed by the trigger |
| Generate a Monday GSC performance brief | Yes, with stable access | Repeatable inputs and measurable output; keep recommendations separate from mutation |
| Change Google Ads budgets when performance drops | Not as an unsupervised first implementation | High-impact external mutation needs robust measurement, guardrails and approvals |
| Check broken internal links and prepare a proposed patch list | Yes | Read-only detection and a reviewable plan are bounded |
| Reply to all Reddit questions about the brand | No | Social posting, identity, moderation and context require human judgment |
A useful decision rule is: schedule the repetition, not the judgment. The task can collect, normalize, compare, validate and draft. A separate approval can own publishing, spending, deletion or external communication.
Step 1: test the exact prompt manually
OpenAI recommends running the prompt manually before scheduling it and reviewing the first outputs. A successful manual run proves the prompt is syntactically usable; it does not prove recurrence is safe. Test three states:
- Normal state: new source material exists and the task produces the intended receipt.
- No-op state: nothing changed and the task exits cleanly without filler.
- Failure state: a source, credential or local dependency is unavailable and the task records the blocker without guessing.
The no-op test is particularly important for a three-times-daily content radar. “No qualifying opportunity” is a valid output. A task that must always produce an article will eventually produce weak or duplicated work.
Step 2: write a task contract, not a motivational prompt
Objective
Check the approved official-source registry for material changes since the
last successful cursor and write one run receipt plus zero or more candidates.
Inputs
- C:\...\SOURCE-REGISTRY.md
- C:\...\state\source-cursors.json
- Current DMT inventory and topic graph (read-only)
Allowed actions
- Read official sources
- Update local cursor and run-receipt files
- Add pending candidate records to the local queue
Forbidden actions
- No WordPress, Sheet, email, social or ad-platform mutation
- No claim supported only by X, Reddit or a search snippet
- No filler candidate when nothing qualifies
Output schema
- run timestamp and source checks
- discovered URL, primary corroboration, reader question
- proposed query, intent, reader job, owner relationship
- action: watch, reject, refresh, new-url candidate or blocked
- exact failures and next action
Stop conditions
- authentication failure
- source rights ambiguity that the candidate depends on
- inventory/graph refresh failure
- task would require a forbidden mutationThis contract makes later review possible. The task knows what it may change, what counts as evidence, what a no-op looks like and when to stop.
Step 3: select model and reasoning deliberately
OpenAI’s automation UI allows model and reasoning selection. Use a smaller/faster model for deterministic collection and formatting, and a stronger reasoning setting where the task must reconcile sources or make a portfolio recommendation. Do not bind the whole automation to one model name unless absence of that exact worker truly invalidates the work.
- Collection: stable source list, canonicalization, hashes and simple classifications.
- Qualification: stronger reasoning to compare intent, owner overlap, evidence and information gain.
- Drafting: an approved candidate plus a source ledger, with deterministic citation checks.
- Release: accountable final reviewer plus machine gates; never delegated solely to the scheduled worker.
Step 4: choose local project or worktree correctly
A local project task requires the machine to be on and the ChatGPT app running. If a laptop sleeps overnight, an overnight local run may not happen as expected. Document this dependency instead of treating it as a mysterious model failure.
Use a Git worktree when the task must create a code/content change that should be isolated from the main working directory. Worktrees can accumulate if a frequent schedule creates one per run. Add cleanup and branch naming rules, and never delete a worktree with unreviewed user changes.
| Need | Local project | Worktree |
|---|---|---|
| Read/write non-Git operational files | Good fit | Usually unnecessary |
| Modify tracked code with reviewable isolation | Risk of colliding with current work | Preferred |
| Run three times daily | One durable workspace can work | Can create excessive worktrees |
| Preserve user’s dirty working tree | Requires careful scope | Stronger isolation |
| Publish to WordPress | Workspace choice does not replace release gates | Same |
Step 5: grant the narrowest permissions
Scheduled work is unattended, so OpenAI runs it with the task’s configured sandbox/permission context. Use read-only access for monitoring and reporting. Use workspace write access only for explicit output/state directories. Full access should be exceptional and still constrained by the task contract.
| Permission | Appropriate task | Failure if over-granted |
|---|---|---|
| Read-only | Audit, inventory, performance brief | Minimal mutation risk |
| Workspace write | Receipts, drafts, local queue and controlled patches | Can overwrite in-scope files if paths are vague |
| Network to allowlisted sources | Official-source monitor | Prompt injection or data leakage if open-ended |
| External app/plugin write | Only a separately approved release worker | Unreviewed publication, messaging or business changes |
| Full filesystem/system access | Rare operational maintenance with exact targets | Large blast radius |
A plugin or Skill can simplify a workflow, but it does not automatically make the workflow safe. Review every tool the task can call, its authentication scope and whether it can mutate an external system. Explicitly invoking a skill with $skill-name can improve repeatability in Codex; verify the skill’s current instructions and version.
Step 6: set the schedule and timezone
Standalone tasks can use an RFC 5545 recurrence rule. Keep the timezone explicit and test daylight-saving behaviour if the business operates across regions. For India, a three-run local schedule can be represented conceptually as:
DTSTART;TZID=Asia/Kolkata:20260812T090000
RRULE:FREQ=DAILY;BYHOUR=9,14,19;BYMINUTE=0;BYSECOND=0Use the product’s current task editor to confirm how it stores multiple daily times. Do not assume a server is using your laptop timezone. Record the next run displayed by the UI and compare it with the intended local time.
Step 7: build durable state
A chat transcript is not a production database. Store small explicit state outside the model context:
- last successful cursor per source;
- canonical source URL, ETag/Last-Modified and content hash where available;
- candidate ID, stage, owner URL and decision rationale;
- lease/claimed-by timestamp so two workers do not process the same item;
- last successful run and exact blocker;
- schema version and migration note.
Keep one authoritative production queue. A local radar ledger may mirror discoveries, but it should reconcile to the DMT Pipeline once an item enters production. Competing queues create duplicate drafting and ambiguous ownership.
Step 8: monitor the Scheduled view
OpenAI provides a Scheduled view for managing tasks and reviewing their state. The first run after any prompt, model, permission, connector or project change deserves manual inspection. Monitor outcomes, not merely “ran successfully.”
| Run metric | Healthy signal | Warning signal |
|---|---|---|
| Source coverage | All due sources checked or exact failures recorded | Silent skipping or repeated broad search instead of cursors |
| No-op rate | Many clean no-op runs are acceptable | Every run invents a candidate |
| Duplicate rate | Existing owner identified early | Same idea repeatedly enters drafting |
| Correction rate | Low and stable | Reviewers rewrite core claims each run |
| Runtime/cost | Bounded for the reader job | Growing context and repeated work |
| External mutation | Matches the task’s approved policy | Unplanned CMS, Sheet, email or social changes |
Failure recovery playbook
The machine was off
Confirm that the task uses a local project, then check whether the computer was awake and the ChatGPT app was running. Decide whether a missed run should be skipped or run once; do not blindly replay every missed interval.
Authentication or a connector failed
Stop before mutation, record the exact error and reauthorize the smallest necessary scope. Do not substitute cached inventory as current proof if the task depends on live state.
The task repeated old material
Inspect cursor updates, canonicalization and content hashing. Compare primary query, reader job and owner URL—not just headline similarity. A correct “refresh owner” decision is not a failed discovery.
A worktree accumulated
List worktrees and inspect branches/diffs before cleanup. Preserve unreviewed changes. Reduce task frequency or use a durable worktree when the workflow does not require a fresh branch per run.
Five practical marketing tasks
- Official-source content radar: discovers and corroborates candidates; never auto-publishes.
- Weekly GSC brief: compares current period, prior period and year-over-year with an exact query/page ledger.
- Content-decay monitor: identifies owners losing clicks/impressions and routes them to a refresh queue.
- Internal-link proposal worker: refreshes the graph and writes approved link suggestions with anchor checks.
- Release QA monitor: verifies scheduled/live URLs, metadata, canonical, mobile overflow and broken embeds, then records a receipt.
A complete content-machine task split
Do not ask one scheduled task to scan the web, judge SEO opportunity, draft five articles, publish them and update reporting. Split the jobs so each has one mutation boundary:
| Scheduled job | Cadence | Allowed mutation | Success |
|---|---|---|---|
| Content radar | Three daily scans | Local source cursor, run receipt and discovery queue | All due sources checked; zero or more corroborated candidates |
| Portfolio planner | Weekly | Pending Pipeline/Refresh Queue rows | Ranked new/refresh/watch/reject decisions with owner boundaries |
| Content worker | Daily or approved queue trigger | One claimed package; guarded WordPress only after gates | One accepted package or an honest blocked/no-op receipt |
| Internal-link worker | Weekly | Only pre-approved link rows | Graph-safe changes and verified anchors |
| Performance review | Monthly | Local report | Evidence-backed stop/double-down/refresh recommendations |
This topology prevents the three daily news scans from becoming three daily publication quotas. A source monitor can run frequently; release frequency should be governed by qualified queue demand and editorial capacity.
Notification policy
Notifications should cause an action. Alert immediately for authentication loss, unintended mutation, repeated policy denial, corrupted state or a release-verification failure. Summarize normal discoveries in a daily receipt. Do not notify on every successful no-op run; alert fatigue hides the event that actually needs intervention.
- Critical: unintended external write, credential exposure or destructive target ambiguity.
- Needs action: three consecutive runs blocked by the same dependency, source or permission.
- Review: a high-scoring candidate is ready for portfolio adjudication.
- Digest only: healthy checks, rejected duplicates and clean no-op runs.
Preflight checklist
- The reader job, inputs, output schema and no-op result are explicit.
- The prompt passed normal, no-op and failure manual tests.
- The model/reasoning choice matches the task.
- Local-machine and app-running requirements are documented.
- Permissions are the narrowest needed.
- Timezone and next run are verified in the UI.
- Durable state has cursors, IDs, schema and a recovery path.
- External mutation is either prohibited or separately gated.
- The Scheduled view and first outputs will be reviewed.
- A failed run preserves the exact blocker and does not fabricate completion.
FAQ
Do local scheduled tasks run when my computer is off?
No. OpenAI’s documentation says a local-project task needs the machine on and the ChatGPT app running. Remote-only task behaviour can differ, so verify the selected context.
Should every scheduled task use a Git worktree?
No. Use worktrees for isolated repository changes. A frequent read-only monitor or local receipt job usually needs a durable project, not a growing set of worktrees.
How this guide was verified
DMT checked the current OpenAI automation documentation and its official screenshots on August 11, 2026, then mapped the product behaviour to the practical content-radar/worker topology. Product options are date-sensitive; the task editor and next-run display remain authoritative for the user’s account.
Bottom line
ChatGPT scheduled tasks are most valuable as reliable operators around a narrow contract. For marketing, schedule source checks, data preparation, QA and proposal generation. Keep publication, spend, deletion and public communication behind explicit release authority. The difference between a helpful automation and a content spam machine is not the schedule—it is the queue, evidence standard, permissions, no-op behaviour and acceptance review wrapped around every run.
For deeper implementation, use the GPT-5.6 model-routing guide, the Codex subagent review pattern, the accepted-result economics method and the agent-harness production controls.
