Postman 桌面版在二零二六年十月二十四日的一次啟動中，未經確認便向 Codex 與 Claude Code 安裝外掛，並寫入啟動 hook 的信任雜湊。編號 14370 的公開 issue 以日誌與原始碼佐證整個流程，指出安裝器會自行批准自己寫入的 hook，官方至今未回覆。
事件由一名 macOS 使用者提出。他在十月二十五日發現 Codex 反覆出現 MCP 驗證警告，並且 API 相關任務總是被導向 Postman 的技能檔，於是翻查本機日誌與全域設定，最終把整條安裝鏈完整記錄下來。
這份紀錄的價值在於時間戳與路徑齊全。它沒有停在「感覺被改動」，而是指出哪一段日誌、哪一個設定檔、哪一行原始碼造成改動，讓其他使用者可以自行核對。
Postman 自動安裝了哪些外掛？
日誌顯示安裝器一次裝上 Codex 外掛 1.1.0、Claude Code 外掛 2.0.1 與命令列工具，並啟用指向 mcp.postman.com 的遠端連線。
Postman 自身的日誌檔案記錄了這次安裝。時間戳為二零二六年十月二十四日九時三十四分十四秒，內容寫著外掛服務完成腳本安裝，來源標記為既有使用者升級，結果欄列出 Claude Code 與 Codex 兩個項目都已安裝。
同一段時間，使用者家目錄下的命令列工具目錄出現 Postman 執行檔與其函式庫，修改時間與安裝窗口吻合。Claude Code 的外掛清單也記錄了版本 2.0.1、使用者層級範圍與相同的安裝時刻。
三處改動指向同一個觸發條件：使用者只是開啟了一個已經安裝的桌面程式。
事件是如何被發現的？
使用者先察覺 Codex 反覆要求 MCP 驗證，再發現 API 任務被導向 Postman 技能，於是回溯日誌與設定檔，把證據固定在十月二十五日。
最初的症狀相當間接。Codex 啟動時出現與 Postman 相關的驗證失敗訊息，日誌寫著連線初始化需要授權，而使用者從未主動連結過該服務。
第二個症狀是行為偏移。處理 API 設計或測試工作時，代理會載入 Postman 的技能檔，即使在對話中沒有提及這個工具。
使用者沿着這兩個線索檢查全域設定，在 Codex 的設定檔中發現三個新增區塊：外掛市集來源、外掛啟用旗標，以及一個帶有雜湊值的 hook 信任紀錄。
自動寫入的 hook 做了什麼？
該 hook 在每次啟動、清除與壓縮對話時輸出指令，要求代理在處理任何非簡單 API 工作之前先載入 Postman 的 api-engineer 技能，範圍遠超使用者授權。
外掛註冊了一個工作階段啟動指令，觸發條件涵蓋啟動、清除與壓縮三種情境。每次觸發時，它會輸出一個情境檔案，把指示注入代理的上下文。
該檔案的措辭相當寬鬆。它要求在設計、實作、模擬、測試、監控、文件撰寫或部署 API 之前，先載入 Postman 的 API 工程師技能並依從其內容。
這解釋了行為偏移的來源。使用者沒有要求使用 Postman，但代理每次開場都收到一則指向該工具的常駐提示。
安裝器為何能自行批准 hook？
安裝器原始碼在安裝完成後呼叫批准函式，先讀取 hook 清單取得雜湊，再以批次寫入方式把信任值寫進設定，註解寫明只批准自己當前版本的 hook。
問題的核心落在信任邊界。多數代理工具要求使用者明確批准 hook，因為 hook 可以注入任意指令，等同取得該工具的執行權。
在這次事件中，批准動作由安裝器自己完成。原始碼顯示它先透過 hook 清單取得雜湊，再以批次寫入介面更新信任狀態。
提出 issue 的使用者對此保持克制。他明確表示，信任紀錄本身無法證明是哪一次互動產生，因此不宣稱使用者曾經按下批准；他主張的是安裝器具備自我批准的能力。
對開發者工作流程有什麼實際影響？
影響集中在三方面：代理行為被常駐指令偏移、遠端 MCP 連線在未授權狀態下反覆重試、企業環境多出一條無法稽核的設定變更來源。
第一項影響是隱性偏好。代理在處理 API 工作時傾向使用特定廠商的技能與流程，使用者難以察覺這種傾斜從何而來。
第二項影響是雜訊。遠端 MCP 端點需要授權，在未完成授權前每次啟動都會產生失敗紀錄，掩蓋真正的錯誤訊息。
第三項影響是合規。企業環境對開發工具的外掛來源通常有清單管制，一個由桌面程式自行寫入的市集來源與 hook 信任值，會落在既有稽核流程之外。
使用者可以如何檢查與移除？
先查 Codex 設定檔有無 postman 市集與 hook 信任紀錄，再查 Claude Code 的外掛清單與命令列目錄，逐項移除後重新啟動代理確認。
檢查應由設定檔開始。Codex 的設定檔若出現 postman 市集來源、啟用旗標或含雜湊的 hook 狀態，即代表曾經被寫入。
Claude Code 方面，需檢視設定檔的外掛啟用清單與已安裝外掛紀錄，並確認使用者層級目錄下是否殘留 Postman 相關檔案。
移除後建議重新啟動代理並觀察開場訊息。若仍見到指向 Postman 的技能載入提示，代表快取或 hook 紀錄尚未清除乾淨。
Postman 目前回應了什麼？
截至十一月三日，該 issue 維持開啟狀態，累積三十五個表情回應與五則留言，其中二十五個為贊同、七個為困惑，官方尚未張貼任何回覆或標籤。
表情回應的分佈值得注意。二十五個贊同與七個困惑並存，顯示部分讀者理解問題嚴重性，另一部分仍在判斷這是否屬於正常整合行為。
留言語氣相當直接。有人以病毒作比喻，有人質疑合法性，也有人把焦點放在企業環境的風險，認為這類自動改動在受管制的機器上無法接受。
提出 issue 的使用者列出六項具體要求，包括停止對既有使用者自動安裝、移除安裝器的自我批准能力、公開觸發旗標、提供完整回滾路徑，以及收窄啟動指令的適用範圍。
出處連結有哪些？
資訊來自 Postman App Support 儲存庫的 issue 14370，以及該 issue 引用的外掛原始碼與 hook 設定檔，版本已固定於特定修訂。
- issue 原文：postmanlabs/postman-app-support#14370
- 外掛儲存庫：postmanlabs/postman-plugin
- hook 設定：hooks/codex-hooks.json
- 啟動情境檔：hooks/session-start-context.md
- 批准邏輯：installer/src/hosts/codex-hooks.ts
常見問題有哪些？
以下五個問題涵蓋資料外洩疑慮、受影響版本、企業環境處理方式、代理工具的一般風險，以及同類事件的判別方法。
這次事件是否涉及資料外洩？
提出 issue 的使用者明確表示沒有此結論。他記錄的是未經同意的整合與指令變更，並在文中說明證據不足以證明資料被傳送。相關帳號識別碼與憑證亦已從公開內容中移除。
哪些版本與平台受到影響？
紀錄中的環境為 macOS，Postman 桌面版 12.33.4，Codex 外掛 1.1.0，Claude Code 外掛 2.0.1。外掛本身以跨平台方式發布，其他作業系統是否出現相同升級行為，仍需以各自日誌核對。
企業環境應該如何處理？
建議把開發代理的外掛市集與 hook 信任狀態納入端點設定基線，並在桌面應用程式升級後重新比對設定檔差異。對於受管制機器，可考慮以設定管理工具鎖定代理的設定檔路徑。
代理工具的外掛為何需要額外審視？
外掛可以註冊 hook，hook 在使用者工作階段開始時執行並注入指令，等同取得代理的行為控制權。因此外掛來源與 hook 信任值屬於高權限設定，變更應由使用者決定。
如何判斷其他工具是否有同類行為？
可比較安裝前後的設定檔快照，重點檢查外掛市集、啟用旗標與 hook 信任紀錄三個區塊。若出現未曾授權的市集來源或雜湊值，即值得進一步追查。
總結：這宗事件對代理工具生態意味什麼？
桌面工具與代理工具的界線正在重疊，安裝一個應用程式可能同時改動另一個工具的設定。事件顯示同意機制若由安裝方自行完成，使用者將失去判斷依據。
對使用者而言，可行的做法是把設定檔納入例行檢查。每次桌面工具大版本升級後，比對代理設定檔的差異，比事後追查行為偏移容易得多。
對工具開發者而言，這次爭議提供一條清楚的界線。整合可以是選項，但不應該在使用者只開啟程式的情況下自動完成，尤其是涉及 hook 信任這類高權限設定。
issue 仍處於開啟狀態，官方尚未回應。後續是否調整安裝流程，將決定這宗事件停留在個案，還是成為同類整合的參考判例。
