定時任務

把重複性任務安排在後臺執行。你可以在 Scheduled（定時任務） 中檢視活躍、已暫停和已完成的任務及其最近執行記錄，也可以把定時任務與 skills 組合起來處理更復雜的工作。

ChatGPT 桌面 App

在 ChatGPT 桌面 App 中，定時任務可以使用本機專案，並在專案目錄或隔離的工作樹中執行。如果任務需要本機檔案，請保持電腦開機並讓 App 持續執行。

ChatGPT Web

如果工作區已啟用定時任務，可以從 Web 端 Chat 或 ChatGPT Work 建立任務，並在 Scheduled（定時任務） 中管理執行記錄。Web 任務可以使用上傳的上下文和連線工具，但不能直接操作你電腦上的資料夾。

Codex CLI

Codex CLI 不提供 Scheduled 管理介面。請在 ChatGPT Web 或桌面 App 中建立和管理定時任務；CLI 可以幫助你先準備並測試提示詞、skill 或指令碼。

IDE 擴充套件

IDE 擴充套件不提供 Scheduled 管理介面。請在 ChatGPT Web 或桌面 App 中建立和管理定時任務；IDE 擴充套件可以幫助你先準備並測試提示詞、skill 或工作區改動。

在 Web 端管理定時任務

開啟 Scheduled（定時任務），可以檢視任務狀態和最近執行記錄。每次執行都應從已儲存提示詞開始時，使用獨立定時任務；希望 ChatGPT 回到同一個聊天並沿用已有上下文時，則在聊天中安排任務。

Web 端定時任務可以使用該聊天可用的上傳檔案、連線工具、skills 和 plugins，但不會在多次執行之間持續保留本機資料夾或工作樹。請把需要長期複用的指令寫入任務提示詞或附帶的 skill，並把必要的源材料放在可存取的專案、上傳檔案或連線服務中。

設定計劃前，先在普通 Web 聊天中測試提示詞。檢查最初幾次執行；如果結果範圍過寬或缺少上下文，再調整提示詞、工具或執行節奏。

ChatGPT 桌面 App

例如，可以安排任務分析 telemetry 錯誤並提交修復，或生成最近程式碼庫改動報告。對於應持續複用同一上下文的工作，請在現有聊天中安排任務。

專案級定時任務執行時，機器必須開機、ChatGPT 桌面 App 必須正在執行，並且所選專案仍可在磁碟上存取。

在 Git 儲存庫中，可以選擇讓定時任務在本機專案或新的工作樹中執行。兩種方式都會在後臺執行：工作樹可以把定時任務產生的改動與未完成的本機工作隔離；本機模式則可能修改你正在編輯的檔案。未使用版本控制的專案會直接在專案目錄中執行。

你可以沿用預設模型和推理強度，也可以顯式選擇，以便更精確地控制任務執行方式。

如果定時任務在使用 ChatGPT 登入時選用了 gpt-5.4 或 gpt-5.4-mini，請在這兩個模型於 2026 年 8 月 31 日退役前完成更新：將 gpt-5.4 替換為 gpt-5.6-terra，並將 gpt-5.4-mini 替換為 gpt-5.6-luna。

定時任務會在無人值守狀態下使用預設沙箱設定。請從能夠完成任務的最小存取權限開始，只有確有需要時才授予網路或更廣泛的檔案存取。參閱沙箱概覽。

管理定時任務

在 ChatGPT 桌面應用側邊欄的 Scheduled 中，可以找到所有定時任務及其執行記錄。

Scheduled 檢視也充當收件箱：產生髮現結果的執行會出現在這裡；有執行需要關注時，會顯示未讀標記。

獨立定時任務每次執行都會新建一個聊天，並把結果彙報到 Scheduled。當每次執行應彼此獨立，或同一項定時任務需要跨一個或多個專案執行時，請使用這種方式。需要自定義節奏時，可編輯 RFC 5545 recurrence rule（RRULE），例如 RRULE:FREQ=MONTHLY;BYMONTHDAY=1;BYHOUR=9;BYMINUTE=0。

對於 Git 儲存庫，每項定時任務都可以在本機專案或專用後臺工作樹中執行。希望隔離改動時使用工作樹；希望任務直接作用於主檢出目錄時使用本機模式，但要注意它可能修改正在編輯的檔案。未受版本控制的專案會直接使用專案目錄。同一項定時任務可以設定到多個專案上。

在 Web 端通過 ChatGPT Work 建立的定時任務，以及在桌面 App 中通過 ChatGPT Work 或 Codex 建立的定時任務，都可以使用 plugins；定時任務也可以使用 skills。為了讓流程更易維護和在團隊內共享，請用 skills 定義動作、工具和上下文。當工作流程不應依賴自動工具選擇時，在任務提示詞中明確選擇或呼叫 skill。

讓 ChatGPT 建立或更新定時任務

你可以在 ChatGPT 或 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.