计划任务
如需完整文档索引，请参阅 llms.txt。文档页面的 Markdown 版本可通过在页面后追加
.md来获取 URL。
安排周期性任务在后台运行。查看活跃、已暂停和 已完成的任务以及最近运行记录，请前往 Scheduled。你可以将计划 任务与 技能 结合起来，完成更复杂的工作。
在 ChatGPT 桌面应用中，计划任务可以使用本地项目，并且 在项目目录或隔离的工作树中运行。请保持电脑开机并 在计划任务需要本地文件时让应用持续运行。
当你的工作区启用计划任务后，可以从 Chat 或 ChatGPT Work 网页端创建任务，并从 Scheduled管理运行记录。网页任务 可以使用已上传的上下文和已连接工具，但不能直接在 你电脑上的文件夹中工作。
Codex CLI 不提供 Scheduled 管理界面。请使用 ChatGPT 网页端 或桌面应用来创建和管理计划任务。 CLI 可以帮助你 先准备并测试提示词、技能或脚本。
该 IDE 扩展不提供 Scheduled 管理界面。请使用 ChatGPT 网页端或桌面应用来创建和管理计划任务。该 IDE 扩展可以帮助你先准备并测试提示词、技能或工作区更改 。
在网页端管理计划任务
Section titled “在网页端管理计划任务”打开 Scheduled 以查看任务状态和最近运行记录。使用独立计划任务 让每次运行都从已保存的提示词开始。使用聊天中的计划任务 当你希望 ChatGPT 回到同一个聊天及其已有 上下文时。
网页端的计划任务可以使用上传文件、已连接工具、技能，以及 该聊天可用的插件。它们不会在运行之间保留可用的本地文件夹或 工作树。请将持久性说明放在任务提示词 或附加技能中，并将所需源材料保存在可访问的 项目、上传内容或已连接服务中。
安排任务前，请在普通网页聊天中测试其提示词。 查看最初几次运行，然后在 结果过于宽泛或需要更多上下文时调整提示词、工具或频率。
例如，安排一个任务来评估遥测错误并提交修复， 或创建关于近期代码库更改的报告。对于 应持续使用同一上下文的长期工作， 请在现有聊天中安排任务。
对于限定到项目范围的计划任务，请保持机器开机并让 ChatGPT 桌面应用持续运行。当 任务计划运行时，所选项目仍必须在磁盘上可用。
在 Git 仓库中，你可以选择计划任务是在本地 项目中运行，还是在新的 工作树上运行。两种选项都会在 后台运行。工作树会将计划任务产生的更改与未完成的本地 工作隔离开，而在本地项目中运行可能会修改你仍在 处理的文件。在未受版本控制的项目中，计划任务会直接在 项目目录中运行。
你也可以让模型和推理强度保持默认设置，或者 如果想更好地控制计划任务的运行方式，也可以显式选择它们。
交互内容： CodexScheduledTasksIllustration 的动态演示请参阅页面顶部的官方原文链接。
计划任务会使用你的默认沙箱设置无人值守运行。请先使用 能让任务成功的最小访问权限，只有在需要时才授予网络或更广泛的文件 访问权限。 了解沙箱机制。
管理计划任务
Section titled “管理计划任务”在 Scheduled 中查找所有计划任务及其运行记录，它位于 ChatGPT 桌面 应用侧边栏。
该 Scheduled 视图相当于你的收件箱。有发现结果的计划任务运行 会显示在那里，未读指示会显示某次运行需要你关注。
交互内容： CodexScheduledTasksIllustration 的动态演示请参阅页面顶部的官方原文链接。
独立计划任务会为每次计划运行启动一个新聊天，并报告
结果于 Scheduled。当每次运行应彼此独立，或一个
计划任务需要跨一个或多个项目运行时，请使用它们。如果需要自定义
频率，请使用自定义计划控件。对于高级计划，请编辑其
RFC 5545 周期规则（RRULE），例如
RRULE:FREQ=MONTHLY;BYMONTHDAY=1;BYHOUR=9;BYMINUTE=0。
对于 Git 仓库，每个计划任务都可以在你的本地项目中运行，或 在专用后台 工作树上运行。请使用 工作树来将计划任务更改与未完成的本地 工作隔离开。当你希望计划任务直接在主 检出中工作时，请使用本地模式，但请注意它可能会更改你正在编辑的文件。 在未受版本控制的项目中，计划任务会直接在项目 目录中运行。你可以让同一个计划任务在多个项目上运行。
使用 ChatGPT Work 在网页端创建的计划任务，或在桌面应用中使用 ChatGPT Work 或 Codex 创建的计划任务，可以使用插件。计划任务也可以使用 技能。为了让计划任务便于维护并可在团队之间共享，请使用 技能 来定义操作，并提供工具和上下文。 当工作流不应 依赖自动工具选择时，请在任务提示词中选择或调用特定技能。
请求 ChatGPT 创建或更新计划任务
Section titled “请求 ChatGPT 创建或更新计划任务”你可以从 ChatGPT 或 Codex 聊天创建和更新计划任务。 描述工作内容、计划安排，以及每次计划运行是应返回到 当前聊天还是启动新聊天。 ChatGPT 可以起草提示词、选择 合适的目标位置，并在计划任务的范围或频率 发生变化时更新它。
例如，请求 ChatGPT 在某个部署完成期间从当前聊天安排一次后续跟进 ，或请求它创建一个独立计划任务，按周期检查 项目。
技能也可以创建或更新计划任务。例如，一个用于 看护拉取请求的技能可以设置一个计划任务来检查 PR 状态，使用 GitHub 插件并修复新的评审反馈。
在聊天中安排任务
Section titled “在聊天中安排任务”当你希望 ChatGPT 按计划返回该聊天 时，请在现有聊天中安排任务。计划任务会使用该聊天已有的上下文，而不是 每次都从新提示词开始。
聊天中的计划任务可以使用基于分钟的间隔来进行主动跟进 循环，也可以在需要在特定 时间签到时使用每日和每周计划。
在聊天中安排任务适用于：
- 检查长时间运行的操作，直到其完成
- 轮询 Slack、 GitHub或其他已连接来源，且结果应 保留在同一聊天中
- 提醒 ChatGPT 按固定频率继续评审循环
- 运行由技能驱动并使用插件的工作流，例如检查 PR 状态 并处理新的反馈
- 继续进行中的研究或分流聊天，而不丢失其上下文
当每次运行应独立，或 发现结果应作为单独运行显示在 Scheduled中时，请使用独立计划任务。
当你在聊天中安排任务时，请让提示词具备持久性。它应描述 什么 ChatGPT 应在每次计划运行中执行、如何判断是否有 重要内容需要报告，以及何时停止或请求你输入。
测试计划任务
Section titled “测试计划任务”安排任务前，请先在普通聊天中手动测试提示词 。这有助于你确认：
- 提示词清晰且范围正确。
- 所选或默认的模型、推理强度和工具按预期运行。
- 生成的输出便于评审。
开始安排运行后，请查看最初几次输出，并根据需要调整 提示词或频率。
在 ChatGPT 桌面应用中，你可以在计划
任务提示词中使用 $skill-name来显式触发技能。
计划任务的工作树清理
Section titled “计划任务的工作树清理”如果你为 Git 仓库选择工作树，频繁的计划可能会随着时间推移创建 许多工作树。归档不再需要的计划运行，并避免 固定运行，除非你确实打算保留它们的工作树。
权限和安全模型
Section titled “权限和安全模型”计划任务会无人值守运行，并使用你的默认沙箱设置。
有关这些边界的通俗解释，请参阅 沙箱概览。有关文件系统和网络 规则，请参阅 权限。
- 如果你的沙箱模式是 read-only，则当工具调用需要 修改文件、访问网络或使用你电脑上的应用时，会失败。 请考虑将沙箱设置更新为 workspace-write。
- 如果你的沙箱模式是 workspace-write，则当工具调用需要 修改工作区之外的文件、访问网络或使用你电脑上的应用 时，会失败。你可以选择性地将命令加入允许列表，让它们在 沙箱之外运行，方法是使用 规则。
- 如果你的沙箱模式是 full access，后台计划任务会带来 更高风险，因为 ChatGPT 可能会更改文件、运行命令并访问网络 且不会询问。请考虑将沙箱设置更新为 workspace-write，并 使用 规则 选择性定义 Agent 可以使用 full access 运行哪些命令。
如果你处于托管环境中，管理员可以使用
管理员强制要求来限制这些行为。例如，他们可以禁止 approval_policy = "never" 或限制允许的沙箱模式。请参阅
管理员强制要求（requirements.toml）。
计划任务会使用 approval_policy = "never" ，当你的组织策略
允许时。如果管理员要求禁止 approval_policy = "never"，
计划任务会回退到你所选权限
模式的审批行为。
自动创建新技能
Section titled “自动创建新技能”Scan all of the `~/.codex/sessions` files from the past day and if there have been any issues using particular skills, update the skills to be more helpful. Personal skills only, no repo skills.
If there’s anything we’ve been doing often and struggle with that we should save as a skill to speed up future work, let’s do it.
Definitely don't feel like you need to update any- only if there's a good reason!
Let me know if you make any.及时了解你的项目
Section titled “及时了解你的项目”Look at the latest remote origin/master or origin/main . Then produce an exec briefing for the last 24 hours of commits that touch
Formatting + structure:
- Use rich Markdown (H1 workstream sections, italics for the subtitle, horizontal rules as needed).- Preamble can read something like “Here’s the last 24h brief for <directory>:”- Subtitle should read: “Narrative walkthrough with owners; grouped by workstream.”- Group by workstream rather than listing each commit. Workstream titles should be H1.- Write a short narrative per workstream that explains the changes in plain language.- Use bullet points and bolding when it makes things more readable- Feel free to make bullets per person, but bold their name
Content requirements:
- Include PR links inline (e.g., [#123](...)) without a “PRs:” label.- Do NOT include commit hashes or a “Key commits” section.- It’s fine if multiple PRs appear under one workstream, but avoid per‑commit bullet lists.
Scope rules:
- Only include changes within the current cwd (or main checkout equivalent)- Only include the last 24h of commits.- Use `gh` to fetch PR titles and descriptions if it helps. Also feel free to pull PR reviews and comments将计划任务与技能结合，修复你自己的错误
Section titled “将计划任务与技能结合，修复你自己的错误”创建一个新技能，尝试通过创建新的 $recent-code-bugfix 并 将其存储在你的个人技能中，来修复你自己的提交引入的错误。
---name: recent-code-bugfixdescription: Find and fix a bug introduced by the current author within the last week in the current working directory. Use when a user wants a proactive bugfix from their recent changes, when the prompt is empty, or when asked to triage/fix issues caused by their recent commits. Root cause must map directly to the author’s own changes.---
# Recent Code Bugfix
## Overview
Find a bug introduced by the current author in the last week, implement a fix, and verify it when possible. Operate in the current working directory, assume the code is local, and ensure the root cause is tied directly to the author’s own edits.
## Workflow
### 1) Establish the recent-change scope
Use Git to identify the author and changed files from the last week.
- Determine the author from `git config user.name`/`user.email`. If unavailable, use the current user’s name from the environment or ask once.- Use `git log --since=1.week --author=<author>` to list recent commits and files. Focus on files touched by those commits.- If the user’s prompt is empty, proceed directly with this default scope.
### 2) Find a concrete failure tied to recent changes
Prioritize defects that are directly attributable to the author’s edits.
- Look for recent failures (tests, lint, runtime errors) if logs or CI outputs are available locally.- If no failures are provided, run the smallest relevant verification (single test, file-level lint, or targeted repro) that touches the edited files.- Confirm the root cause is directly connected to the author’s changes, not unrelated legacy issues. If only unrelated failures are found, stop and report that no qualifying bug was detected.
### 3) Implement the fix
Make a minimal fix that aligns with project conventions.
- Update only the files needed to resolve the issue.- Avoid adding extra defensive checks or unrelated refactors.- Keep changes consistent with local style and tests.
### 4) Verify
Attempt verification when possible.
- Prefer the smallest validation step (targeted test, focused lint, or direct repro command).- If verification cannot be run, state what would be run and why it wasn’t executed.
### 5) Report
Summarize the root cause, the fix, and the verification performed. Make it explicit how the root cause ties to the author’s recent changes.之后，创建一个新的计划任务：
Check my commits from the last 24h and submit a $recent-code-bugfix.