自动化任务

你可以把重复性任务交给自动化任务在后台执行。Codex 会把有发现的结果放进收件箱；如果没有可汇报的内容，则会自动归档这次任务。你也可以把自动化任务与 技能 结合，完成更复杂的流程。

对于项目级自动化任务，Codex App 必须保持运行，并且所选项目必须能在本地磁盘上访问到。

在 Git 仓库里，你可以选择自动化任务运行在当前本地项目，还是运行在新的 工作树 中。两种方式都会在后台执行。工作树能把自动化任务生成的改动与当前未完成的本地工作隔离开，而直接运行在本地项目时，则可能修改你正在编辑的文件。对于未启用版本控制的项目，自动化任务会直接在项目目录中运行。

你也可以保留默认的模型和推理强度设置；如果想更精细地控制自动化行为，也可以显式指定它们。

管理任务

所有自动化任务及其运行记录都可以在 Codex App 侧边栏的“自动化任务”面板中找到。

其中 “Triage” 区域相当于你的收件箱。有发现结果的自动化任务运行会显示在这里，你也可以按“全部运行记录”或“仅未读”来过滤。

独立自动化任务会按计划启动全新的运行，并把结果汇报到 Triage。当每次运行都应彼此独立，或一个自动化任务需要跨一个或多个项目运行时，使用独立自动化任务。如果需要自定义节奏，请选择自定义计划并输入 cron 语法。

对于 Git 仓库，每个自动化任务都可以选择运行在本地项目，或者运行在独立的后台 工作树 中。如果你想把自动化任务改动和手头未完成的本地工作隔离开，请使用工作树；如果你希望自动化任务直接作用于主检出目录，则使用本地模式，但要注意它可能会改动你正在编辑的文件。对未受版本控制的项目，自动化任务会直接运行在项目目录中。你也可以把同一个自动化任务配置到多个项目上。

自动化任务使用你的默认沙箱设置。在只读模式下，凡是需要修改文件、访问网络或操作电脑上应用的工具调用都会失败。启用完全访问后，后台自动化任务的风险会明显升高。你可以在 设置 中调整沙箱设置，并通过 规则 选择性地放行命令。

自动化任务可以使用 Codex 可用的同一套插件和技能。为了让自动化任务更易维护、也更便于团队共享，请使用 技能 来定义动作，并提供工具和上下文。你还可以在自动化任务提示词中通过 $skill-name 显式调用某个技能。

让 Codex 创建或更新自动化任务

你可以从普通 Codex 线程中创建和更新自动化任务。描述任务、计划，以及该自动化任务应该继续附着在当前线程上，还是启动全新的运行。Codex 可以起草自动化提示词，选择合适的自动化类型，并在范围或节奏变化时更新它。

例如，你可以要求 Codex 在这个线程中提醒你部署完成，或要求它创建一个独立自动化任务，按固定计划检查某个项目。

技能也可以创建或更新自动化任务。例如，一个用于看守 pull request 的技能，可以设置一个重复自动化任务，使用 GitHub 插件检查 PR 状态，并修复新的评审反馈。

线程自动化

线程自动化是附着在当前线程上的 heartbeat 式重复唤醒。使用它们，可以让 Codex 按计划持续回到同一段对话。

当计划任务需要保留线程上下文，而不是每次都从新提示词开始时，请使用线程自动化。

线程自动化可以使用按分钟计算的间隔来做活跃跟进循环，也可以使用每日或每周计划，在特定时间进行检查。

线程自动化适合：

• 持续检查一个长时间运行的命令，直到它完成。
• 轮询 Slack、GitHub 或其它连接来源，并且希望结果留在同一线程中。
• 提醒 Codex 按固定节奏继续评审循环。
• 运行由技能驱动、并使用插件的工作流，例如检查 PR 状态并处理新的反馈。
• 让一个聊天持续聚焦在进行中的研究或分诊任务上。

当每次运行都应独立、需要跨多个项目运行，或发现结果应作为独立自动化运行出现在 Triage 中时，请使用独立或项目自动化任务。

创建线程自动化时，请让提示词足够持久。它应该描述 Codex 每次被唤醒时要做什么、如何判断是否有值得汇报的重要内容，以及什么时候停止或向你请求输入。

