我提供給 Codex 最好的工具是客製化的 CLI

當工具可以表達為精確的指令時，Codex 在使用工具方面的表現非常出色。

這聽起來很顯而易見，但它改變了我思考如何讓 Codex 存取我日常使用工具的方式。

Connector 或 MCP server 對於存取資料非常有用。我就是這樣使用 Slack、Linear 和 Sentry 的。但有時原始輸出的資料量太大、太雜亂，或者直接丟給 Codex 處理顯得太過笨拙。在這些情況下，我通常希望有一個輔助工具：一個帶有旗標 (flags)、穩定 JSON 格式、可預測錯誤訊息以及說明視窗的指令。

這賦予了 Codex 它本來就非常擅長使用的東西。

它可以進行搜尋、縮小範圍、重試、透過管道 (pipe) 傳輸輸出、將大型結果寫入文件、檢查 --help，並根據上一次的結果組合出下一個指令。這幾乎不需要什麼繁瑣的準備工作。

如果你只是想要這套操作手冊，我已經在這裡寫下了如何讓 Codex 建立一個這樣的工具：

建立一個 Codex 可以使用的 CLI：https://developers.openai.com/codex/use-cases/agent-friendly-clis

第一部分是使用 Codex 來建立 CLI。第二部分是將該 CLI 封裝成一個 Skill，以便未來的 Codex 執行緒知道首先要執行哪些指令、要提取多少輸出，以及哪些操作需要經過批准。

以下是我實際以這種方式使用的三個 CLI。它們並非 Connector 的替代品。當我希望 Codex 在處理大型資料來源，卻又不想將整個資料拖入執行緒時，它們就會與 Connector 並肩運作。

Codex 執行緒

我過去的 Codex 執行緒中充滿了有趣的模式，我希望從中學習並將其編碼為未來有用的 Skill 和自動化流程。

我一直讓 Codex 參考它自己的執行緒。我還有一個自動化程式，會掃描最近的執行緒，找出值得保存為 Skill 的模式。

原始的對話存檔太過雜亂，不適合直接丟給 Codex。它包含了工具輸出、部分的嘗試，以及僅在當下有用的上下文。你可以告訴 Codex 直接讀取它的執行緒。這確實可行，但如果你頻繁這樣做，速度會變慢且資訊會變得雜亂。

所以我使用了 codex-threads。

codex-threads --json sync
codex-threads --json messages search "build a CLI" --limit 20
codex-threads --json threads resolve "tweet idea"
codex-threads --json threads read <session-id>
codex-threads --json events read <session-id> --limit 50

它會在 ~/.codex/sessions 維護一個可供本地搜尋的索引，然後提供指令給 Codex 來搜尋、解析和讀取舊的執行緒。

當我想要將一個執行緒轉化為 Skill 時，這特別有用。許多優秀的 Skill 都是從「找到執行順利的那條執行緒，然後保留該模式」開始的。

Slack

當答案隱藏在一個我無法手動找到的執行緒中時，我會要求 Codex 讀取 Slack：例如為什麼會做出某個 app-server 驗證決策、其他人是否也遇到了同樣的本地開發錯誤，或者審查人員在發布頻道中已經同意了什麼。

Slack Connector 很有用，但當 Codex 擁有指令形式的工具時，重複的研究會變得更容易：

slack-cli search "app server auth" --all-pages --max-pages 3 --json
slack-cli resolve-permalink "https://openai.slack.com/archives/..."
slack-cli read-thread L143 123522523239.633199 --json
slack-cli context R152 25723525099.626199 --before 5 --after 5 --json

這讓 Codex 可以進行廣泛搜尋、解析確切的執行緒、提取周邊的上下文，並引用重要的訊息。

slack-cli 仍然使用經過批准的 Codex apps 閘道。它不是一種繞過權限的方法。它採用相同的存取模型，只是將其塑造成 Agent 可以組合的指令。

Typefully

我經常使用 Codex 來撰寫和排程內容，而我使用 Typefully 來處理這些工作。

Typefully 有一個很好的 API，但我不需要 Codex 每次在我需要草稿協助時都重新學習整個 API。我只需要我實際會用到的那幾個操作：

typefully-cli --json drafts list --social-set <id> --limit 20
typefully-cli --json drafts read --social-set <id> <draft-id>
typefully-cli --json drafts create --social-set <id> --body-file draft.json
typefully-cli --json media upload --social-set <id> ./image.png
typefully-cli --json queue schedule-read --social-set <id>

所以我讓 Codex 讀取 API 文件並建立 typefully-cli，這是一個我可以從任何儲存庫執行的輕量級 Rust 二進位檔。

圍繞它的 Skill 與二進位檔本身一樣重要。它告訴 Codex 要使用 JSON、預設建立草稿、在 Shell 引號變得麻煩時使用 body file，並且除非我明確要求，否則永遠不要發布、排程、刪除或覆寫任何內容。

最後這一點才是重點。我不希望每次請求協助撰寫貼文時，都要不斷輸入「不要發布這個」。

建立一個

有用的部分其實很簡單：如果我一直把同樣的文件、匯出資料、日誌或 API 的怪異之處丟給 Codex，我通常會希望停止解釋這些，而是直接給它一個指令。

然後，我將該 CLI 封裝成一個 Skill，這樣 Codex 就會記住如何使用它。如果你希望 Codex 為你自己的工具建立其中一個工具，我已經在這裡寫下了操作手冊：

使用案例：https://developers.openai.com/codex/use-cases/agent-friendly-clis

$cli-creator：https://github.com/openai/skills/tree/main/skills/.curated/cli-creator