Claude Code 到 Codex 遷移指南 2026

2026 年 5 月 3 日，我盤點了 744 筆本地代理設定項目，接著依操作權重排序其中 691 筆。¹ 數量看起來很大。更重要的是結構：約 20 個檔案撐起了整套系統。

Claude Code 到 Codex 的遷移，應該移植操作契約，而不是複製檔案樹。把 CLAUDE.md 規則移到分層的 AGENTS.md，把可重用流程移到 Codex 技能，把確定性的關口移到聚焦的掛鉤，把風險姿態移到設定檔，把瀏覽器與來源工具移到明確的 MCP。不要把 Claude 掛鉤網格照搬到 Codex；要搬的是證明義務。

TL;DR

我在 Codex 世界裡已經有私有寫作與驗證堆疊。缺的不是技能內容。缺的是公開操作手冊：可重用技能應該放在哪裡、Codex 應該如何選用它們、公開寫作應該跑在哪個設定檔，以及哪些 Claude 時代的關口應該變成 Codex 原生規則，同時不暴露私有工作流程細節。

第一次真正在 Codex 跑過之後，遷移規則改了：不要讓私有工作流程一被移植就變成環境預設。要分階段。我現在的站點專屬寫作路徑先採明確呼叫；遷移工作流程則以使用者技能的形式供本地積極使用，並作為私有 Codex 套件候選項供本地測試。該套件不是開源，也不是普遍可用；如果你想測試這套遷移工作流程，請聯絡我。套件不應該只因為本地有安裝項目，就變成預設執行路徑。真正的安裝試行仍然需要套件驗證、外掛安裝驗證、具命名空間的技能探索、重複項清理，以及全新的 Codex 會話，才有意義。這讓系統能在工作流程成為預設行為之前，先從真實工作中學習。¹⁸¹⁰¹⁴

不要從複製每個 Claude 掛鉤到 Codex 開始。先寫 Codex 契約：

• 把持久的跨儲存庫政策放在 ~/.codex/AGENTS.md。
• 把儲存庫政策放在 AGENTS.md，並把更窄的覆寫放在靠近工作的位置。
• 把可重用流程放在 .agents/skills 或 $HOME/.agents/skills。
• 把公開寫作提升到 careful-review 或專用的 public-writing 設定檔。
• 保留確定性關口作為掛鉤，但把掛鉤視為一道護欄，而不是整套安全模型.

第一個成功的遷移產物應該是一篇能自我描述的文章。這個產物證明系統能描述自己、引用目前文件、使用經過整理的本地盤點，並在 Codex 控制下產出公開作品，而不公開背後的私有機制。

我在 Claude Code as Infrastructure 談過 Claude 端的堆疊，在 AGENTS.md Patterns 談過指令檔案，在 Static Skills Are Dead Skills 談過技能衰退問題。下面的遷移把這些線索連到我實際使用的 Codex 執行環境。

相鄰脈絡可讀 Codex CLI guide、Claude Code vs Codex、Codex vs Claude Code 2026、Claude Code Hooks Tutorial、Building Custom Skills，以及 Jiro Quality Philosophy。那些文章說明了這次遷移在這裡組合起來的各個元件。

遷移盤點顯示了什麼？

本地系統有三個重心。

使用資料指向同一個結論。我的設定檔路由記錄顯示，重審查工作主導了日常執行。¹ 真正的核心不是最長的檔案，也不是最聰明的腳本。核心是會選擇風險層級、載入原則，並在完成前強制要求證據的決策層。

這個發現改變了移植方式。

如果重要的是「Claude 有很多掛鉤」，遷移就會複製掛鉤。如果重要的是「系統有一套哲學」，遷移就會複製文字。盤點顯示了不同答案：重要的是一份會在正確時機觸發的小契約。

發布前我們做了什麼？

文章本身成了第一個遷移練習。

首先，我映射成熟 Claude Code 設定的形貌：哪些部分管控行為，哪些部分只是記錄偏好，哪些部分應該保持私有。接著我用官方文件和本地 CLI 檢查目前 Codex 行為，因為遷移指南如果繼承舊旗標或不支援的設定形狀，很快就會腐壞。然後我以真實遷移為前提起草本文，但把公開細節收斂為整理過的架構，而不是私有實作。

