2026 年 10 月 25 日，一名使用者在 Postman 官方支援倉庫送出一份 issue，標題開宗明義寫著嚴重二字。事情經過很單純：他在 Mac 上打開久未使用的 Postman 桌面版，自己的程式碼代理（coding agent）卻跟著變了樣。Codex 反覆跳出 MCP 驗證警告，還一直把 API 工作導向 Postman skills。追查下去，發現系統多了使用者級 Postman 外掛、一段啟動指令鉤子、一條遠端 MCP 連線、一個 Claude Code 外掛，以及另外裝上的 Postman CLI。只因為打開了它，一個 API 客戶端就把自己變成其他工具的預設工作流。
原始 issue 連結如下：
https://github.com/postmanlabs/postman-app-support/issues/14370
六項證據
作者把追查過程寫得相當完整，關鍵證據有六項。第一，Postman 自己的紀錄檔寫明自動安裝：main.log 出現 source:"auto-existing-upgrade"，結果是 Codex 與 Claude 外掛雙雙裝上。第二，Codex 全域設定被改寫：config.toml 多了 Postman 的 marketplace 來源、外掛啟用旗標，以及鉤子信任雜湊。第三，鉤子把廣義 API 工作導進 Postman：啟動鉤子印出的指引寫道，回應任何非同小可的 API 工程任務之前，先載入 Postman skill 再說，範圍遠大於使用者明確說要用 Postman 的情境。第四，安裝程式明確試圖替自己的鉤子放行：原始程式碼在裝完外掛後呼叫放行函式，把雜湊寫進信任紀錄，註解寫著只放行本次安裝的 Postman 鉤子。第五，遠端 MCP 在未正常驗證下被啟用：設定指向 Postman 的 MCP 端點，Codex 紀錄檔隨即出現驗證失敗。第六，Claude Code 也被裝上，還多了一個 CLI：設定檔啟用官方外掛，使用者家目錄出現 Postman 執行檔，時間戳都落在同一安裝窗口。
作者也自我設限：排除私密路徑、帳號與憑證，只主張非預期的整合與指令變更，不主張資料外洩。重現步驟至今尚未在乾淨的 Mac 上完整重現，訴求則有六點：當成嚴重資安與同意事件處理；舊使用者自動安裝先停，改成明確 opt-in；移除安裝端自我放行，信任改由 agent host 端使用者決定；公布觸發自動安裝的版本與旗標，以及會動到哪些 agent 與檔案；給完整 rollback 與解除安裝路徑，移除後不得再次安裝；啟動 skill 的指令收斂到明確要求用 Postman 才觸發。
官方只回一句轉交內部團隊，社群不買單
這份 issue 在 11 月初被轉到 Hacker News，拿下 1201 分、392 則留言。GitHub 那一側，11 月 2 日一則只寫 Postman is a virus 的留言拿下 167 個讚，另有人質疑這種寫入行為的合法性，也有人直言企業環境無法接受這類風險。Postman 員工 foma-agent 出面回應，稱公司重視信任，已經轉交內部團隊，並請受影響使用者聯繫支援。另有一名使用者實測回報，在舊版 Codex 之下，這輪寫入的是 CLI、Claude 外掛、Codex marketplace 與外掛條目，並未出現信任雜湊，屬於版本差異，值得註記。
HN 討論連結如下：
https://news.ycombinator.com/item?id=50354960
HN 討論整理：七個主題
第一個主題是商業模式早就註定結局。最高共鳴的留言開場即指出，募資逾 4 億美元、聘用 1500 人，本該是 curl 等級的小工具。有人把 YC 世代方法論拿來對照 GNU、curl 與 ffmpeg 的書呆子 UNIX 運動，也有人補刀，無法想像 1500 人在做這個。
第二個主題是真正的資安風險。最硬的乾貨指出，Postman 會記錄每個請求的完整細節，包含 query parameter，變數送出的是解析後真值；擋掉 logging endpoint，整個 App 就不正常，調查 HIPAA 合規時得到的結論是不合規。第二手印證跟著出現：防火牆排除規則一直被擋，才發現請求經過 Postman 伺服器 proxy。也有人放進 agent 框架分析：繞過 harness 信任模型、提示詞注入、靜默註冊對外遠端 MCP。
第三個主題在企業端：不是抱怨，是 decertify。醫療業留言說資安團隊直接 decertify，整批一夜切到 Bruno。同日有人通知團隊停用並退款，直言護城河沒大到要忍受不道德甚至可能違法的行為。護城河是慣性，資安事件一破就回不去。
第四個主題是替代品清單自動長出來：Bruno（以 git 存 request 定義）、Yaak、Kreya（offline-first 加 git 格式）、JetBrains 內建 REST client、Emacs restclient 與 verb、Firefox RESTer、.http 檔加 TUI resterm。最務實的一則留言說，其實都不需要了。
第五個主題是反方唯一立足點：客戶不是開發者。BA 與測試等非技術角色需要 collections，B2B 早已是事實標準；有人指出 Postman 靠搞定 CTO 簽約，再由內部強制推行；也有人以 MongoDB 類比，開發者社群散了，企業餘生還在。
第六個主題是半小時就能 vibe-code 出來：有人用 Claude 一小時做出可用替代品，有人直接叫 AI 寫打全部 endpoint 的測試腳本，認為這樣更彈性，也有人說有了 agent 加 curl，Postman 顯得多餘。
第七個主題來自 GitHub 後續：官方回應之後的攻防，內容見上一節。正反分歧可以收斂成四句：產品是否仍被需要，B2B 慣性對上 agent 加 curl 已足夠；嚴重性如何認定，半信半疑對上明文 secret 加關不掉等同惡意軟體級；責任歸屬，募資結構必然對上 VC 與管理層主動選擇；去留抉擇，肌肉記憶對上立刻刪除、退款與 decertify。
為什麼值得關注
這起事件的特殊之處，不在於單一產品出包，而在於它踩中 agent 時代最敏感的一條線：誰有權改寫你的 agent 設定。瀏覽器外掛裝到瀏覽器裡，編輯器外掛裝到編輯器裡，大家都還能接受；但一個桌面應用跨出去改別人家 agent 的全域設定、註冊啟動鉤子、替自己的鉤子放行、再掛一條遠端 MCP 連線，等於把同意邊界整個搬走。等到 agent 真正成為工作入口，這類寫入的代價只會更高。
整理過程另有一點方法學聲明：本文基於日報抽樣 80 則、GitHub issue 全文，以及 HN 即時規模對帳（392 則含已刪），並非全樹逐則；各項數字寫的是各自抓取時間，不互抄。
懶人包
互動式懶人包如下，可直接在頁內瀏覽：
若上方嵌入無法顯示，可開備援直連：