计划任务
安排周期性任务在后台运行。在 Scheduled 中查看活跃、已暂停和已完成的任务及最近的运行记录。你可以将计划任务与技能结合，用于处理更复杂的工作。
在 ChatGPT 桌面应用中，计划任务可以使用本地项目，并在项目目录或隔离的工作树中运行。当计划任务需要本地文件时，请保持电脑开机并让应用保持运行。
例如，安排一个任务来评估遥测错误并提交修复，或创建有关近期代码库更改的报告。对于需要持续使用相同上下文的工作，可以在现有聊天中安排任务。
对于项目范围的计划任务，请保持电脑开机并让 ChatGPT 桌面应用保持运行。计划任务运行时，所选项目必须仍可在磁盘上访问。
在 Git 仓库中，你可以选择让计划任务在本地项目中运行，或在新的工作树中运行。两种方式都会在后台运行。工作树可以将计划任务的更改与未完成的本地工作分离；而在本地项目中运行可能会修改你仍在处理的文件。在非版本控制项目中，计划任务会直接在项目目录中运行。
你也可以保留模型和推理工作量的默认设置，或者根据需要明确选择它们，以便更好地控制计划任务的运行方式。
插图：ChatGPT 编写器已准备好创建计划任务，并已选择 5.6 Sol Extended。
计划任务会使用默认的沙箱设置，在无人值守的情况下运行。请从能让任务成功完成的最小访问权限开始，仅在必要时授予网络访问权限或更广泛的文件访问权限。了解沙箱。
管理计划任务
Section titled “管理计划任务”在 ChatGPT 桌面应用侧边栏的 Scheduled 中查找所有计划任务及其运行记录。
Scheduled 视图充当你的收件箱。包含发现结果的计划任务运行记录会显示在那里，未读指示器会在某次运行需要你关注时显示。
插图：计划任务页面，包含 All、Active 和 Paused 筛选条件及三个计划任务。
独立计划任务会为每次运行启动新的聊天，并在 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 在部署完成期间安排一次来自当前聊天的后续任务，或请求它创建一个按周期检查项目的独立计划任务。
技能也可以创建或更新计划任务。例如，用于跟进拉取请求的技能可以设置一个计划任务，通过 GitHub 插件检查 PR 状态并修复新的审查反馈。
在聊天中安排任务
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，并使用规则选择性地定义代理在完全访问权限下可以运行的命令。
如果你处于受管环境中，管理员可以使用管理员强制要求限制这些行为。例如，他们可以禁止 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## OverviewFind 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 scopeUse Git to identify the author and changed files from the last week.
- Determine the author from `git config user.name`/`git config 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 changesPrioritize 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 fixMake 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) VerifyAttempt 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) ReportSummarize 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.