下一步發生在發布前：用這份指南建出 Codex 設定，再依實際改動修訂文章。公開文章應該呈現遷移模式與驗收標準。不應該發布私有提示、私有寫作工作流程、精確掛鉤內部、敏感路徑，或任何會讓讀者重建私有系統的東西。

實際執行產生了一張適合公開的證明表。我只發布契約、啟用狀態與驗收訊號，不發布私有提示、精確掛鉤內容或寫作工作流程內部。

你應該從掛鉤開始 Codex 遷移嗎？

Claude 教會我用生命週期事件思考。UserPromptSubmit 掛鉤可以注入專案脈絡。PreToolUse 掛鉤可以封鎖敏感路徑。Stop 掛鉤可以拒絕薄弱完成。這個模式在 Claude 可行，因為我的本地堆疊圍繞分派器成長，會把許多小腳本轉成一條有序事件管線。¹¹

Codex 也有掛鉤，但目前 Codex 把它們視為受功能關口控制的生命週期系統，而不是永遠啟用的掛鉤目錄。OpenAI 的掛鉤文件顯示在 config.toml 中使用 [features] codex_hooks = true，而我的本地 codex features list 回報 hooks 在 Codex CLI 0.130.0 上為穩定且已啟用。²⁸ OpenAI 記錄掛鉤輸入是 stdin 上的 JSON，含有會話 id、工作目錄、事件名稱與作用中模型等共享欄位。² Codex 支援 SessionStart、PreToolUse、PermissionRequest、PostToolUse、UserPromptSubmit 與 Stop 等事件；PreToolUse 可攔截 Bash、apply_patch 與 MCP 工具呼叫。²

同一份文件也給了遷移時最重要的警告：PreToolUse 仍是護欄，不是完整強制邊界。文件指出攔截不涵蓋每一條 shell 路徑，也不會攔截網頁搜尋或其他非 shell、非 MCP 工具呼叫。²

這個限制不代表 Codex 掛鉤薄弱。它代表掛鉤不應承擔整個移植。OpenAI 也指出，同一事件有多個相符命令掛鉤時會並行啟動，所以如果 Codex 移植需要順序，仍需要分派器或一個合併掛鉤命令。²

對 Codex 而言，我想把掛鉤用在狹窄的確定性檢查：

• 封鎖明顯具破壞性的 shell 命令。
• 對憑證形狀的路徑發出警告。
• 加入少量會話啟動脈絡。
• 記錄公開寫作執行的證據。
• 在缺少必要產物或驗證命令時讓停止事件失敗。

我不希望掛鉤承擔寫作語氣、引用政策、哲學、路由或專案原則。Codex 已經有更好的歸宿。

Claude 產物如何映射到 Codex？

當每個 Claude 產物都映射到最符合其工作的 Codex 原語，遷移會更乾淨。

OpenAI 的 AGENTS.md 文件讓第一列成為遷移主幹。Codex 會在工作前讀取 AGENTS.md 檔案，從 Codex home directory 載入全域指引，然後從專案根目錄走到目前目錄，讓較近的檔案覆寫較早的指引。³ 這個行為符合我實際需要 CLAUDE.md 提供的東西：持久工作協議加上專案本地細節。

關鍵動作：把規則改寫成操作。「謹慎寫作」不屬於 AGENTS.md。「對公開文章，先收集引用、驗證 URL、執行禁用短語檢查，並回報任何未驗證宣稱」才屬於那裡。

私有寫作技能應該如何移到 Codex？

部落格寫作者堆疊移植起來很乾淨，因為它已經有正確形狀。Codex 技能是含有 SKILL.md 檔案的資料夾，該檔案包含 frontmatter 與指令。Codex 可以在使用者明確呼叫，或任務符合技能描述時啟用技能。⁴ Codex 會從儲存庫、使用者、管理員與系統位置讀取技能，包括儲存庫 .agents/skills、$HOME/.agents/skills 與 /etc/codex/skills。⁴

