1. 为什么你的 Codex 定时任务总是跑不起来
很多人第一次接触 Codex 的 Scheduled Tasks，脑子里想的是「我写一句提示词，它每天自动帮我巡检项目」。结果配完之后发现：任务要么根本没触发，要么触发了但报错说找不到依赖，要么它在你正在改代码的时候把工作区搅得一团乱。
问题不在 Codex 本身，而在于定时任务和普通对话是两种完全不同的运行模式。普通对话里你在旁边盯着，出错了随时打断；定时任务是无人值守的，它拿到什么环境、什么权限、什么目录，就按那个条件硬跑。所以配置的重点不是提示词写得多漂亮，而是运行环境、工作目录、权限边界这三件事有没有提前定好。
这篇面向 ChatGPT Plus 用户，讲清楚 Codex 定时任务怎么设置，重点落在 Worktree 隔离和自动巡检的落地配置上。我会给出一份可复制的config.toml骨架，演示怎么通过 TaoToken 的统一 Key 和 API 通道接入，最后跑一次巡检触发并验证结果。适合已经用过 Codex、想让重复性检查自动化的开发者。
先说结论：定时任务适合处理已经手动跑通、步骤固定、输出容易检查的工作。没验证过的复杂流程直接设成定时任务，等于给自己埋雷。
2. 前置准备：TaoToken 统一 Key 与 API 通道
在配置定时任务之前，先把模型调用通道理顺。Codex 的定时任务在后台运行时，需要稳定的 API 入口，否则任务触发时如果通道不通，你只能看到一条失败记录，排查起来很麻烦。
TaoToken 在这里的作用是提供一个统一的 Key 和 API 通道，把模型调用集中管理。官网地址是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 入口是 https://taotoken.net/api （这个不加 UTM）。
你需要先拿到 API Key。进入控制台创建：
- 控制台：https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite
- API Keys 管理：https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite
创建完 Key 之后，建议先在模型对话页面手动验证一次通道是否正常：
- 模型对话：https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite
这一步别跳过。我见过太多人直接把没验证过的 Key 写进定时任务配置，然后任务每天失败一次，还以为是 Codex 的问题。手动对话能通，说明 Key 和通道没问题，再往下配。
如果你后续要做长期编码或者 Agent 类的自动化，可以了解下 Coding Plan：
- Coding Plan：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite
接入文档在这里，配置参数有疑问可以对照：
- 接入文档：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite
3. 可复制的 config.toml 骨架与 Worktree 配置
Codex 的项目级配置放在项目根目录的.codex文件夹里。定时任务相关的配置主要分三块：模型通道、Worktree 初始化脚本、任务权限。
下面是一份可以直接改的config.toml骨架：
# .codex/config.toml [model] # 通过 TaoToken 统一通道调用 provider = "openai-compatible" base_url = "https://taotoken.net/api" api_key_env = "TAOTOKEN_API_KEY" model = "gpt-4o" [environment] # Worktree 创建后自动执行的初始化脚本 setup_script = """ npm install npm run build """ # 常用操作，供定时任务调用 [environment.actions] run_tests = "npm test" lint = "npm run lint" build = "npm run build" [scheduled_tasks.default_permissions] # 只读巡检：不允许写入、不允许网络访问 sandbox = "read-only" allow_write = false allow_network = false [scheduled_tasks.worktree] # 可能产生修改的任务使用独立 Worktree enabled = true # 与原仓库共享 Git 提交信息，但文件副本独立 share_git_history = true几个关键点解释一下。
base_url指向 TaoToken 的 API 入口，api_key_env表示从环境变量读取 Key，不要把 Key 明文写进配置文件。你可以在本地 shell 里设置：
export TAOTOKEN_API_KEY="你的Key"setup_script是 Worktree 模式的核心。Worktree 创建的是一个全新的工作目录，Git 跟踪的代码文件会在，但node_modules、Python 虚拟环境、.env、本地缓存这些被.gitignore忽略的内容不会自动带过来。所以定时任务经常出现「代码能读，测试跑不了」的情况。把初始化命令写进setup_script，Codex 创建 Worktree 后会自动执行。
权限这块，read-only适合纯巡检任务。如果任务需要生成代码修改，改成项目内写入：
[scheduled_tasks.default_permissions] sandbox = "workspace-write" allow_write = true allow_network = false注意allow_network默认关掉。只有任务确实需要查询外部系统时才开，而且尽量只开必要的插件或域名，不要图省事直接放开整台机器。
4. 创建定时任务并触发一次巡检
配置写好后，在 ChatGPT 桌面端的 Scheduled 页面创建任务，也可以直接在 Codex 对话里描述需求。任务描述要明确四件事：检查范围、是否允许修改、输出格式、没有结果时怎么处理。
一个可用的巡检提示词模板：
每个工作日检查当前项目最近 24 小时的失败测试、异常提交和新增高风险 Issue。 不修改代码，不创建 Issue，不重新运行 CI。 将重复问题合并，按严重程度排序。 为每个问题提供证据、相关文件和建议动作。 如果无法访问某项信息，明确说明。 如果没有新问题，只输出「本次巡检未发现新增问题」。创建时选择 Worktree 模式，运行周期设为工作日每天一次。任务创建后不会立刻等到第二天，你可以在 Scheduled 页面手动触发一次，验证整条链路。
触发后观察执行记录。正常情况下你会看到：
- Codex 创建了一个独立 Worktree 目录；
- 执行
setup_script里的npm install和npm run build； - 按提示词扫描最近提交和测试结果；
- 生成一份结构化报告，显示在 Scheduled 页面的运行记录里。
如果报告里出现「无法运行测试」之类的信息，大概率是setup_script没覆盖到某个依赖，回到config.toml补上对应命令再触发一次。
5. 本篇常见错误排查
Worktree 里测试跑不起来，提示找不到模块。这是最常见的问题。原因是 Worktree 是新的工作目录，node_modules不在。检查setup_script是否包含npm install，Python 项目对应pip install -r requirements.txt或poetry install。
定时任务修改了正在编辑的文件。说明任务用了本地模式且开了写入权限。只读巡检用本地模式没问题，但只要任务可能产生修改，就切到 Worktree 模式，让它在独立目录里折腾。
任务每天重复报告同一个旧问题。提示词里没有区分「新增」和「历史」。加上时间范围限定，比如「最近 24 小时」，并要求「将重复问题合并」。
API 调用失败，任务记录显示通道错误。先回到模型对话页面手动验证 Key 是否有效。如果手动能通、定时任务不通，检查环境变量TAOTOKEN_API_KEY是否在任务运行的环境中可见。后台任务不一定继承你当前 shell 的环境变量，必要时在config.toml里用其他方式注入。
权限开太大导致安全风险。无人值守任务不要用完全访问模式。数据库迁移、生产环境操作、批量删除文件这类动作，继续保留人工审批，不要交给定时任务。
任务频率设得太高。每小时跑一次巡检，大部分时候输出都是「无新增问题」，白白消耗调用额度。按实际需要设成每天或每周一次就够。
6. 把巡检稳定下来的几个动作
定时任务跑通一次不代表可以放任不管。前几次执行结果要人工看一遍：是否读取了正确项目、是否运行了预期测试、输出是否方便审查、有没有产生无关修改。如果任务每次都需要你重新解释，说明流程还不稳定，这时候应该先把工作方法整理成 Skill，再由 Scheduled Task 负责运行周期。Skill 定义怎么做，定时任务定义什么时候做。
对于长期编码和 Agent 类自动化，可以走 Coding Plan 通道：
- Coding Plan：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite
Claude Code 相关接入参考：
- ClaudeCodeAnthropic：https://taotoken.net/claude-code-anthropic?utm_source=taotoken_aicg_blog_end&utm_content=claudecode&utm_campaign=rewrite
配置参数和接入细节对照文档：
- 接入文档：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite
从只读巡检开始，可能修改代码时用 Worktree 隔离，高风险操作保留人工审批。这样 Codex 省下的是重复检查的时间，而不是在后台制造新的工程问题。
