一個只放了單一檔案、九行 Express 程式碼的儲存庫，丟進新版 Codex Security CLI 後，掃描在 8 分半鐘後撞上 $6.00 預算上限而停止。它消耗了 700 萬 input tokens，產出一份 1,605 字的威脅模型，漏洞發現則是零。打算把它接進 CI 的人，先記住這個結論：掃描成本取決於 agent 的推理迴圈，不是程式碼行數；第一個該設定的選項是 --max-cost。
不過，這個工具依然值得研究。這是第一個不必把儲存庫交給 GitHub App，也能自行執行的 Codex Security 版本。
Codex Security CLI 能做什麼，又不做什麼
Codex Security 並不是新產品。OpenAI 在 2026 年 3 月將它以研究預覽形式推出，當時是託管服務：連接 GitHub 儲存庫後，它會建立威脅模型、在隔離環境掃描提交紀錄，並在 ChatGPT 工作區回報發現。SecurityWeek 報導，它提供給 ChatGPT Pro、Enterprise、Business 與 Edu 客戶使用。
2026 年 7 月 28 日推出的是另一回事。openai/codex-security 是採用 Apache-2.0 授權的 CLI 與 TypeScript SDK，發布至 npm時，版本為 0.1.0，時間是 17:09 UTC；同日 23:48 UTC 隨後推出 0.1.1。撰文當下，它有 1.8k stars 與 28 個未關閉 issue。這是個剛上線第一天的專案。
安裝需要 Node.js 22 以上與 Python 3.10 以上，因為掃描引擎是隨套件附帶的 Python plugin：
npm install @openai/codex-security
npx codex-security info想快速確認安裝到什麼版本，直接執行 info：
sdkVersion: 0.1.1
bundledPluginVersion: 0.1.14
cliVersion: 0.1.1
codexVersion: 0.144.6
model: gpt-5.6-sol
reasoningEffort: xhigh成本的關鍵就在最後兩行。這次安裝環境預設以 GPT-5.6 Sol 搭配 xhigh 推理強度執行掃描。雖然可用 --model 覆寫模型，但 plugin 的設計核心是深度 agentic loop，而真正計費的正是這個迴圈。
CLI 提供的功能比託管版看起來更多：scan、validate、patch、scans（列出、顯示、重新執行、比對、比較）、bulk-scan、匯出為 CSV、JSON 或 SARIF 的 export、install-hook，以及將工具註冊為 MCP server 的 mcp 模式。值得留意的是，info 也會顯示 scanMcp: false，原因是無法透過 MCP transport 取消掃描。
兩種驗證方式，以及真正可能卡住你的那一關
npx codex-security login 可使用 ChatGPT 帳號登入，--device-auth 適用於無頭機器，CI 則可用 OPENAI_API_KEY。若 API key 與登入狀態同時存在，互動式掃描會詢問你要使用哪一種；非互動式執行則優先採用 API key。
官方文件有一項提醒必須仔細看：完整儲存庫掃描可能還需要 Trusted Access for Cyber。登入或設定 API key 都不會自動取得這項權限，因此該預期的是提出存取申請，而不是完成登入就能使用。
讓 OpenAI Codex Security CLI 對接相容端點
最先會碰壁的做法，就是把 OPENAI_API_KEY 設成第三方金鑰，然後期待流量自動送往該服務：
codex-security: Authentication failed using OPENAI_API_KEY.只換 key 不會改變目的地，因為內嵌的 Codex runtime 依然指向 OpenAI 自己的 base URL，也會忽略 OPENAI_BASE_URL。要透過接受 TOML 值的 --codex 覆寫 provider 設定：
OPENAI_API_KEY=sk-... npx codex-security scan . --auth api-key --max-cost 5 \
--codex 'model_provider="relay"' \
--codex 'model_providers.relay.name="relay"' \
--codex 'model_providers.relay.base_url="https://your-endpoint/api/v1"' \
--codex 'model_providers.relay.env_key="OPENAI_API_KEY"' \
--codex 'model_providers.relay.wire_api="responses"'有兩個細節各讓我浪費了一次執行。值沒有加引號會出現 Invalid --codex TOML value。另外，Codex 0.144.6 會直接拒絕 wire_api="chat"，錯誤訊息指向討論串 #7782，並要求使用 responses。你的端點必須實作 Responses API，而不只是 Chat Completions。
模型費用最後落在哪裡，也由同一項設定決定。無論實際指向哪個端點，CLI 一律以 GPT-5.6 Sol 的 OpenAI 定價估算成本，因此畫面上的累計額是 token 數量計算，不是你的實際帳單。假設同一批流量改走價格只有定價一半的端點，下方 $6.03 的那次執行實際約為 $3，但 CLI 仍會顯示 $6.03。
一次掃描的實際成本
先附上一個前提：五次測試全都經由第三方 OpenAI 相容端點執行，因為我沒有 ChatGPT Business 或 Enterprise 登入帳號可測試官方路徑。以下測量的是一般開發者今天能實際使用的 CLI 行為，不代表擁有權限帳號時託管服務的表現。
測試用儲存庫刻意做得很小，也刻意保留問題：九行程式碼，埋了四個缺陷。
const express = require('express');
const { exec } = require('child_process');
const db = require('./db');
const app = express();
const API_KEY = "sk-live-9f3a2b7c1d4e5f6a8b9c0d1e2f3a4b5c";
app.get('/u', (req, res) => db.query("SELECT * FROM users WHERE id = " + req.query.id, (e, r) => res.json(r)));
app.get('/ping', (req, res) => exec("ping -c 1 " + req.query.host, (e, o) => res.send(o)));
app.get('/f', (req, res) => res.sendFile(__dirname + "/files/" + req.query.name));
app.listen(3000);問題包括字串串接的 SQL、直接將 query parameter 傳給 child_process.exec、未消毒的 sendFile 路徑，以及硬編碼金鑰。環境為 macOS、Node v22.17.0、Python 3.14.6、@openai/[email protected]、內附 plugin 0.1.14；所有測試均在 2026-07-29 02:20 至 03:05 UTC 之間執行。
| 執行 | 目標 | 預算 | 停止時成本 | 耗時 | 快取 input | 新增 input | Output | 發現 |
|---|---|---|---|---|---|---|---|---|
| 1 | 完整儲存庫，標準模式 | $1.00 | $1.46 | 3m23s | 1,092,608 | 121,396 | 10,300 | 0 |
| 2 | 完整儲存庫，標準模式 | $6.00 | $6.03 | 8m33s | 6,654,720 | 331,330 | 34,946 | 0 |
| 3 | 工作目錄，一行 diff | $3.00 | $3.06 | 9m46s | 2,035,712 | 240,448 | 28,120 | 0 |
| 4 | 完整儲存庫，完整專案 | $8.00 | $8.54 | 8m00s | 7,299,840 | 634,419 | 57,223 | 0 |
| 5 | 完整儲存庫，reasoning_effort=low | $3.00 | $3.20 | 4m13s | 1,749,248 | 366,841 | 16,269 | 0 |
這些金額是 CLI 在掃描過程中顯示、並記錄於 scans list 的估算值。它們以 OpenAI 定價與 token 數量計算，並非端點實際收取的費用；而快取 input 正是總額看似低於 token 數量直覺的原因。以第 2 次執行為例，若按每百萬新增 input $5.00、快取 input $0.50、output $30.00 計算，結果完全吻合：
331,330 x $5.00/M = $1.657
6,654,720 x $0.50/M = $3.327
34,946 x $30.00/M = $1.048
------
$6.032 (CLI 回報 $6.03239)同一組費率可將五次執行的總額都重算至分，若你自己的數字看起來不對，這是個實用的交叉檢查方式。
五次掃描沒有一次完成。它們全都因預算中止，且 scans list 將每次執行標記為 phase: preflight, status: failed，並顯示 coverage: worklistRows 0；也就是沒有任何一次進入回報漏洞的階段。
第 4 次是對照組。最初的儲存庫刻意不完整：沒有 package.json，且匯入了不存在的 ./db，工具自身的威脅模型將此列為明確未知項目。重建為有四個檔案、十三行程式碼並宣告相依套件的完整專案後，成本沒有降低，反而升至 $8.54 與 790 萬 input tokens。
成本曲線並非線性。前 3 分鐘緩慢增加，接著兩次階梯式跳升；每次跳升都對應 agent 擴大工作範圍。日誌在第 51 秒揭露了原因：Preflight: worker delegation supported (up to 8 worker slots)。
95% 的 input tokens 都是快取讀取，表示同一份 context 一輪又一輪重送，而不是每次重新讀取。單價雖低，卻依然是帳單中最大的一項。即使套用快取 input 費率，700 萬 tokens 對九行程式碼而言依然會累積成可觀金額。
這也說明為何廣為流傳、約每 1,000 行程式碼 $0.02 的估算在此完全失效。按照這個費率，我的儲存庫成本應該連一美分的一小部分都不到。
調低推理強度，幫助沒有預期中大
第 5 次在與第 4 次相同的專案中設定 model_reasoning_effort="low"。Token 消耗從每分鐘約 100 萬降至約 50 萬，因此同樣的金額可換得兩倍實際時間。但它仍在同一個 preflight 階段撞上上限，沒有任何結果可回報。若整個流程不論如何都需要超出預算的輪數，把消耗率減半也無法解決問題。
--max-cost 是檢查點，不是煞車
官方 CLI 文件表示，已經進行中的請求可能在超過上限後才完成。但文件沒有說明可能超出多少；五次測試中，超支幅度介於 0.5% 到 46%：$1.00 上限實際停在 $1.46，$6.00 上限停在 $6.03，其餘三個中間區間的上限則超出 2% 至 7%。超支多少取決於 agent 當時已送出的工作，因此接近上限時發生 worker fan-out 是最昂貴的情況。你無法承受超過多少，就應把上限設在那個數字以下。
Pre-commit 並不是省錢捷徑
完整掃描成本失控時，最直覺的解法就是只掃描變更內容。我先提交乾淨的基線版本，再加入一行有漏洞的程式碼，也就是以字串串接建立的 LIKE 子句，然後執行 --working-tree --base HEAD。
它比第一次完整掃描還要貴：花費 9m46s、2,276,160 input tokens，面對 $3.00 上限時在 $3.06 停止。它確實比完整掃描更深入流程，在預算耗盡前寫出了排序後的審查工作清單（rank_input.jsonl、deep_review_input.jsonl），但依然沒有產生任何發現。限制為 diff 並不會縮小每一輪的 context：agent 還是會讀取儲存庫、建立完整威脅模型、再分派給多個 worker。
install-hook 能將它接入 Git pre-commit hook，並在偵測到高嚴重性發現或掃描錯誤時阻擋提交。要在團隊導入前，先在自己的程式碼庫為單次 diff 掃描定價；因為這個 hook 可能替每次 commit 增加數分鐘與數美元的成本。
它目前仍看不見的問題
這個工具替九行程式碼產生的威脅模型其實做得不錯。它辨識出四個信任邊界，把缺少的 ./db 模組標記為明確未知項目，也不會在無法驗證時自行認定 Express 提供了保護。它還清楚寫出自身限制：「Controls not present in the repository must not be assumed.」
這就是結構性的限制。它唯一的輸入是原始碼，因此部署時才決定的事情都看不見：CORS policy、未關閉的 debug mode、脆弱 TLS、缺少 security headers、cache poisoning，以及跨服務的執行期授權。尤其物件層級授權漏洞，需要以兩個真實身分發出已驗證請求才能確認；光靠閱讀原始碼無法取得這種證據。
不同語言的分析深度似乎也不平均。一篇使用託管服務的實務文章指出，Python、JavaScript、TypeScript、Go 與 Java 的支援最強，Ruby、PHP 與 Kotlin 則落後一些。我只測試了 JavaScript，因此這部分請視為轉述資訊。
值不值得現在就用？
若你想取得威脅模型，今天就可以安裝。這是每次執行我都確實收到的唯一產物：一份 1,605 字文件，整理信任邊界、列出攻擊者情境，並針對這個特定服務定義 critical、high、medium 與 low 的意義。它也能作為其他安全工具的輸入，因為 --knowledge-base 接受自行提供的架構文件，生成的模型也可以編輯。
若你需要可預測的支出，或真正的漏洞發現清單，建議先等。在五種設定下，我兩者都沒有得到；一個十秒就能讀完的儲存庫，每次掃描卻花了 $1.46 到 $8.54。流程較後段文件提到的輸出，包括 findings.json、coverage.json 與 report.md，我一次都沒能走到。具備權限的 ChatGPT Business 帳號是否會有不同表現，是這些測試無法回答的未解問題。
這次測試中，兩個顯而易見的成本控制手段都沒有效：縮小至 diff 與降低推理強度，最後都撞上同一面牆。唯一能改變計算結果的是模型費率；估算值是根據定價的 token 數量算出，因此費率為定價一半的端點，會讓同一次執行的實際成本減半。預算應根據實測執行結果，而不是儲存庫大小；同時，上限應低於你的真正極限，並預留一輪 worker 的緩衝，我遇過最嚴重的超支是上限的 46%。
FAQ
Codex Security CLI 是免費的嗎？
CLI 與 SDK 採 Apache-2.0 授權，安裝不需費用，但掃描並非免費。它會透過你驗證使用的憑證消耗 GPT-5.6 Sol tokens，CLI 也會按照 OpenAI 定價持續顯示預估成本。
我需要 ChatGPT Business 或 Enterprise 方案嗎？
若使用託管的 GitHub 整合，需要：該路徑僅限 Pro、Enterprise、Business 與 Edu。CLI 可接受一般的 OPENAI_API_KEY，但文件提醒完整儲存庫掃描仍可能需要 Trusted Access for Cyber，而任何方案都不會自動授予這項權限。
它可以在 CI 中執行嗎？
可以。設定 OPENAI_API_KEY，加入 --fail-on-severity 讓發現項目以非零 exit code 結束，並將 CODEX_SECURITY_STATE_DIR 指向儲存庫外可寫入的路徑。掃描預設只產生報告，不會修改內容。
它支援第三方 OpenAI 相容端點嗎？
支援，前提是該端點實作了 Responses API。你必須使用 --codex flags 覆寫 Codex provider 設定，因為只設定 OPENAI_API_KEY 會導致驗證失敗。
CLI 與 Codex Security plugin 有何不同？
掃描引擎相同，進入方式不同。plugin 在 OpenAI 基礎設施上，針對已連接的 GitHub 儲存庫執行；CLI 則在你的機器上，針對本機路徑執行，掃描歷程保存在本機 state directory，另外提供限定 diff 的掃描、pre-commit hook、SARIF 匯出與 MCP 註冊功能。
延伸閱讀： GPT-5.6 pricing guide · Codex auto mode