自动化任务

在后台自动执行定期任务。Codex 会将结果发送到收件箱，如果没有需要报告的内容则自动归档任务。你可以将自动化与技能（skills）结合使用，以处理更复杂的任务。

对于项目范围的自动化，在计划运行该自动化时，运行本地 Codex 应用程序的机器必须处于开机状态，Codex 必须正在运行，且所选项目在磁盘上仍必须可用。

在 Git 仓库中，你可以选择自动化是在本地项目中运行，还是在新的 worktree 上运行。两种方式都在后台运行。Worktree 可以将自动化产生的更改与尚未完成的本地工作隔离开来，而在本地项目中运行则可能修改你仍在编辑的文件。在不受版本控制的项目中，自动化直接在项目目录中运行。

你也可以保留模型和推理强度的默认设置，或者在需要更精细控制自动化运行方式时显式选择它们。

管理任务

在 Codex 应用侧边栏的自动化面板中查看所有自动化及其运行记录。

「待处理」（Triage）区域充当你的收件箱。有结果的自动化运行会显示在此处，你可以筛选收件箱以显示所有自动化运行或仅显示未读的运行。

独立自动化 按计划启动全新运行，并将结果报告到待处理区。适用于每次运行应相互独立的场景，或者一个自动化需要在多个项目上运行的情况。如果需要自定义频率，可以选择自定义计划并输入 cron 表达式。

对于 Git 仓库，每个自动化可以在本地项目或专用的后台 worktree 上运行。当你希望将自动化产生的更改与未完成的本地工作隔离时，使用 worktree。当你希望自动化直接在主检出版本中工作时使用本地模式，但请注意它可能会修改你正在编辑的文件。在不受版本控制的项目中，自动化直接在项目目录中运行。你可以让同一个自动化在多个项目上运行。

自动化使用你的默认沙箱设置。在只读模式下，任何需要修改文件、访问网络或与计算机上的应用程序交互的工具调用都会失败。启用完全访问权限后，后台自动化会带来更高的风险。你可以在「设置」中调整沙箱设置，并通过「规则」有选择地将命令加入允许列表。

自动化可以使用 Codex 可用的所有插件和技能。为了保持自动化的可维护性和团队间的可共享性，建议使用技能来定义操作并提供工具和上下文。你可以在自动化中使用 $skill-name 来显式触发某个技能。

让 Codex 创建或更新自动化

你可以在普通的 Codex 对话中创建和更新自动化。描述任务、计划以及自动化是应保持附加到当前对话还是启动全新运行。Codex 可以草拟自动化提示词、选择合适的自动化类型，并在范围或频率发生变化时进行更新。

例如，你可以让 Codex 在部署完成期间在当前对话中提醒你，或者让它创建一个独立自动化，按定期计划检查某个项目。

技能也可以创建或更新自动化。例如，一个用于跟进拉取请求的技能可以设置一个定期自动化，通过 GitHub 插件检查 PR 状态并修复新的审查反馈。

对话自动化

对话自动化（Thread automations）是附加到当前对话的心跳式定期唤醒调用。适用于你希望 Codex 按计划持续回到同一对话的场景。

当计划执行的工作需要保留对话上下文而非每次都从新提示词开始时，使用对话自动化。

对话自动化可以使用分钟级别的间隔进行主动跟进循环，也可以使用每日或每周计划在特定时间进行检查。

对话自动化适用于：

• 检查长时间运行的命令直到完成
• 轮询 Slack、GitHub 或其他已连接的数据源，并将结果保留在同一对话中
• 提醒 Codex 按固定节奏继续审查循环
• 运行使用插件的技能驱动工作流，例如检查 PR 状态并处理新反馈
• 将对话聚焦于持续的研究或分类任务

当每次运行应相互独立、需要在多个项目上运行，或者结果应作为独立的自动化运行显示在待处理区时，应使用独立自动化或项目自动化。

创建对话自动化时，提示词需要具备持久性。它应描述 Codex 每次唤醒时应做什么、如何判断是否有重要事项需要报告，以及何时停止或请求你的输入。

测试自动化

在安排自动化之前，先在普通对话中手动测试提示词。这有助于确认：

• 提示词清晰且范围正确
• 所选或默认的模型、推理强度和工具行为符合预期
• 生成的 diff 可供审查

开始安排运行后，审查前几次输出，并根据需要调整提示词或频率。

自动化的 Worktree 清理

如果你为 Git 仓库选择了 worktree，频繁的计划可能会随时间积累大量 worktree。归档不再需要的自动化运行，并避免固定运行，除非你打算保留其对应的 worktree。

权限与安全模型

自动化在无人值守下运行，并使用你的默认沙箱设置。