這是 Claude Code 遷移容易微妙出錯的地方。Codex 技能不是 Claude slash commands。官方 Codex 技能的明確呼叫路徑是技能選擇器或 $skill-name mention，而 Codex CLI slash commands 是另一個互動控制表面，用於狀態、權限、模型變更、外掛與會話控制等內建動作。⁴¹⁵ 像 /cave 這樣的提示如果技能描述辨識它，或包裝器把它轉成 Use $cave ...，仍然可以是有用的簡寫，但 slash 文字本身不是持久契約。若要證明遷移，請測試 $skill-name；只有在你承諾相容性時，才另外測試 /name。

這表示我應該把新的 Codex 原生寫作技能正規化到官方技能路徑，而不公開私有技能名稱或內容：

$HOME/.agents/skills/source-verifier/SKILL.md
$HOME/.agents/skills/public-post-writer/SKILL.md
$HOME/.agents/skills/site-specific-writer/SKILL.md

我的本地執行環境也在較舊位置有可用的使用者技能。¹ 我不應只因公開文件命名 .agents/skills 就刪掉那些。安全的遷移是：

1. 複製或符號連結一個技能到 $HOME/.agents/skills。
2. 重新啟動 Codex。
3. 確認 Codex 列出並啟用該技能。
4. 在試行期間讓技能僅限明確呼叫。
5. 探索與試行使用都成功後，再移動其餘部分。
6. 保留舊路徑，直到既有會話和腳本不再依賴它。

這就是我對第一個私有寫作工作流程採取的路徑。我把站點專屬寫作者分階段放成明確呼叫限定的私有技能，而不是讓它成為每個內容任務的預設寫作者。這給了遷移一個更好的測試：如果技能能改善本文與下一次公開寫作執行，且不洩漏私有流程，它就能從明確呼叫限定移到試行。如果它增加混亂，就保持限定範圍。

品牌專屬寫作者不應成為預設站點寫作者。私有產品寫作者可能共享同樣的引用與審查標準，但其受眾、產品事實、行動呼籲與語氣規則應該限定在該產品。正確移植會把品牌配接器分開，並為 blakecrosley.com 建立一個薄站點專屬寫作者。

該站點技能應該保持精簡：

---
name: site-specific-writer
description: 為特定網站撰寫公開技術文章。用於需要已驗證來源、內部連結、網站語氣與發布檢查的文章。
---

# Site-Specific Writer

每一篇公開技術文章都要使用私有寫作、來源驗證與 AI 可發現性技能。

完成前必備證明：
- 外部技術宣稱都有引用。
- 目前 Codex 宣稱引用 OpenAI 文件。
- 內部宣稱連到既有文章或標示為作者分析。
- 文章在有用時包含 TL;DR、依角色區分的 takeaways 與讀者問題。

Codex 技能文件顯示 name 與 description 是手動技能 frontmatter 欄位，並讓描述成為隱式啟用的觸發條件。⁴ 內文可以要求 Codex 使用私有配套技能；除非本地工具鏈加了額外 metadata，組合應屬於指令。通用堆疊擁有寫作規則。站點包裝器擁有語氣、連結模式與證明。

同樣的切分也適用於遷移工作流程本身。OpenAI 的外掛文件建議，當你仍在迭代一個個人工作流程時，先從本地技能開始；當你想在團隊間分享穩定套件或綁定更多整合時，再建立外掛。¹⁰ 這讓作用中路徑很明顯：先使用者技能，再私有套件試行。我沒有把遷移技能開源，也沒有承諾公開發布；如果你想測試，請聯絡我。外掛快取探查顯示已安裝外掛技能會出現在外掛命名空間底下，而不是裸技能名稱，因此套件文件應區分直接技能使用與外掛安裝後的技能使用。⁸

私有套件需要驗證器，早於需要發布敘事。在最近一次執行中，我加了驗證器，檢查 marketplace JSON、外掛 manifest、技能 frontmatter、必要引用、引用檢查器語法、安裝政策、沒有作用中掛鉤或 MCP manifest、產生檔案，以及明顯的私有路徑或機密 fixture 洩漏。這個檢查應該放在任何更廣泛啟用之前，因為 OpenAI 的外掛文件把 marketplace 視為安裝表面，而不是不穩定私有工作流程的暫存區。⁸¹⁰

