BBT for BBT 繁體中文

Posted on Nov 7

把 Codex CLI 當成 osFoundry 的 worker 來跑

#codex #osfoundry #cli #tutorial

做完這些設定後，osFoundry 桌面 App 裡的某個 agent 會以 cli:codex:agent 作為模型。工作交到它手上時，App 會在你的 Mac 上用你自己的 ChatGPT 登入啟動 codex exec。執行只會發生在你允許的資料夾裡。Codex 回報的內容，包括它的推理、執行過的指令和最後的訊息，都會以一行一行的形式出現在 osFoundry 的執行紀錄中。整個過程完全用不到 OpenAI API key。

誰負責什麼

	Codex CLI	osFoundry
登入	自己的 ChatGPT 登入（`codex login`），由 Codex 保存	完全不碰。從子行程的環境中移除 `CODEX_API_KEY`、`OPENAI_API_KEY` 和 `OPENAI_BASE_URL`，讓執行維持在訂閱方案上
模型呼叫	由 `codex` 行程直接送往 OpenAI	成本記為 `0.0`（訂閱制，不按量計費）
工具	自己的 shell 和檔案編輯，限於工作資料夾內	自己的工具（例如 `memory_search`），透過 `127.0.0.1` 上的 loopback MCP bridge 提供，而且只在 git worktree 隔離該次執行時才提供
核准	執行途中沒有：`exec` 是非互動式，`approval_policy="never"`	每一次經過 bridge 的工具呼叫都會通過 `orchestrator::execute_tool` 及其政策關卡
輸出	每個完成的 item 在 stdout 輸出一個 JSON 事件（`--json`）	把每個事件轉成進度行或回答文字；保留 stderr 尾端供錯誤訊息使用
你的檔案	在資料夾或 worktree 中讀寫	由它決定資料夾：Code 畫面的 repository，沒有的話就用你第一個允許的本機資料夾

設定

安裝 Codex CLI 並登入一次。osFoundry 會在 PATH、~/.codex/bin 以及 /Applications/Codex.app 裡尋找執行檔（用 cask 安裝時，執行檔會放在 Contents/Resources/codex，which codex 找不到它）。

   codex login

打開標頭列的鑰匙圖示（提示文字是 API Keys (BYOK)），切換到 External AI（外部 AI）分頁。Codex 那一列會顯示 Installed、No live stream 標章，以及自主模式的模型 id。Codex 沒有聊天用的 id，所以只會出現一個 id：

   Codex   Installed   No live stream   Enabled
   cli:codex:agent (autonomous)
   osFoundry tools require git-worktree isolation for Codex (it trades its
   own sandbox for git safety). Point it at a git repo folder.

範例：External AI 分頁中的 Claude Code 與 Codex

如果還沒登入，按下 Sign in 按鈕會開啟一個執行 codex login 的終端機。

點擊 Verify sign-in（確認登入）。它會透過與正式執行相同的 builder，跑一次極小的 completion：

   codex exec "Reply with the single word: ok" \
     --json --skip-git-repo-check --ignore-user-config --ignore-rules \
     -s read-only -c 'approval_policy="never"'

只有在 codex exec --help 列出 --ignore-rules 時才會加上它。osFoundry 直接詢問執行檔，是因為舊版會拒絕這個旗標，導致整次執行失敗。

給 agent 一個資料夾。在 Settings → Local Folders 新增一個。如果也想讓 Codex 用到 osFoundry 自己的工具，就把這個資料夾設成 git repository，並在 Code 畫面點擊 Enable for this workspace。之後每次執行都會有自己的分支和工作副本。
在 Studio 打開 agent，設定 Model Preference。選單會在 CLI agents 區塊中以 cli:codex:agent 列出 Codex（provider 顯示為 "External AI (subscription)"）。如果這個 agent 要負責 worker 步驟，就把 Runtime Role 設為 worker。

工作交付時，指令長這樣。沒有 worktree 時，會保留 Codex 自己的 sandbox：

codex exec "<system prompt>

User: <task>" \
  --json --skip-git-repo-check --ignore-user-config --ignore-rules \
  -C /path/to/folder -s workspace-write -c 'approval_policy="never"'

有 worktree 時，sandbox 旗標會被替換，並接上 bridge：

codex exec "<system prompt>

