OpenAI's scheduled tasks run recurring work in the background and, on eligible plans, can start from Gmail, Slack or GitHub events on ChatGPT web and mobile. Desktop tasks can use local projects. Unattended runs use your sandbox settings, and calls that need more access fail rather than ask.
What the documentation covers
This post summarizes OpenAI's page on scheduled tasks and automations as read on 19 October 2026. It is a plain reading of what the page says, with practical notes added. Details can change, so check the current page before you rely on a limit or a setting.
Where tasks are created and managed
You can create tasks from ChatGPT on the web when enabled for your workspace, from the desktop app, or by asking ChatGPT in a chat. The Codex CLI and the IDE extension do not have the Scheduled management interface. The Scheduled view works as an inbox: runs with findings appear there with an unread indicator. Standalone tasks start a new chat for each run, while tasks scheduled inside a chat reuse that chat's context.
Triggers
| Trigger | Where | Notes |
|---|---|---|
| Time schedule | Web, desktop and chat | Recurring background work |
| Gmail, Slack or GitHub event | ChatGPT web and mobile, eligible plans | Not available in the desktop app, Codex CLI or IDE extension |
| Combination | Not allowed | A task cannot combine event triggers with a time based schedule |
Event details matter. Slack triggers do not cover reactions, edits, deletes or DMs, and you must add the assistant to each watched channel. GitHub triggers need the connected app to have repository access. When events arrive close together they may be batched, and you can review pending events or choose Run now. Admins can control event triggers with the permission named Allow event triggered scheduled tasks.
Local versus web
Desktop tasks can work with local projects. Web tasks can use uploaded files and connected tools, but cannot work in a folder on your computer and do not keep a local folder or worktree between runs. For local file work, the page says to keep the computer on and the app running, and the selected project must still be on disk.
For Git repositories you can choose between running in the local project or in a new worktree. Local mode can change files you are editing. A worktree keeps scheduled changes separate from unfinished work. Frequent schedules can create many worktrees, so archive runs you no longer need.
Sandbox and approvals
Tasks run unattended with your default sandbox settings:
| Level | Behavior for unattended tasks |
|---|---|
| Read-only | Calls fail if they need to modify files, use the network or work with apps |
| Workspace-write | Calls fail if they touch files outside the workspace or need network access. Specific commands can be allowed outside the sandbox through rules |
| Full access | Flagged as elevated risk, as changes, commands and network access happen without asking |
Tasks use an approval policy of never when organization policy allows it. Otherwise they fall back to the approval behavior of the selected permission mode. Admins can enforce limits with admin requirements. The page's security advice is to start with the narrowest access that lets the task succeed, grant network or broader file access only when needed, test prompts in a regular chat first and review the first few runs.
Worked example: a GitHub triggered review task
A team wants a task that reviews each new pull request on a private repository. On ChatGPT web they connect GitHub, confirm the app has access to that repository only, and attach a GitHub event trigger. They test the prompt in an ordinary chat on a sample pull request first, as the page advises. They keep the sandbox at read-only so the task cannot change files or use the network on its own. Runs appear in the Scheduled inbox with an unread marker, and a reviewer reads the first ten before trusting it.
Because it is an event task, they also think about who can open pull requests. On a private repository, only members can. They would not attach the same task to a public repository without filtering authors, since outside contributors could plant text in a pull request.
Governance checklist for OpenAI tasks
- Is the task created in a managed workspace, with admins aware of event trigger permission?
- What apps are connected, and with what scope?
- What sandbox level does it use, and is full access allowed anywhere?
- Is the task pinned to a model that is scheduled for retirement? The page notes tasks that use retired models need updating.
- Who reads the Scheduled inbox, and how often?
- Is the project still on disk for local tasks?
For general design guidance on sandbox choice, see which sandbox level should an unattended task run in.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how tool calls from an assistant are checked before they run, and think about which of your task's connected apps you would want checked the same way.
Where Safeguard fits
Safeguard's MCP Guardrail and policies are GA capabilities for governing what assistants do through tool connections. The Safeguard CLI can also write code, and the download page lists a Local agent and a Cloud agent as Available.
Quick check
Can a ChatGPT task use a Slack trigger and a daily schedule together?
No. The page says a task cannot combine event triggers with a time based schedule.
What happens if a read-only task tries to edit a file?
The tool call fails, per the documentation.
Do Codex CLI and the IDE extension have the Scheduled view?
No. The page says they do not have the Scheduled management interface.
Sources
Last reviewed: 19 October 2026.
