你可以把重复性任务交给自动化任务在后台执行。Codex 会把有发现的结果放进收件箱；如果没有可汇报的内容，则会自动归档这次任务。你也可以把自动化任务与 技能 结合，完成更复杂的流程。
自动化任务在 Codex App 后台运行。运行期间应用必须保持开启，并且所选项目必须能在本地磁盘上访问到。
在 Git 仓库里，你可以选择自动化任务运行在当前本地项目，还是运行在新的 工作树 中。两种方式都会在后台执行。工作树能把自动化任务生成的改动与当前未完成的本地工作隔离开，而直接运行在本地项目时，则可能修改你正在编辑的文件。对于未启用版本控制的项目，自动化任务会直接在项目目录中运行。
你也可以保留默认的模型和推理强度设置；如果想更精细地控制自动化行为，也可以显式指定它们。
管理任务
所有自动化任务及其运行记录都可以在 Codex App 侧边栏的“自动化任务”面板中找到。
其中 “Triage” 区域相当于你的收件箱。有发现结果的自动化任务运行会显示在这里，你也可以按“全部运行记录”或“仅未读”来过滤。
对于 Git 仓库，每个自动化任务都可以选择运行在本地项目，或者运行在独立的后台 工作树 中。如果你想把自动化任务改动和手头未完成的本地工作隔离开，请使用工作树；如果你希望自动化任务直接作用于主检出目录，则使用本地模式，但要注意它可能会改动你正在编辑的文件。对未受版本控制的项目，自动化任务会直接运行在项目目录中。你也可以把同一个自动化任务配置到多个项目上。
自动化任务使用你的默认沙箱设置。在只读模式下，凡是需要修改文件、访问网络或操作电脑上应用的工具调用都会失败。启用完全访问后，后台自动化任务的风险会明显升高。你可以在 设置 中调整沙箱设置，并通过 规则 选择性地放行命令。
为了让自动化任务更易维护、也更便于团队共享，你可以使用 技能 来封装动作、工具和上下文。你还可以在自动化任务提示词中通过 $skill-name 显式调用某个技能。
安全地测试自动化任务
在给自动化任务设置定时之前，先把提示词放到普通线程里手动跑一遍。这能帮助你先确认：
- 提示词是否清晰，范围是否划得准确
- 你选择的模型、默认模型、推理强度和工具行为是否符合预期
- 最终产出的 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.持续跟进你的项目变化
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，并存到个人技能目录。
---
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) 汇报
总结根因、修复内容和验证结果，并明确说明根因如何与作者近期改动直接相关。然后再新建一个自动化任务：
Check my commits from the last 24h and submit a $recent-code-bugfix.