Skip to content

ChatGPT scheduled tasks: work that runs without you

Running ChatGPT work on a schedule — standalone versus in-chat tasks, event triggers from Gmail, Slack and GitHub, worktree isolation, sandbox permissions, and the manual test you should never skip.

CurrentLast verified

Platforms

  • ChatGPT on the web
  • ChatGPT desktop app
  • ChatGPT mobile (event-triggered tasks)

What the official documentation says

  • Scheduled tasks run recurring work in the background; active, paused and completed tasks and their recent runs are reviewed in Scheduled.

    Scheduled tasks

  • In the desktop app, scheduled tasks can work with local projects and run in the project directory or an isolated worktree; the computer must stay on and the app running when a task needs local files.

    Scheduled tasks

  • Codex CLI and the IDE extension do not provide the Scheduled management interface — use ChatGPT web or the desktop app to create and manage scheduled tasks.

    Scheduled tasks

  • Standalone scheduled tasks start a new chat for each run; a scheduled task inside a chat returns to that same chat and uses its existing context.

    Scheduled tasks

  • Custom schedule controls cover custom cadences, and an advanced schedule can be edited as an RFC 5545 recurrence rule (RRULE), such as RRULE:FREQ=MONTHLY;BYMONTHDAY=1;BYHOUR=9;BYMINUTE=0.

    Scheduled tasks

  • On eligible plans, scheduled tasks can run from supported Gmail, Slack and GitHub events; event-triggered tasks are available on ChatGPT web and mobile and are not available in the desktop app, Codex CLI or the IDE extension.

    Scheduled tasks

  • One task can use multiple event triggers, but it cannot combine event triggers with a time-based schedule.

    Scheduled tasks

  • For Slack, @ChatGPT must be added to every channel the task watches; for GitHub, the connected app must have access to the repository.

    Scheduled tasks

  • Scheduled tasks run unattended with your default sandbox settings, and the documented advice is to start with the narrowest access that lets the task succeed.

    Scheduled tasks

  • The documentation advises testing a prompt manually in a regular chat before scheduling it.

    Scheduled tasks

Run it by hand first. This is not optional

The documentation repeats one piece of advice in two separate places: test the prompt manually in a regular chat before you schedule it.

The stated reason is practical — it is how you confirm three things. That the prompt is clear and scoped correctly. That the selected or default model, reasoning effort and tools behave as expected. That the resulting output is something you can actually review.

This belongs at the top of the page because scheduled tasks run unattended. An untested prompt on a daily cadence means producing something you will not read, every day — or worse, making an unexpected change in your repository, every day.

Standalone versus in-chat

This is the first real decision when configuring a scheduled task.

A standalone task starts a new chat for each run and reports results in Scheduled. It fits two cases: runs that should be independent of one another, and one task that should run across one or more projects.

A task inside a chat returns to that chat and uses its existing context instead of starting from a fresh prompt every time. The documented fits are specific:

  • checking a long-running operation until it finishes
  • taking a periodic snapshot of a connected source (note the distinction the documentation draws — a periodic snapshot, not a response to a supported app event)
  • reminding ChatGPT to continue a review loop at a fixed cadence
  • running a skill-driven workflow that uses plugins, such as checking PR status and addressing new feedback
  • continuing an ongoing research or triage chat without losing its context

There is one easily-missed requirement for in-chat prompts: make the prompt durable. It should describe what ChatGPT does on each run, how to decide whether there is anything worth reporting, and when to stop or ask you for input. Skip the last two and you get a stream of "nothing new" noise.

Event triggers: from "on the hour" to "when something happens"

On eligible plans, a task can fire on an app event rather than a clock. The documented support is:

  • Gmail — new incoming messages, optionally filtered by sender or subject.
  • Slack — new messages in selected channels, optionally filtered by author and by whether thread replies are included. Reactions, edits, deletes and direct messages are not supported.
  • GitHub — pull request activity in a repository. Filter by pull request, author, title or label, and choose whether reviews, comments, commit updates, or only merges should trigger it.

Three constraints are worth knowing before you design around this:

  1. Event-triggered tasks exist only on the web and mobile. Not the desktop app, not Codex CLI, not the IDE extension.
  2. You cannot mix event triggers with a time-based schedule. Several event triggers on one task is fine; "every day at 9" and "when a PR opens" is not.
  3. Connect and authorize the app first. Slack additionally needs @ChatGPT in every channel the task watches; GitHub needs the connected app to have access to the repository.

One runtime behaviour to remember: when several matching events arrive close together, ChatGPT may combine them into one run. To process pending events immediately, open Scheduled and choose Run now.

Worktrees keep the task away from your working copy

For a task in a Git repository, you choose between running in your local project and running on a new worktree. Both run in the background; the difference is isolation:

  • Worktree — the task's changes stay separate from your unfinished local work.
  • Local mode — it works directly in your main checkout, and the documentation says plainly that this can modify files you are still working on.

Non-version-controlled projects do not get the choice; tasks run directly in the project directory.

The cost is accumulation: a frequent schedule plus worktrees creates a lot of worktrees over time. The documented remedy is to archive runs you no longer need, and to avoid pinning runs unless you intend to keep their worktrees.

