OpenAI Codex 的 automations 用来让重复任务在后台自动运行，适合定时检查项目、持续跟进长任务、或把结果发到 Triage 收件箱。项目级自动化要求 app 正在运行且项目已在磁盘上；Git 仓库可选择本地项目或新 worktree，非版本控制项目则直接在项目目录运行。

OpenAI Codex 自动化与定时任务 #

管理任务 #

你可以在 Codex app 侧边栏的 automations 面板里查看所有 automations 及其 runs。

Triage 区域相当于收件箱。带 findings 的 automation run 会出现在这里；你也可以筛选显示全部 automation run，或只看未读内容。

Standalone automations 会按计划启动新的 run，并把结果报告到 Triage。适合每次执行都应该彼此独立，或者一个 automation 要跨一个或多个项目运行的场景。如果需要自定义频率，可以选择 custom schedule 并填写 cron 语法。

对于 Git 仓库，每个 automation 可以运行在本地项目里，也可以运行在专用的后台 worktree。当你想把 automation 的改动和未完成的本地工作隔离开时，优先用 worktree；当你希望它直接作用于主 checkout 时，用本地模式，但要注意它可能修改你正在编辑的文件。在非版本控制项目中，automations 会直接在项目目录中运行。一个 automation 也可以在多个项目上运行。

Automations 会使用你的默认 sandbox 设置。只读模式下，如果工具调用需要修改文件、访问网络，或与电脑上的应用交互，就会失败。开启 full access 后，后台 automations 的风险会明显更高。你可以在 Settings 中调整 sandbox 设置，并通过 rules 有选择地放行命令。

Automations 可以使用 Codex 可用的相同 plugins 和 skills。为了让自动化更容易维护、也更容易在团队里共享，建议用 skills 定义动作本身，并提供工具和上下文。你也可以在 automation 中通过 $skill-name 显式触发某个 skill。

让 Codex 创建或更新 automations #

你可以直接在普通 Codex thread 里创建或更新 automation。只要描述任务、计划频率，以及这个 automation 是应该继续附着在当前 thread 上，还是每次都从新的 run 开始。Codex 可以帮你起草 automation prompt、选择合适的 automation 类型，并在范围或节奏变化时更新它。

例如，你可以让 Codex 在部署完成期间留在这个 thread 里提醒你；也可以让它创建一个独立 automation，按固定周期检查某个项目。

skills 也可以创建或更新 automations。比如，一个用于跟进 pull request 的 skill，可以设置一个 recurring automation，结合 GitHub plugin 检查 PR 状态，并处理新出现的 review feedback。

Thread automations #

Thread automations 是附着在当前 thread 上的心跳式定时唤醒。适合你希望 Codex 按计划回到同一段对话中继续处理的场景。

当计划中的工作需要保留 thread 的上下文，而不是每次都从新 prompt 开始时，应该使用 thread automation。

Thread automations 支持按分钟间隔执行，适合高频跟进循环；也支持每日和每周计划，适合在固定时间检查一次。

Thread automations 适合这些任务：

• 持续检查一个长时间运行的命令，直到它完成
• 轮询 Slack、GitHub，或其他已连接来源，并把结果保留在同一个 thread 里
• 提醒 Codex 按固定节奏继续 review 循环
• 运行基于 skill 的工作流，例如检查 PR 状态并处理新反馈
• 让一个 chat 保持聚焦在持续进行的 research 或 triage 任务上

如果每次 run 都应该彼此独立、需要跨多个项目运行，或者 findings 应该作为独立 automation run 出现在 Triage 中，就应使用 standalone automation 或 project automation。

创建 thread automation 时，prompt 要尽量写得耐久。它应该说明：每次 thread 被唤醒时 Codex 要做什么、如何判断有没有重要内容需要报告，以及什么时候停止或向你要输入。

怎么测试 automations #

在安排 automation 之前，先在普通 thread 里手动测试 prompt。这样可以确认：

• prompt 清楚，而且范围没有写偏
• 选定或默认的 model、reasoning effort 和 tools 行为符合预期
• 最终 diff 是可以 review 的

开始真正安排 runs 后，先检查前几个输出，再根据情况调整 prompt 或 cadence。

Automations 的 worktree 清理 #

如果在 Git 仓库里选择 worktree，频繁调度可能会随着时间创建很多 worktree。把不再需要的 automation runs 归档掉，并避免 pin run，除非你确实打算保留对应 worktree。

权限和安全模型 #

Automations 会无人值守运行，并使用你的默认 sandbox 设置。

• 如果 sandbox mode 是 read-only，当工具调用需要修改文件、访问网络，或与电脑上的应用交互时，会失败。可以考虑把 sandbox settings 改成 workspace write。
• 如果 sandbox mode 是 workspace-write，当工具调用需要修改 workspace 之外的文件、访问网络，或与电脑上的应用交互时，会失败。你可以通过 rules 有选择地把某些命令放到 sandbox 外运行。
• 如果 sandbox mode 是 full access，后台 automations 的风险会更高，因为 Codex 可能在不询问的情况下修改文件、运行命令并访问网络。可以考虑把 sandbox settings 改回 workspace write，并用 rules 选择性定义 agent 在 full access 下允许运行哪些命令。

如果你在 managed environment 里，管理员可以通过强制要求限制这些行为。例如，他们可以禁止 approval_policy = "never"，或限制允许的 sandbox modes。查看 Admin-enforced requirements (requirements.toml)。

当组织策略允许时，Automations 会使用 approval_policy = "never"。如果 admin requirements 不允许 approval_policy = "never"，automations 会回退到你所选模式对应的审批行为。

示例 #

自动创建新的 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.

跟进项目最新变化 #

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

结合 automations 和 skills 修复自己的 bug #

创建一个新的 skill，尝试修复当前作者在最近一周内引入的 bug，方法是创建新的 $recent-code-bugfix，并把它 保存到个人 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.

之后，创建一个新的 automation：

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

常见问题 #

OpenAI Codex 的 automations 会在什么地方显示结果？ #

会显示在 Codex app 侧边栏的 automations 面板里；其中带 findings 的 run 会进入 Triage，相当于收件箱。你还可以筛选查看全部 automation runs，或只看未读。

Codex 自动化应该用本地项目还是 worktree？ #

如果你想让 automation 改动和自己未完成的本地工作隔离开，选 worktree。要是希望它直接操作主 checkout，可以用本地项目模式，但要注意它可能修改你正在编辑的文件。

为什么我的 automation 运行失败？ #

最常见的原因是 sandbox 限制：read-only 不能修改文件、访问网络或操作本机应用；workspace-write 不能碰 workspace 外的文件或做网络访问；full access 则风险更高。先检查 Settings 里的 sandbox 设置，再按需要用 rules 放行命令。