AGENTS.md 應該如何承載公開寫作規則？

最強的 Codex 遷移改動屬於 AGENTS.md，不是掛鉤。公開寫作需要一個預設風險類別。

這是我想放在全域或專案檔案靠前位置的規則：

## 公開寫作是產品工作

公開文章、指南、landing pages、會影響使用者理解的 docs，以及 product copy 至少使用 `default` profile。當 claims、citations、brand、money、safety、security 或 user trust 涉入時，提升到 `careful-review`。

完成公開寫作前：
- 起草前先收集 citations。
- 對目前工具行為引用官方 product docs。
- 清楚標示 author analysis。
- 執行 banned-phrase scan。
- 驗證 internal links。
- 回報任何無法驗證的 claim。

這條規則修正了我在路由器盤點發現的缺陷。有些內容工作漂向快速執行，因為路由器把「內容」當成便宜工作。公開寫作在改變人們相信、購買、安裝或執行的東西時，並不是便宜工作。部落格草稿、指南與產品頁比日常程式碼編輯更需要審查，因為失敗模式是公開信任，不是本地測試失敗。

你正在讀的這篇文章就是例子。它引用目前 Codex 文件來說明目前 Codex 行為。它把本地盤點宣稱標示為作者分析。它使用真實堆疊，而不是假裝遷移從空白機器開始，但它把私有實作細節留在公開文章之外。

Codex 設定檔應該如何編碼風險？

OpenAI 的設定參考把 profile 定義為啟動時的預設設定檔，並支援對受支援設定鍵做設定檔範圍覆寫。⁵ 同一份參考把 model_reasoning_effort、approval_policy 與 sandbox_mode 定義為明確的設定控制。⁵

這給了 Codex 一個自然位置來編碼風險。

[profiles.public-writing]
model = "gpt-5.5"
model_reasoning_effort = "xhigh"
sandbox_mode = "workspace-write"
approval_policy = "on-request"
web_search = "live"

確切模型可以改。政策不應該改。公開寫作需要更高推理、當事實可能變動時要做即時來源檢查、限定工作區的執行，以及對離開安全工作路徑的動作需要人工核准。

路由器應該把這類任務映射到 public-writing 或 careful-review：

• 部落格文章、指南或首頁變更。
• 任何有引用的文章。
• 任何比較工具或供應商的內容。
• 任何命名目前 Codex、Claude Code、OpenAI、Anthropic、Apple、Google 或其他快速變動產品的文章。
• 任何觸及 schema、llms.txt、SEO、analytics 或公開 metadata 的工作。

設定檔不是氛圍。設定檔是風險預算。

哪些 Codex 掛鉤仍然重要？

Codex 掛鉤應該執行那些必須在執行環境中發生的小事。

公開寫作停止掛鉤可以檢查已變更檔案，若公開 Markdown 文章含 footnote references 但沒有 definitions，就拒絕完成。工具前掛鉤可以在代理嘗試編輯 .env、analytics credentials 或 generated translation caches 來寫文章時發出警告。會話啟動掛鉤可以加入目前日期，並提醒 Codex「latest」宣稱需要驗證。

保持掛鉤 payload 小。OpenAI 記錄了掛鉤的 JSON 輸出形狀，包括 systemMessage、continue 與事件專屬欄位。² 用那些欄位封鎖或警告精確失敗。不要重建整個 Claude 分派器網格，除非 Codex 失敗資料證明你需要它。

設定測試不足以獲得晉級。掛鉤只有在真實使用觀察通過顯示三件事後，才移出試行：它在預期情境觸發、它通過普通工作、它記錄安全的彙總遙測而不是私有內容。如果阻擋觸發，理由必須告訴使用者下一步該做什麼。²⁸

第一次即時執行後，實際掛鉤 backlog 看起來像這樣：