User: <task>" \
  --json --skip-git-repo-check --ignore-user-config --ignore-rules \
  -C /path/to/worktree \
  --dangerously-bypass-approvals-and-sandbox \
  -c 'mcp_servers.osfoundry.url="http://127.0.0.1:<port>/mcp"' \
  -c 'mcp_servers.osfoundry.http_headers={Authorization="Bearer <per-run token>"}'

Codex 沒有加入 system prompt 的旗標，所以 osFoundry 會把 agent 的 system prompt 放在對話前面，中間隔一個空行。先前的對話輪次接在後面，以 User: / Assistant: 逐字稿的形式呈現。

一次執行

範例。以下是 Codex 寫出的事件行，以及 osFoundry 據此顯示的行。文字僅供說明，但事件類型和行的格式都是程式碼實際對應的那些。

$ codex exec … --json
{"type":"item.completed","item":{"type":"reasoning","text":"Check what the tests cover first."}}
{"type":"item.completed","item":{"type":"mcp_tool_call","server":"osfoundry","tool":"memory_search"}}
{"type":"item.completed","item":{"type":"command_execution","command":"npm test"}}
{"type":"item.completed","item":{"type":"file_change","path":"src/date.ts","change":"edit"}}
{"type":"item.completed","item":{"type":"agent_message","text":"Fixed the off-by-one in parseRange; 42 tests pass."}}
{"type":"turn.completed","usage":{"input_tokens":…,"cached_input_tokens":…,"output_tokens":…}}

osFoundry run
  Thinking: Check what the tests cover first.
  Using memory_search…
  Using shell — npm test
  Edited src/date.ts
  Fixed the off-by-one in parseRange; 42 tests pass.

Codex 用 server 和 tool 兩個欄位來標示經過 bridge 的工具，所以那一行顯示的是不帶 mcp__osfoundry__ 前綴的 memory_search。回答是以完整的 agent_message item 送達，而不是逐 token 送達。進度行會在 Codex 還在工作時一行一行出現；每則訊息的文字則要等 Codex 寫完那則訊息後才會出現。token 數量取自 turn.completed，其中 input_tokens 不含快取的部分，因此 osFoundry 會把 cached_input_tokens 加回去，得出 context 大小。

界線在哪裡

沒有 cli:codex 這種聊天模式。Codex 的設定裡沒有關掉 shell 工具的開關，所以透過 Codex 做的「無工具 completion」實際上仍是一個帶著 shell 的 agent。osFoundry 不會默默照跑，而是直接拒絕聊天 id："codex has no tool-less chat mode — use 'cli:codex:agent' for an autonomous run instead."

-s 是針對檔案系統和指令的 sandbox。workspace-write 限制 Codex 能寫入的位置，以及它的指令能做的事。它不限制模型可以呼叫哪些工具，而 Codex 也沒有類似 --disallowedTools 的東西。因此，把 Codex 加進 channel 時，Add agent 面板會提示在這個 harness 上無法強制套用工具範圍。

osFoundry 的工具需要 worktree。在非互動式的 exec 中，除非同時繞過核准和 sandbox，否則 Codex 會取消每一次 MCP 工具呼叫。逐工具的核准模式、受信任的專案、approval_policy="never"，結果都一樣會被取消。所以 App 只做一個交換：只有在 git 隔離取而代之時，才放棄 Codex 的 OS sandbox。沒有 worktree 時，執行維持 -s workspace-write，不接 bridge，執行紀錄中也會有一行說明這件事。

你自己的 Codex 設定不會被帶進來。--ignore-user-config 會跳過 ~/.codex/config.toml，所以你替自己設定的 MCP server 不會混進 osFoundry 的執行。驗證資訊仍然從 CODEX_HOME 載入。--ignore-rules 也會把 .rules execpolicy 檔案排除在外。

每次執行都有實際時間上限：自主執行 1,800 秒，登入檢查 300 秒。時間一到，子行程就會被丟棄並終止。

接下來

讓 agent 指向一個小型 git repository，為 workspace 啟用 code agent，再給它一個同時需要 shell 指令和 osFoundry 記憶內容的任務。這樣就能看到 Using shell 和 Using memory_search… 出現在同一次執行中。Studio agents 頁面說明了 Model Preference 的位置，桌面版則可以在下載頁面取得。

DEV Community

把 Codex CLI 當成 osFoundry 的 worker 來跑

誰負責什麼

設定

一次執行

界線在哪裡

接下來

Top comments (0)