在后台自动化处理重复任务。Codex 会将调查结果添加到收件箱，如果没有报告内容，则会自动归档任务。您可以将自动化与技能 (Skills) 结合使用，以处理更复杂的任务。
对于项目范围内的自动化，应用必须处于运行状态，且选定项目必须在磁盘上可用。
在 Git 仓库中，您可以选择自动化是在本地项目运行，还是在新的 工作树 (Worktree) 中运行。这两种选项都在后台运行。工作树将自动化产生的更改与未完成的本地工作隔离开，而在本地项目中运行则可能会修改您正在处理的文件。在非版本控制的项目中，自动化直接在项目目录中运行。
您也可以将模型和推理能力的设置保持在默认状态，或者在想要进一步控制自动化运行方式时显式地进行选择。
管理任务
您可以在 Codex 应用侧边栏的“自动化 (Automations)”面板中找到所有自动化任务及其运行情况。
“分类 (Triage)”部分相当于您的收件箱。有调查结果的自动化运行会显示在这里，您可以过滤收件箱，以仅查看所有运行记录或仅查看未读的运行记录。
独立自动化按计划启动新的运行并在“分类”中报告结果。当每次运行都应保持独立，或当某项自动化需要在多个项目中运行时，请使用此方式。如果您需要自定义节奏，请选择自定义计划并输入 cron 表达式。
对于 Git 仓库，每项自动化既可以在本地项目运行，也可以在专用的后台 工作树 中运行。当您希望将自动化产生的更改与未完成的本地工作隔离开时，请使用工作树。当您希望自动化直接在主检出 (main checkout) 中工作时，请使用本地模式，请注意这可能会改变您正在编辑的文件。在非版本控制的项目中，自动化直接在项目目录中运行。您可以让同一项自动化在多个项目上运行。
自动化使用您的默认沙盒设置。在只读模式下，如果工具调用需要修改文件、访问网络或操作计算机上的应用，则会失败。在启用完全访问权限的情况下，后台自动化具有更高的风险。您可以在设置 (Settings) 中调整沙盒设置，并通过规则 (Rules) 选择性地将命令加入白名单。
自动化可以使用 Codex 可用的插件和技能。为了使自动化在团队间易于维护和共享，请使用技能来定义操作并提供工具与上下文。您可以在自动化内部使用 $skill-name 来显式触发技能。
要求 Codex 创建或更新自动化
您可以从普通的 Codex 对话中创建和更新自动化。描述任务、时间表，以及自动化应保持附加在当前对话中还是启动新的运行。Codex 可以起草自动化提示词 (prompt)、选择合适的自动化类型，并在范围或节奏发生变化时对其进行更新。
例如，要求 Codex 在部署完成时在此对话中提醒您，或者要求它创建一个按重复计划检查项目的独立自动化。
技能也可以创建或更新自动化。例如，一个用于监控拉取请求 (PR) 的技能可以设置一个重复性的自动化，利用 GitHub 插件检查 PR 状态并修复新的评审反馈。
对话自动化
对话自动化是附加在当前对话上的心跳式重复唤醒调用。当您希望 Codex 按计划持续回到同一个对话时，可以使用它。
当计划任务需要保留对话上下文而不是每次从新的提示词开始时，请使用对话自动化。
对话自动化可以使用基于分钟的间隔进行主动跟进循环，或者在您需要在特定时间进行检查时使用每日和每周计划。
对话自动化适用于：
- 检查长时间运行的命令直到其完成
- 当结果应留在同一对话中时，轮询 Slack、GitHub 或其他已连接的源
- 提醒 Codex 以固定频率继续评审循环
- 运行使用插件的基于技能的工作流，例如检查 PR 状态并处理新的反馈
- 保持聊天专注于正在进行的研究或分类任务
当每次运行都应独立、需要在多个项目上运行，或者调查结果应在“分类”中显示为单独的自动化运行时，请使用独立或项目自动化。
创建对话自动化时，请确保提示词具有持久性。它应该描述 Codex 每次唤醒时应该做什么、如何判断是否有重要内容需要报告，以及何时停止或向您寻求输入。
测试自动化
在安排自动化之前，先在普通对话中手动测试提示词。这有助于您确认：
- 提示词清晰且范围定义准确。
- 所选或默认的模型、推理能力和工具的行为符合预期。
- 产生的代码差异 (diff) 是可评审的。
当您开始安排运行后，请检查前几次输出，并根据需要调整提示词或频率。
自动化工作树清理
如果您为 Git 仓库选择了工作树，频繁的计划运行可能会随时间创建许多工作树。请归档您不再需要的自动化运行，并避免固定运行记录，除非您打算保留其对应的工作树。
权限和安全模型
自动化在无人值守的情况下运行，并使用您的默认沙盒设置。
- 如果您的沙盒模式为只读 (read-only)，则需要修改文件、访问网络或操作计算机上应用的工具调用将会失败。请考虑将沙盒设置更新为工作区写入 (workspace write)。
- 如果您的沙盒模式为工作区写入 (workspace-write)，则需要修改工作区外文件、访问网络或操作计算机上应用的工具调用将会失败。您可以使用规则选择性地将允许在沙盒外运行的命令加入白名单。
- 如果您的沙盒模式为完全访问 (full access)，则后台自动化风险较高，因为 Codex 可能会在不询问的情况下更改文件、运行命令并访问网络。请考虑将沙盒设置更新为工作区写入，并使用规则选择性地定义代理可以使用完全访问权限运行哪些命令。
如果您处于受管环境中，管理员可以使用强制要求限制这些行为。例如，他们可以禁止 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.保持与项目同步
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结合自动化与技能来修复您自己的 Bug
创建一个新技能，通过生成一个新的 $recent-code-bugfix 并将其存储在您的个人技能库中，来尝试修复您自己提交的代码中引入的错误。
---
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.