1. SessionStart：讓精簡目前日期、時效性、專案與公開/私有邊界脈絡保持試行。
2. PreToolUse:Bash：讓窄範圍破壞性命令與憑證讀取防護保持試行。
3. PostToolUse:apply_patch：讓非阻斷品質影子檢查監看已變更程式碼/設定 patch 行。
4. Stop：讓已變更公開 Markdown 引用關口保持試行。
5. Stop：把最終驗證契約折進既有品質 Stop 試行；在真實失敗證明需求前，不建立分離摘要掛鉤。

這組會移植安全行為，而不匯入數月 Claude 專屬儀式。

MCP 與瀏覽器工具應該如何配合？

我目前的 Codex 設定已經使用私有 MCP 支援的瀏覽器自動化路徑。¹ Codex 也透過 CLI 與 config.toml 支援 MCP servers：codex mcp add 可以註冊 stdio server，而 [mcp_servers.<server-name>] tables 可以定義 command、args、environment、URLs、enabled_tools、disabled_tools 與 timeouts。⁶

對公開寫作來說，MCP 屬於兩個地方：

• 瀏覽器自動化，用來檢查即時渲染頁面、截圖與本地預覽。
• 來源探索或文件擷取，當特定供應者暴露可靠 MCP server 時使用。

MCP 不應隱藏來源軌跡。部落格寫作者需要讀者可以點擊的引用，而不是只存在於會話中的私有工具結果。MCP 可以幫忙找到事實。最終文章仍需要公開來源。

如何啟動 Claude Code 到 Codex 的遷移？

第一個 Codex 原生產物應該在使用這套移植的同時描述這套移植。

這是互動式啟動迴圈：

codex -p careful-review --search \
  "Inventory the local Codex and Claude migration surface, then create a citation bank for a sanitized post about moving the setup to Codex."

codex -p careful-review \
  "Draft content/blog/claude-code-to-codex-migration.md using the local inventory, official Codex docs, and existing internal posts. Label author analysis clearly."

codex -p careful-review \
  "Review the draft for unsupported claims, stale Codex flags, broken internal links, and AGENTS.md operational value."

對非互動工作，使用 codex exec，並把即時搜尋當成設定/設定檔關切，而不是複製互動式 --search 旗標。OpenAI 記錄 codex exec 用於腳本化或 CI 風格執行，含 --profile、--sandbox 與 --config 覆寫；我的本地 Codex CLI 0.130.0 help 確認了那些旗標，並拒絕 codex exec --search。⁷⁸

codex exec -p careful-review -c 'web_search="live"' \
  "Create a citation bank for content/blog/claude-code-to-codex-migration.md from official Codex docs and sanitized local inventory."

codex exec -p careful-review \
  "Review content/blog/claude-code-to-codex-migration.md for unsupported Codex claims, stale flags, broken internal links, and AGENTS.md operational value."

命令列細節很重要。OpenAI 將 --full-auto 標記為 deprecated compatibility flag，並建議改用 --sandbox workspace-write。⁷ 以 --full-auto 為中心的舊指南不應控制新的自動化。

文章變成驗收測試。如果 Codex 能：

• 載入寫作技能。
• 使用 careful-review。
• 引用目前 OpenAI 文件。
• 使用本地盤點而不暴露私有實作細節。
• 解釋 AGENTS.md、技能、掛鉤、設定檔與 MCP 的改變。
• 在站點儲存庫產出乾淨的 Markdown 文章。

那麼寫作移植就能運作。

Claude Code 到 Codex 遷移檢查清單

對 Codex 設定：

• 新增或更新 ~/.codex/AGENTS.md，放入全域工作協議。
• 新增儲存庫 AGENTS.md 公開寫作規則。
• 建立 public-writing，或把公開寫作路由到 careful-review。
• 讓 careful-review 確實對公開宣稱使用 high 或 xhigh 推理。
• 新增路由器規則，把指南、部落格文章、文件與產品文案視為公開表面工作。

對技能：

