假設每天早上都有一件固定工作：把昨天的 CI failures 看一遍，把同類錯誤整理在一起，挑出比較值得先看的幾個，最後留一份摘要給人 review。

這件事用 cron 完全做得到。cron 到時間跑一條 command，那條 command 可以是 script，也可以再去叫 Codex。[3] 但如果工作真的交給 Codex，時間到了只是開始。它醒來之後還要知道要做什麼、在哪裡做、可以動到哪裡，以及做完的結果要留在哪裡。

Codex 的 Scheduled Tasks 把 schedule 跟後面的 Agent work 接在一起。Instructions、可重用的 skills、Local 或 Worktree、Model / Reasoning、Sandbox / Approval，以及最後的 review 都可以落在同一份工作設定裡。[1][2]

Scheduled agent job anatomy showing that scheduling is only the trigger and a Codex Scheduled Task still needs an agent job contract around it

Figure 1｜排程只是觸發器，真正的工作還需要一份 agent job contract。

排程到了，後面的工作還是要有人接

一條 crontab 可以很短：到某個時間，跑某個 command。command 裡面要做多少事情，cron 不管。[3]

Scheduled Task 多處理的是後面那段。Prompt 要放進一個能執行的環境裡，跑的時候還要知道哪些東西可以碰，做完也要有地方把結果送回來。[1][2] Model 跟 Reasoning 也能固定在這份 task 裡，不過這兩個比較像執行時的選項，跟幾點開工是兩回事。

如果真的想用 cron 自己組，也沒什麼問題。cron 叫 shell script，script 再叫 Codex CLI，旁邊自己接 Git worktree、log、通知和 review，一樣可以把整條鏈路拼起來。Built-in Scheduled Tasks 的差別主要是這段 glue 不用全部自己接。

所以每天幾點開始通常不難。比較容易出問題的是工作醒來之後，拿到的 context 夠不夠、碰到的是哪個 checkout、權限會不會卡住，以及結果到底有沒有真的產生。

背景工作會寫 code，就先處理 checkout 和權限

如果只是讀 log、掃 issue、整理 repo 狀態，那跑在 Local 通常最直接，因為它看到的就是你目前 project 的內容，也不用多一段整合。

但如果這個 Scheduled Task 會自己改 code，情況就不太一樣。你可能還在同一個 repo 裡做一半的 feature，背景 task 也在這時候醒來改檔。兩邊都沒有做錯，最後一樣可能把 working tree 攪在一起。Codex 提供 Local / Worktree 的選擇，worktree 可以把背景修改跟你手上的未完成工作分開。[2]

如果修改很 bounded，而且你知道它只會碰哪幾個地方，Local 不一定有問題。會跨多檔、會跑比較久，或你自己同時間也在那個 repo 工作，Worktree 通常比較好管。代價也很直接：未 commit 的 local state 不會自己跟過去，環境可能要再 setup，做完之後還要 review 和整合回來。

Scheduled run 也還是在 Sandbox 和 Approval 的邊界裡。OpenAI 曾修正 scheduled automations 沒有遵守 selected approval mode 的問題。[2] 這件事對背景工作很實際，因為如果 task 跑到一半需要人工批准，而那時根本沒人在電腦前，它就會很準時地停在那裡等你。

如果希望它在人不在場時也能跑完，那 write scope 就要先收窄，讓 task 在既定範圍裡自己做完。外部寫入、破壞性操作或需要升權限的步驟，再留給明確的 review / approval。

Model 和 Reasoning 先別急著 pin

Automations 可以固定 Model 和 Reasoning，但如果 task 還在摸索，其實不用一開始就把這兩個選項鎖死。[2]

如果只是固定掃描、整理、分類，而且輸入輸出都很穩，通常沒必要因為它在背景跑就把 reasoning 開得很重。但如果它要跨檔找 root cause、自己產生修改，或最後還要做取捨，那對 reasoning 的要求本來就比較高。

頻率也會把設定放大。如果一天只跑一次，多花一點 reasoning 成本可能沒什麼感覺；但如果每小時都會醒來跑一次，同一個設定一天會被重複很多次，這時候才比較值得去看 Model 跟 Reasoning 到底是不是設得太重。

Task 還沒穩定以前，先用預設值跑幾次。等你看到固定的 quality、latency 或 usage 問題，再決定要不要 pin，通常比較省事，也不會讓文章或工作流跟著某一顆 Model 名稱綁死。

每次開新的 run，還是回到同一條 Thread

