1. 为什么我的 Codex 定时任务一到点就“失忆”先说结论Codex Automation 的定时任务之所以会“失忆”绝大多数情况不是模型抽风也不是提示词写得不好而是任务每次被触发时落到了一个全新的、没有历史上下文、没有工具授权、工作目录还可能不对的执行环境里。你手动跑的时候一切正常是因为你手动跑的那条会话里工作目录、工具权限、历史状态都是齐的而 Cron 到点拉起的那次执行往往只是“启动了任务”并不保证“回到你验证过的那条线程”。我踩这个坑的场景很典型一个每天固定时间整理项目变更、生成日报并发送邮件的任务。手动运行读仓库、总结、发邮件全通。挂上定时之后日志里能看到任务确实被触发了执行痕迹也有但邮件就是发不出去或者总结出来的内容是空的、读到的是旧文件。最开始我怀疑提示词不稳定接着怀疑邮件工具授权过期最后翻本地配置和会话索引才发现问题出在target_thread_id和heartbeat这两个字段上——任务压根没绑定到我手动验证过的那条线程。这篇文章面向的是已经在用或准备用 Codex Automation 做定时任务的开发者尤其是任务里涉及邮件、外部 API、固定项目目录、连接器调用这类“有状态、有权限依赖”的场景。我会把这次排障的完整过程拆开先讲清楚 Codex 自动化和传统 Cron 的心智模型差异再给出可复制的config.toml与settings.json骨架然后一步步教你怎么校验target_thread_id、怎么用 TaoToken 统一 Key 接入并稳定复用会话最后用一个定时任务复现验证动作收尾。如果你只想让任务“到点跑一下纯文本总结”Cron 够用但只要任务需要“回到正确的位置、带着正确的权限做事”就值得把下面的配置看完。2. 前置用 TaoToken 统一 Key 打通 Codex 的 API 通道在动 Automation 配置之前先把 API 通道理顺否则后面排障会同时面对“上下文丢失”和“鉴权失败”两个变量很难定位。我现在的做法是让 Codex 走 TaoToken 的统一 Key 和 API 通道这样模型对话、编码任务、自动化触发用的是同一套凭证出问题时只需要在一个地方查。TaoToken 在这里扮演的角色很直接它是一个统一的模型 API 接入层你拿到一个 Key就能在 Codex 这类工具里配置base_url和api_key不用为每个模型或每个工具单独维护一套凭证。对 Automation 场景来说这一点很关键——定时任务在无人值守的情况下触发如果凭证分散、过期时间不一致失败原因会非常隐蔽。你需要先拿到 Key。进入控制台创建 API Keyhttps://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite创建好之后API 的基础地址是https://taotoken.net/api注意这个地址不带任何查询参数直接作为base_url使用。拿到 Key 之后先别急着配 Automation先用一次普通请求确认通道是通的。你可以用 curl 做一次最小验证curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-20250514, messages: [{role: user, content: ping}], max_tokens: 16 }如果返回里有正常的choices结构说明 Key 和通道都没问题。这一步看起来多余但它能帮你把“API 通道问题”和“Automation 上下文问题”彻底分开。我见过不少人一上来就怀疑target_thread_id结果折腾半天发现是 Key 没配对。先把通道验证掉后面排障会清爽很多。如果你更习惯在图形界面里先确认模型可用可以直接用模型对话页跑一句https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite通道确认之后再进入 Codex 的配置文件环节。这里有个原则Codex 的 API 配置和 Automation 的线程配置是两件事前者决定“能不能调用模型”后者决定“任务在哪个上下文里执行”。两者都要对任务才稳。3. 可复制配置config.toml 与 settings.json 骨架Codex 的本地状态目录默认在~/.codexWindows 下对应C:\Users\你的用户名\.codex。如果你设置过CODEX_HOME环境变量就以它指向的目录为准。自动化任务一般一条对应一个目录~/.codex/automations/automation-id/automation.toml先给一份我实际在用的automation.toml骨架字段名可能随版本微调但核心结构不变name daily-project-report status ACTIVE kind heartbeat # 绑定已经手动跑通过的线程这是防失忆的关键 target_thread_id 019e07b4-64e4-7c21-90d9-1c5f3301ee7c # 固定工作目录避免自动化跑到错误项目 cwds [C:/Users/your-name/work/project] # 周期规则按当前版本支持情况填写 rrule RRULE:FREQDAILY;BYHOUR21;BYMINUTE30;BYSECOND0几个字段逐个说清楚。kind决定触发方式cron是传统定时heartbeat是绑定线程的持续工作模式涉及工具权限和固定上下文的任务用heartbeat。status确认任务是否启用排障时先看它是不是ACTIVE。target_thread_id是整份配置里最容易被忽略、也最容易出错的一项它必须来自一条你已经手动验证成功的线程。cwds固定工作目录防止任务跑错项目却“不报错只读旧文件”。rrule是周期规则按版本支持情况填。再给一份settings.json骨架用来配置 Codex 走 TaoToken 的 API 通道{ api: { base_url: https://taotoken.net/api, api_key: sk-你的TaoTokenKey, model: claude-sonnet-4-20250514 }, automation: { default_kind: heartbeat, session_index: ~/.codex/session_index.jsonl, log_dir: ~/.codex/logs } }这里把base_url指向 TaoToken 的 API 地址api_key填你在控制台创建的 Key。automation段里我额外标了会话索引和日志目录排障时会反复用到。注意不要把 Key 硬编码进会提交到仓库的文件里用环境变量或本地私有配置更稳妥。配置写完之后先别急着等定时触发。手动触发一次确认任务能正常执行再让它进入定时循环。这一步的顺序很重要先手动验证上下文再交给自动化复用。4. 校验 target_thread_id找到真正绑定的线程target_thread_id填错或填了一个不存在的线程是“失忆”最直接的原因。校验它分三步。第一步从会话索引里反查。Codex 本地通常有会话索引文件~/.codex/session_index.jsonl用命令行快速看最近几条tail -n 20 ~/.codex/session_index.jsonl | jq -r .thread_id, .cwd, .updated_at如果你没装jq直接tail看原始行也行。重点确认三件事这条自动化绑定的thread_id是否真实存在最近一次运行是否真的落到了这个线程触发后有没有出现thread/read、thread/resume相关的失败记录。第二步确认工作目录匹配。自动化任务跑错目录时经常不报错只是“总结不到东西”。在索引里核对cwd字段和你automation.toml里的cwds是否一致。Windows 上还要特别注意路径归一化问题同一个文件可能被表示成两种形式C:\Users\...\rollout.jsonl \\?\C:\Users\...\rollout.jsonl看起来是同一个路径但恢复线程时可能被判定为不一致导致resume failed或stale path。如果你在日志里看到这类字样优先怀疑路径写法不统一。第三步确认工具权限。如果失败点出现在邮件、Gmail、Drive、GitHub 这类工具调用上先判断当前自动化上下文是否拥有和手动会话一样的工具权限。这一步比改提示词重要得多。手动会话里你授权过的工具不会自动继承到一条全新的自动化线程上。把这三步走完你基本能确定target_thread_id是不是那个“正确的家”。如果它指向的线程本身就没跑通过完整流程那自动化复用它的结果自然也不稳定。5. 复现验证一次定时任务的成功结果长什么样配置和线程都确认之后做一次完整的复现验证。我习惯手动把rrule临时改成“一分钟后触发”跑通再改回正式周期。触发之后按顺序看这几个地方。先看自动化目录下的运行记录ls -lt ~/.codex/automations/automation-id/再看日志里是否出现线程恢复成功的痕迹grep -E thread/resume|thread/read ~/.codex/logs/*.log | tail -n 20一次成功的执行日志里应该能看到线程被正确恢复、工作目录匹配、工具调用正常返回。业务侧的表现是日报内容读到了当前项目的最新变更邮件按预期发出且同一天同一主题只发了一封。这里必须强调幂等设计。自动化任务一定要假设会重试失败重试、心跳抖动都可能让同一个任务跑两遍。如果你的任务会发邮件、写日报、改文件、创建 issue就必须设计幂等。我的做法是用“日期 标题 项目名”作为唯一键发送前先检查当天是否已经发过。自动化最怕的不是失败而是“半成功”——总结做了两遍、邮件发了两封日志还看不出哪次是最终结果。验证通过后把rrule改回正式周期让任务进入稳定循环。之后每次它被触发都会回到你验证过的这条线程带着正确的权限和目录做事。6. 本篇常见错排查错误一复制自动化后忘了改target_thread_id。这是最隐蔽的坑。你以为复制了一条新任务实际上它还绑着旧线程新任务的行为完全受旧线程上下文影响日志很难解释。每次复制后name、target_thread_id、cwds三个字段必须一起检查。错误二多个 heartbeat 绑到同一条线程。理论上能跑不代表生产上该这么做。多个高频 heartbeat 指向同一个target_thread_id可能遇到恢复竞争、重复执行、状态抖动。关键任务一条线程一个自动化先稳定再扩展。错误三只看 UI 不看本地文件。UI 适合快速看状态排障要回到文件。至少看三处~/.codex/automations/automation-id/automation.toml、~/.codex/session_index.jsonl、~/.codex/logs或 state 相关文件。错误四一上来就改提示词。排障顺序应该是先查触发方式kind是 cron 还是 heartbeat再查绑定线程target_thread_id是否存在再查工作目录再查会话恢复有没有resume failed、stale path最后才查工具权限和提示词。顺序反了会在错误的地方花大量时间。错误五API 通道和线程配置混在一起排查。先用第 2 节的 curl 确认 TaoToken 通道正常再动 Automation 配置。两个变量分开验证定位效率会高很多。如果你在接入或排障过程中卡在鉴权、Key 配置、通道报错这类问题上可以直接对照接入文档逐项核对https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite需要重新生成或管理 Key走 API Keys 页面https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite7. 长期跑编码与 Agent 任务把通道固定下来把 Codex Automation 跑稳之后如果你还要长期跑编码类、Agent 类任务建议把 API 通道和额度规划也固定下来避免每次任务触发都面对不确定的鉴权状态。我现在的做法是让自动化任务统一走 TaoToken 的 Coding Plan模型对话、编码任务、定时自动化共用一套通道出问题时只在一个地方查。https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite回到这次排障的核心经验无状态、无工具依赖的任务用 Cron 就够需要上下文和工具权限的任务用 heartbeat target_thread_id。排障时先看本地配置和线程绑定再看提示词。自动化真正难的地方不是写一个定时表达式而是搞清楚任务每次醒来时它到底是谁、在哪里、能做什么。把target_thread_id校验对把工作目录固定住把幂等设计补上你的定时任务就不会再“失忆”了。