• 一次一個，把私有寫作技能移到或鏡像到 $HOME/.agents/skills。
• 在把外掛套件視為執行路徑前，先讓正在積極測試的遷移工作流程作為使用者技能。
• 使用 $skill-name 作為標準明確呼叫測試；把 /name 視為便利包裝或選擇器習慣，而不是 Codex 技能已載入的證明。
• 在 marketplace 啟用前加入套件就緒度驗證器。
• 加入本地框架健康度關口，在晉級前證明 AGENTS 引用、設定檔、技能、掛鉤、套件狀態、登錄檔形狀與啟用狀態。
• 對安裝試行，驗證 marketplace add、外掛 read/install、外掛 listing、技能 listing、新會話技能可見性與重複 marketplace 清理。
• 在允許隱式啟用前，保持試行技能僅限明確呼叫。
• 把通用寫作標準與站點專屬語氣分開。
• 把來源驗證保持為硬性事實關口。
• 把 AI 可發現性檢查與作者語氣分開。
• 建立薄站點專屬寫作者技能，而不是重用品牌專屬寫作者。
• 每次移動後確認 Codex 發現技能。

對跨代理協作：

• 讓 Codex 保持迴圈所有者。
• 把審查錨定到真實檔案或脈絡產物。
• 當錨點缺失、輸出為空或第二代理逾時時失敗即關閉。
• 用本地證據拒絕未支援的第二代理發現。
• 只接受有根據的發現，套用最小修正，重跑靜態審查，然後執行 Codex 擁有的檢查。

對掛鉤：

• 先只移植確定性檢查。
• 用 SessionStart、PreToolUse、PostToolUse 與 Stop 做窄範圍關口。
• 在加入更多關口前先記錄失敗。
• 對影子掛鉤，記錄分類而不是原始私有內容。
• 晉級前測試一個已知壞 fixture 與一個已知嘈雜 fixture。
• 在強制執行遷移檢查前，分開乾淨失敗與清理債。
• 把掛鉤視為執行環境檢查，而不是標準原則儲存。

寫作工作流程：

• 起草前先收集引用。
• 對目前 Codex 行為使用官方文件。
• 對本地盤點與經驗使用作者分析。
• 在既有內部文章已說明概念時連結它們。
• 最終前執行驗證。
• 對指南維護，驗證來源與執行環境宣稱、同步衍生公開表面、重新產生探索檔案，並命名略過的翻譯、部署與即時檢查。
• 對翻譯指南，記錄選定的翻譯供應者、差異批次或章節數、無值憑證狀態、是否發生寫入/上傳、語系驗證，以及執行被阻擋時的未寫入原因。
• 對機密與記錄衛生，分開可執行原始碼、文件、產生的快取、會話逐字稿、shell 快照、記錄與刻意保存的機密儲存；在把遷移工作流程視為安全前，先遮蔽歷史並把輔助工具轉為需要環境變數的設定。
• 部署後，在 production 驗證 canonical URL、structured data、sitemap、llms-full.txt、deployment state、CDN freshness 與 changed content markers。
• 如果 CDN cache 提供過時內容，透過既有部署路徑只清除受影響公開 URL，然後重新檢查變更標記。

FAQ

私有寫作技能需要公開嗎？

不需要。遷移文章可以描述寫作系統的形狀，而不發布私有技能名稱、提示、評分細節或品牌專屬配接器。公開教訓是那些技能應該放在哪裡，以及 Codex 應該如何啟用它們。

遷移技能也遵循同一條規則。它目前是私有的，不是開源套件。如果你想測試工作流程，請聯絡我。

Claude Code 到 Codex 遷移應該重用品牌專屬寫作者嗎？

不應該。品牌專屬寫作者應維持品牌專屬。個人或公司網站需要薄站點配接器，共享驗證標準，但不繼承另一個產品的受眾、事實或行動呼籲。

我應該把每個 Claude Code 掛鉤都複製到 Codex 嗎？

不應該。只有在識別背後契約後才複製行為。憑證封鎖屬於掛鉤。寫作評分規準屬於技能。風險規則屬於設定檔或路由器。哲學屬於 AGENTS.md 加聚焦技能。

Codex 技能應該放在哪裡？

對新的 Codex 原生工作，使用官方技能位置：儲存庫 .agents/skills 放專案技能，$HOME/.agents/skills 放使用者技能。⁴ 如果既有本地設定也使用 ~/.codex/skills，保留它，直到 Codex 探索確認新位置可運作。