如果只是每天整理昨天的 CI failures，那每次重新開一個 run 通常就夠了。而 deployment 之類還沒結束、兩小時後要回來看的這種，則是另一種工作。

Codex 的 thread automations 可以定時喚醒同一條 Thread，讓 conversation context 留著再繼續。[2] 這比較適合一件還沒結束的工作，例如 long-running process 還在跑，晚一點要回來看狀態；固定的每日整理則通常沒有必要一直背著前一天整條 conversation。

如果只是每 15 分鐘醒來看一次 deployment 有沒有完成，那本質上還是在定時檢查。另一種是 deployment 狀態一變，系統就直接送事件過來叫後面的工作開始，這才是 event-driven。兩種最後都可以接 Agent，但 latency、空跑次數和 failure mode 不一樣。Scheduled Task 可以拿來 polling，polling 不會因為後面接了 Agent 就變成 event trigger。[1]

已經有 CI 或 scheduler，就不要為了 Codex 再搬一次 trigger

如果 GitHub Actions、Jenkins、Airflow 或自家的 scheduler 已經在管 trigger、retry、secret、audit 和告警，通常沒必要只為了讓 Codex 定時跑，就把 trigger 再搬到另一個地方。

對 ChatGPT Enterprise workspace，OpenAI 也提供過讓 trusted non-interactive Codex local workflows 從 scripts、schedulers 和 private CI runners 啟動的 access-token 路徑。[2] 如果原本的 scheduler 已經在管這些，那就讓它繼續管時間和事件，Codex 接後面的 Agent work 就好。

Built-in Scheduled Tasks 比較適合個人或 desktop workflow。你想在 Codex 裡直接留一份 recurring job，跑完之後也回到 Codex 裡 review，這種就很順。反過來，如果 trigger 本來就跟 pipeline state、deployment event 或既有的 retry policy 綁在一起，那留在原系統通常比較乾淨。

責任已經在哪裡，就盡量少搬一次。

ACTIVE 只代表設定存在，後面的路還要自己驗

畫面顯示 ACTIVE 時，最容易犯的錯就是把它當成「之後一定會自己跑完」。

官方 Codex repo 有過 Automation 顯示 ACTIVE，但排程到了沒有建立 Thread，也沒有可見執行的案例。[4] 也有另一個案例是 Thread 建起來了，但 prompt 沒有真的 submit 成 user Turn，後面也沒有 model sampling。[5]

這些 issue 不能拿來推算 Codex Automations 的整體可靠率，但至少可以看出 failure 不只一種：有可能 scheduler 根本沒叫起來，也可能 Thread 有了，Agent Turn 卻沒有真的開始。

Automation verification ladder showing the proof path from configured state through scheduler firing, run creation, prompt dispatch, execution, output and review

Figure 2｜要驗證的不是設定而已，而是整條執行路徑。

Automation configured / ACTIVE
        ↓
Scheduler actually fires
        ↓
Run or Thread starts
        ↓
Prompt reaches an Agent Turn
        ↓
Model and tools execute
        ↓
Expected artifact or side effect appears
        ↓
Result passes review

只看第一格，後面六格都還不知道。

排程時間也要實際看一次。官方 repo 也有 RRULE 的 local time / UTC 解讀不一致回報。[6] 這只能證明 timezone / recurrence 確實是一個可能出錯的 layer，不能拿來估發生頻率。

第一次設 Scheduled Task，可以先挑一個低風險、結果很好判斷的 workload。先在普通 Thread 手動跑一次 prompt，看它在有人盯著的情況下能不能完成；接著把 schedule 設在不遠的時間，實際看一兩次 run。確認 firing time、Thread / Turn、tool activity、輸出和 review path 都對，再把 cadence 拉到正式值。

等整條 path 確定跑通，再讓它真的自己去跑。

參考資料

  1. OpenAI, Introducing the Codex app. https://openai.com/index/introducing-the-codex-app/
  2. OpenAI, ChatGPT & Codex changelog. https://developers.openai.com/codex/changelog
  3. The Open Group, crontab. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html
  4. OpenAI Codex GitHub, Automation marked Active but does not run or create a thread, issue #16938. https://github.com/openai/codex/issues/16938
  5. OpenAI Codex GitHub, Codex Desktop cron automation creates empty thread but does not execute prompt, issue #26086. https://github.com/openai/codex/issues/26086
  6. OpenAI Codex GitHub, Desktop automations ignore timezone for RRULE scheduling / next execution, issue #26633. https://github.com/openai/codex/issues/26633