测试自动化任务

在给自动化任务设置定时之前，先把提示词放到普通线程里手动跑一遍。这能帮助你先确认：

• 提示词是否清晰，范围是否划得准确
• 你选择的模型、默认模型、推理强度和工具行为是否符合预期
• 最终产出的 diff 是否便于评审

开始定时运行后，请审查前几次输出，并根据结果继续调整提示词或执行频率。

自动化任务的工作树清理

如果你在 Git 仓库中选择使用工作树，频繁触发的自动化任务会随着时间推移创建大量工作树。请及时归档那些已经不需要的自动化任务运行记录，并避免固定你并不打算长期保留的运行记录。

权限与安全模型

自动化任务会以无人值守方式运行，并使用你的默认沙箱设置。

• read-only：如果工具调用需要修改文件、访问网络或与电脑上的应用交互，就会失败。若想执行真正会落盘的自动化任务，通常应改用 workspace-write。
• workspace-write：允许在工作区内写入，但如果工具调用需要修改工作区外的文件、访问网络或与电脑上的应用交互，仍然会失败。你可以通过 规则 选择性地放行沙箱外命令。
• full access：风险最高。Codex 可以在无需询问的情况下改文件、运行命令并访问网络。通常更推荐优先使用 workspace-write，再配合 规则 精确定义哪些命令可以拿到完全访问权限。

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

当组织策略允许时，自动化任务会使用 approval_policy = "never"。如果管理员要求不允许 approval_policy = "never"，那么自动化任务会回退到你所选模式对应的审批行为。

示例

自动创建新技能

这个示例适合每天检查个人技能是否需要更新：它会扫描最近一天的会话记录，只在确有必要时改进个人技能。

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](https://github.com/org/repo/pull/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

把自动化任务和技能组合起来，修复自己最近引入的问题

创建一个新技能，用于尝试修复由你自己近期提交引入的问题。可以把它保存为 $recent-code-bugfix，并存到个人技能目录。

下面保留英文 frontmatter，方便直接复制为技能文件；正文部分说明了如何限定近期改动、找出直接相关故障、实施最小修复并完成验证。

---
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

## 概览

找出当前作者在过去一周内引入的一个问题，实施修复，并在可能时完成验证。在当前工作目录内操作，默认代码就在本地，并确保根因能够直接对应到作者自己的改动。

## 工作流

### 1) 确定近期改动范围

使用 Git 确认作者身份，并找出过去一周里改动过的文件。

- 通过 `git config user.name` / `user.email` 确定作者。如果拿不到，就使用环境中的当前用户名，或仅在必要时询问一次。
- 使用 `git log --since=1.week --author=<author>` 列出近期提交和涉及的文件，重点关注这些提交改动过的文件。
- 如果用户的提示词为空，就直接采用这个默认范围继续。

### 2) 找出与近期改动直接相关的具体故障

优先处理那些能够直接归因到作者改动的问题。

- 如果本地能拿到日志或 CI 输出，就优先查找最近的失败项，例如测试失败、lint 报错或运行时错误。
- 如果没有提供失败信息，就运行最小且相关的验证步骤，例如单个测试、文件级 lint 或针对性复现命令，并确保它触及近期编辑过的文件。
- 确认根因必须直接关联到作者的改动，而不是无关的历史遗留问题。如果只能找到无关问题，就停止并报告没有发现符合条件的问题。

### 3) 实施修复

做一个符合项目约定的最小修复。

- 只更新解决问题所必需的文件。
- 不要额外加入防御性检查或无关重构。
- 保持改动与本地风格和测试习惯一致。

### 4) 验证

在可能时尝试完成验证。

- 优先选择最小的验证步骤，例如针对性测试、聚焦的 lint，或直接复现命令。
- 如果无法运行验证，说明原本会运行什么，以及为什么这次没有执行。

### 5) 汇报

总结根因、修复内容和验证结果，并明确说明根因如何与作者近期改动直接相关。

然后再新建一个自动化任务。下面这条提示词会检查最近 24 小时的提交，并提交一次 $recent-code-bugfix 运行：

Check my commits from the last 24h and submit a $recent-code-bugfix.