為什麼 /skill 提示有時會在 Codex 失敗？

因為 /skill 不是標準 Codex 技能呼叫契約。Codex 技能會在你選取或明確提及技能時啟用，包括 $skill-name，或在任務符合技能描述時啟用。⁴ Codex CLI slash commands 是自己的內建命令表面。¹⁵ 需要確定性技能啟用時，使用 $skill-name。只把 /name 保留為便利包裝、選擇器習慣或提示短語，且它仍需自己的證明。

Claude Code 到 Codex 遷移的核心是什麼？

核心不是掛鉤、技能或設定檔本身。核心是在工作開始前回答四個問題的決策層：來的是哪一種工作、應該用哪個風險設定檔、哪些指令管它，以及完成前必須存在什麼證明？

重點整理

對 Codex 使用者： 移植契約，不要移植目錄。AGENTS.md、設定檔、技能、MCP 與掛鉤各有工作。把每條規則放在 Codex 最會直接遵守的位置。

對從 Claude Code 遷移的使用者： 把 Codex 掛鉤視為護欄，而不是成熟 Claude 分派器系統的完整替代。從 AGENTS.md 與技能開始，再在需要執行環境強制執行的地方加入掛鉤。

對公開寫作者： 部落格寫作屬於高審查設定檔。目前宣稱需要目前來源。漂亮但錯誤的文章，比壞掉的本地腳本更快損害信任。

對我自己的系統： 私有寫作系統已不只是實質移植；第一個站點專屬寫作者已分階段設為明確呼叫限定，遷移工作流程作為使用者技能啟用，私有外掛套件已通過本地安裝試行但未成為公開發布。Codex 原則現在讓品質與品味成為操作規則。最終驗證摘要保持手動影子審查，並把窄範圍確定性檢查折進既有品質 Stop 試行，而不是分離掛鉤。精簡 SessionStart 脈絡掛鉤在試行中，第一個作用中品質掛鉤以影子模式監看 apply_patch 變更，第一個 pre-Bash 安全防護作為窄範圍阻斷試行執行，引用檢查器現在作為已變更公開 Markdown Stop 試行執行，指南維護執行在真實公開文件上證明來源到渲染迴圈，一次執行修正過時精確數量宣稱而不是保留舊來源框架數字，另一次抓到產生版與服務版 AI 探索路由不一致，近期執行修正模型/參數相容性、基準/模型卡漂移、快速變動的外掛發布漂移、已渲染 FAQ 結構化資料漂移、點數計算漂移、僅第三方 API/法律/功能最低要求宣稱與 frontmatter slug 路由漂移，而最新 Codex 指南執行讓指南翻譯可選供應者，對 Codex 擁有的工作使用 Codex 作為預設供應者，在快取寫入前拒絕截斷的翻譯輸出，完成語系寫入，驗證語系路由，並用定向清除解決過時 CDN 回應，而不是默默依賴 Claude-only 路徑。一次有界機密/記錄衛生執行在記錄輪換、遮蔽與預防掛鉤缺口前，分離來源、文件、產生的快取、會話記錄、shell 快照、記錄與刻意保存的機密儲存。發布迴圈現在把本地檢查、部署狀態、CDN 新鮮度與即時變更標記證明視為分離關口。來源情報執行在私有記憶寫入前證明試跑/寫入量紀律，公司部落格導入路徑現在會在目標/路徑/intake 證據不明確時停止，不產生檔案，部落格翻譯器現在會在 D1 憑證或明確目標缺失時停止寫入執行，並在憑證存在時於發布前拒絕殘留過多的 Codex 輸出，跨代理協作迴圈證明審查/修正/重新驗證而不把權威交給第二代理，手動本地框架健康度關口會在任何更廣泛啟用前檢查確定性晉級表面。下一步是繼續證明剩餘明確呼叫限定的 production 儀式、讓公開發布邊界保持停放，並持續讓真實公開寫作與工程工作跑過分階段通道，再擴大任何關口。

參考資料