Permissions: start at the narrowest, not at "whatever works"

Scheduled tasks run unattended with your default sandbox settings. The consequences of each mode are spelled out:

  • read-only — tool calls fail if they need to modify files, access the network, or work with apps on your computer.
  • workspace-write — calls fail if they need to modify files outside the workspace, reach the network, or drive apps. You can selectively allowlist commands outside the sandbox using rules.
  • full access — background scheduled tasks carry elevated risk here, because ChatGPT may change files, run commands and access the network without asking. The recommendation is to move back to workspace write and use rules to define exactly which commands get full access.

There is also a managed-environment behaviour: scheduled tasks use approval_policy = "never" when your organization policy allows it, and fall back to the approval behaviour of your selected permission mode when admin requirements disallow that value.

The guiding rule is short — start with the narrowest access that lets the task succeed, and grant network or broader file access only when required.

Pair them with skills

The documentation recommends using skills to define the task's action and supply its tools and context, on the grounds that this keeps scheduled tasks maintainable and shareable across teams. When the workflow should not rely on automatic tool selection, select or invoke a specific skill in the task prompt; in the desktop app you can trigger one explicitly with $skill-name.

How to do it

  1. Run the prompt manually in a regular chat first and confirm the scope, the model behaviour and the output format.
  2. Choose the task type. Standalone if each run should be independent and appear as its own entry in Scheduled; in-chat if it should return to an existing chat with its context.
  3. Set the cadence with the custom schedule controls, or write an RRULE for an advanced schedule.
  4. If it should fire on an event rather than a clock, create it on the web or mobile and connect and authorize Gmail, Slack or GitHub first.
  5. In a Git repository, choose where it runs — a worktree isolates the task's changes from your unfinished work; local mode edits your main checkout.
  6. Review the sandbox settings and start from the narrowest access that works.
  7. Watch the first few runs, then adjust the prompt, tools or cadence.

On Windows

  1. The Windows desktop app supports scheduled tasks with the same Scheduled view in the sidebar.
  2. Any task that needs local project files requires the computer to stay on, the app running, and the project still present on disk at the scheduled time — this is not platform-specific.
  3. If you do not want that dependency on your machine, move the task to ChatGPT Work with Cloud selected instead.

On mobile

  1. The documentation states that event-triggered scheduled tasks are available in ChatGPT on the web and mobile.
  2. So you can create and manage Gmail, Slack and GitHub event-triggered tasks from a phone, and open Scheduled to review pending events or choose Run now.
  3. You cannot create a project-scoped scheduled task that needs folders on your computer from mobile.

Use cases

  • A morning briefing that summarises the last 24 hours of commits, grouped by workstream.
  • Watching pull request activity on a repository and following up when new review feedback lands.
  • Checking back on a long-running operation in the same chat until it finishes.

Common mistakes

  • Scheduling a prompt you have never run by hand. The documentation names testing first as explicit advice; skipping it means producing bad output unattended, on a schedule.
  • Trying to combine an event trigger with a time-based schedule. One task can have several event triggers, but not both kinds at once.
  • Adding a Slack trigger without adding @ChatGPT to every channel the task watches.
  • Reaching for full access to make a task "just work". The documentation warns specifically about background tasks under full access and points to workspace write plus rules instead.
  • Running a frequent schedule against worktrees in a Git repository and never archiving the runs, accumulating worktrees indefinitely.

FAQ

Standalone or in-chat — which do I want?
It comes down to context. A standalone task starts a new chat per run, which suits runs that should be independent of each other or one task that runs across several projects. An in-chat task returns to the same chat and uses its existing context, which suits following one thing over time — checking a long-running operation until it finishes, or reminding ChatGPT to continue a review loop at a fixed cadence.
Can a task react to email or Slack instead of a clock?
On eligible plans, yes. The documented triggers are Gmail new incoming messages (optionally filtered by sender or subject), Slack new messages in selected channels (optionally filtered by author, with a choice about thread replies; reactions, edits, deletes and DMs are not supported), and GitHub pull request activity in a repository. Event-triggered tasks are available only on the web and mobile.
Will a scheduled task edit files I am working on?
That depends on where you let it run. In a Git repository you choose between your local project and a new worktree — the documentation is explicit that local mode can change files you are actively editing, while worktrees keep the task's changes separate. In non-version-controlled projects, tasks run directly in the project directory.
What permissions does it run with?
Your default sandbox settings, unattended. Under read-only, tool calls fail if they need to modify files, access the network, or work with apps. Under workspace-write, calls fail if they need to write outside the workspace, reach the network or drive apps — rules can allowlist specific commands. Under full access, background tasks carry elevated risk, and the documentation recommends moving back to workspace write with rules. Scheduled tasks use approval_policy = "never" when organization policy allows it; if admin requirements disallow that, they fall back to the approval behaviour of your selected permission mode.
Can I schedule "9am on the first of every month"?
Yes. Beyond the custom schedule controls you can edit the RFC 5545 recurrence rule directly. The example given in the documentation is exactly that case: RRULE:FREQ=MONTHLY;BYMONTHDAY=1;BYHOUR=9;BYMINUTE=0.

Official sources

These are the pages this tutorial is checked against. Follow them if you need the vendor's exact wording.

Source status