定时任务

把重复性任务安排在后台运行。你可以在 Scheduled（定时任务） 中查看活跃、已暂停和已完成的任务及其最近运行记录，也可以把定时任务与 skills 组合起来处理更复杂的工作。

在 ChatGPT 桌面应用中，定时任务可以使用本地项目，并在项目目录或隔离的工作树中运行。如果任务需要本地文件，请保持电脑开机并让应用持续运行。

例如，可以安排任务分析 telemetry 错误并提交修复，或生成最近代码库改动报告。对于应持续复用同一上下文的工作，请从现有任务安排后续工作。

项目级定时任务运行时，机器必须开机、ChatGPT 桌面应用必须正在运行，并且所选项目仍可在磁盘上访问。

在 Git 仓库中，可以选择让定时任务在本地项目或新的工作树中运行。两种方式都会在后台执行：工作树可以把定时任务产生的改动与未完成的本地工作隔离；本地模式则可能修改你正在编辑的文件。未使用版本控制的项目会直接在项目目录中运行。

你可以沿用默认模型和推理强度，也可以显式选择，以便更精确地控制任务运行方式。

定时任务会在无人值守状态下使用默认沙箱设置。请从能够完成任务的最小访问权限开始，只有确有需要时才授予网络或更广泛的文件访问。参阅沙箱概览。

管理定时任务

在 ChatGPT 桌面应用侧边栏的 Scheduled 中，可以找到所有定时任务及其运行记录。

Scheduled 视图也充当收件箱：产生发现结果的运行会出现在这里；有运行需要关注时，会显示未读标记。

独立定时任务每次运行都会新建一个任务，并把结果汇报到 Scheduled。当每次运行应彼此独立，或同一项定时任务需要跨一个或多个项目执行时，请使用这种方式。需要自定义节奏时，可编辑 RFC 5545 recurrence rule（RRULE），例如 RRULE:FREQ=MONTHLY;BYMONTHDAY=1;BYHOUR=9;BYMINUTE=0。

对于 Git 仓库，每项定时任务都可以在本地项目或专用后台工作树中运行。希望隔离改动时使用工作树；希望任务直接作用于主检出目录时使用本地模式，但要注意它可能修改正在编辑的文件。未受版本控制的项目会直接使用项目目录。同一项定时任务可以配置到多个项目上。

ChatGPT Web 中的 ChatGPT Work，以及桌面应用中的 Work 或 Codex，可以让定时任务使用 plugins。定时任务也可以使用 skills。为了让流程更易维护和在团队内共享，请用 skills 定义动作、工具和上下文。当工作流不应依赖自动工具选择时，在任务提示词中明确选择或调用 skill。

让 ChatGPT 创建或更新定时任务

你可以在 ChatGPT 的 Work 或 Codex 任务中创建和更新定时任务。说明工作内容、计划，以及每次运行应回到当前任务还是新建任务。范围或执行节奏发生变化时，ChatGPT 可以起草提示词、选择合适目标并更新定时任务。

例如，可以让 ChatGPT 在部署结束后从当前任务安排一次跟进，也可以创建独立定时任务，按固定节奏检查项目。

Skills 也能创建或更新定时任务。例如，看守 pull request 的 skill 可以设置定时任务，通过 GitHub plugin 检查 PR 状态并修复新的评审反馈。

从任务安排工作

如果希望 ChatGPT 按计划回到现有任务，请从该任务安排工作。之后的运行会使用任务已有的上下文，而不是每次从新提示词开始。

任务中的定时工作可以使用按分钟计算的间隔完成高频跟进，也可以按天或按周在指定时间检查。

适合的场景包括：

• 检查长时间运行的操作，直到完成。
• 轮询 Slack、GitHub 或其他连接来源，并让结果留在同一任务中。
• 按固定节奏继续代码评审循环。
• 执行由 skill 驱动并使用 plugins 的工作流，例如检查 PR 状态并处理新反馈。
• 在不丢失上下文的前提下，继续研究或分诊任务。

如果每次运行都应独立，或发现结果应作为独立运行出现在 Scheduled 中，请使用独立定时任务。

从任务安排工作时，提示词应能够长期复用：说明 ChatGPT 每次运行要做什么、如何判断是否有重要内容需要汇报，以及何时停止或请求输入。

测试定时任务

设置计划前，先在普通任务中手动测试提示词，以确认：

• 提示词清晰且范围准确。
• 所选或默认模型、推理强度和工具的行为符合预期。
• 输出便于评审。

开始按计划运行后，应检查前几次输出，并根据结果调整提示词或执行节奏。

在 ChatGPT 桌面应用中，可以在定时任务提示词中使用 $skill-name 显式调用某项 skill。

定时任务的工作树清理

如果 Git 仓库中的定时任务使用工作树，频繁运行会随时间创建大量工作树。请归档不再需要的运行记录；除非确实要保留对应工作树，否则不要固定这些运行。

权限与安全模型

定时任务以无人值守方式运行，并使用默认沙箱设置。边界的通俗解释见沙箱概览，文件系统和网络规则见权限。

• read-only：需要修改文件、访问网络或操作电脑应用的工具调用会失败。需要实际写入时，可考虑改为 workspace-write。
• workspace-write：允许在工作区内写入；需要修改工作区外文件、访问网络或操作电脑应用的调用仍会失败。可以通过规则选择性允许命令在沙箱外运行。
• Full access（完全访问）：后台任务可以在不询问的情况下修改文件、运行命令和访问网络，风险更高。通常应优先使用 workspace-write，再通过规则精确授予命令完全访问权限。

在受管理环境中，管理员可以通过强制要求限制这些行为，例如禁止 approval_policy = "never"，或限制允许使用的沙箱模式。参阅管理员强制要求（requirements.toml）。

组织策略允许时，定时任务使用 approval_policy = "never"。如果管理员要求禁止该值，定时任务会回退到所选权限模式对应的审批行为。

示例

自动创建新 skills

下面的提示词会检查过去一天的个人会话，只在确有必要时改进个人 skills：

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.

持续跟进项目变化

下面的提示词生成过去 24 小时内指定目录的项目简报：

Look at the latest remote origin/master or origin/main . Then produce an exec briefing for the last 24 hours of commits that touch <DIRECTORY>

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

组合定时任务和 skills，修复自己引入的问题

创建一个 $recent-code-bugfix skill，用于查找并修复当前作者在最近一周引入的问题，并把它保存到个人 skills。

---
name: recent-code-bugfix
description: 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.