• 如果沙箱模式为只读，任何需要修改文件、访问网络或与计算机上的应用程序交互的工具调用都会失败。建议将沙箱设置更新为工作区写入。
• 如果沙箱模式为工作区写入，任何需要修改工作区外的文件、访问网络或与计算机上的应用程序交互的工具调用都会失败。你可以通过规则有选择地将命令加入允许列表，使其在沙箱外运行。
• 如果沙箱模式为完全访问，后台自动化会带来较高风险，因为 Codex 可能会在未经询问的情况下修改文件、运行命令并访问网络。建议将沙箱设置更新为工作区写入，并使用规则有选择地定义代理可以以完全访问权限运行的命令。

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

当组织策略允许时，自动化使用 approval_policy = "never"。如果管理员要求禁止 approval_policy = "never"，自动化将回退到所选模式的审批行为。

示例

自动创建新技能

扫描过去一天中所有 `~/.codex/sessions` 文件，如果使用某些技能时出现了问题，则更新这些技能使其更有帮助。仅限个人技能，不包括仓库技能。

如果我们经常做并且遇到困难的事情，应该将其保存为技能以加速未来的工作。

只有有充分理由时才更新，不必强制。

如果做了任何更改，请告诉我。

了解项目最新动态

查看远程 origin/master 或 origin/main 的最新状态。然后为过去 24 小时内涉及 `<DIRECTORY>` 的提交生成一份执行简报。

格式与结构：

- 使用丰富的 Markdown（H1 工作流标题、斜体字幕、适当使用水平分割线）
- 前言可写为："以下是 `<directory>` 的 24 小时简报："
- 字幕应写为："按工作流分组的叙述性概述，标注负责人。"
- 按工作流分组而非逐一列出每个提交。工作流标题应为 H1。
- 为每个工作流撰写简短叙述，用通俗语言解释变更。
- 使用项目符号和加粗以提高可读性
- 可以按人员创建项目符号，但需将其姓名加粗

内容要求：

- 在正文中附带 PR 链接（例如 `[#123](...)`），不加 "PRs:" 标签
- 不要包含提交哈希或「关键提交」部分
- 一个工作流下可以有多个 PR，但避免按提交逐条列举

范围规则：

- 仅包含当前工作目录（或等效的主检出版本）内的更改
- 仅包含过去 24 小时的提交
- 如有帮助，可使用 `gh` 获取 PR 标题和描述，也可拉取 PR 审查和评论

结合自动化与技能修复自己的 Bug

创建一个新技能，用于尝试修复由你自己的提交引入的 Bug，创建 $recent-code-bugfix 并将其存储在你的个人技能中。

---
name: recent-code-bugfix
description: 在当前工作目录中，查找并修复当前作者在过去一周内引入的 Bug。当用户希望主动修复其近期更改中产生的 Bug、提示词为空或被要求排查/修复其近期提交导致的问题时使用。根本原因必须直接映射到作者自己的更改。
---

# Recent Code Bugfix

## 概述

查找当前作者在过去一周内引入的 Bug，实施修复并在可能时进行验证。在当前工作目录中操作，假设代码是本地可用的，并确保根本原因直接与作者自己的编辑相关。

## 工作流程

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

使用 Git 识别过去一周的作者和更改的文件。

- 通过 `git config user.name`/`user.email` 确定作者。如果不可用，使用环境中的当前用户名或询问一次。
- 使用 `git log --since=1.week --author=<author>` 列出近期的提交和文件。聚焦于这些提交涉及的文件。
- 如果用户提示词为空，直接使用此默认范围继续。

### 2) 找到与近期更改相关的具体失败

优先处理可直接归因于作者编辑的缺陷。

- 如果本地有可用的日志或 CI 输出，查找近期的失败（测试、lint、运行时错误）。
- 如果没有提供失败信息，运行涉及已编辑文件的最小验证（单个测试、文件级 lint 或针对性的复现）。
- 确认根本原因直接与作者的更改相关，而非无关的遗留问题。如果只发现无关的失败，停止并报告未检测到符合条件的 Bug。

### 3) 实施修复

进行符合项目约定的最小修复。

- 仅更新解决问题所需的文件。
- 避免添加额外的防御性检查或不相关的重构。
- 保持更改与本地风格和测试一致。

### 4) 验证

在可能时尝试验证。

- 优先使用最小的验证步骤（针对性测试、聚焦的 lint 或直接复现命令）。
- 如果无法运行验证，说明将运行什么以及未执行的原因。

### 5) 报告

总结根本原因、修复措施和执行的验证。明确说明根本原因如何与作者的近期更改相关联。

之后，创建一个新的自动化：

检查我过去 24 小时的提交并提交一个 `$recent-code-bugfix`。