npm 新增「只送審」權杖：自動化不能直接發版，免 2FA 直接發版預計 2027 年 1 月移除

2026 年 9 月 18 日（美國太平洋時間），GitHub 在官方異動紀錄宣布，建立 npm 細緻權限存取權杖（granular access token）時，多了一個可選的權限等級 Read and write (stage only)：讓自動化流程把新版本送進待審區，卻不把「直接發布到 npm registry」的權限交給這個權杖，放行上架改由套件維護者以 2FA 核准。

本文於 2026 年 9 月 20 日查核，讀的是這則 GitHub Changelog 全文、npm 說明中心的 About access tokens 與 Staged publishing 兩頁，以及 7 月 31 日那則先預告 2027 年時程的較早公告。本站沒有登入 npm 帳號，也沒有建立權杖或跑過送審流程；下文不做「該不該換權杖」的建議，只整理官方頁面寫出來的條件與時程。

9 月 18 日公告了什麼：一個新的權限等級

GitHub 把這則公告歸在「supply chain security（供應鏈安全）」標籤底下，說明寫得很直接：自動化流程用 npm stage publish 送出版本，套件維護者再以雙因素驗證（2FA）複查並核准發布，兩個動作分屬不同角色、不同權限。這種設計是要在不擋住自動化的前提下，把「誰能真的把套件推上 registry」收回到一個會被 2FA 保護的人身上。

這則公告最關鍵的一句限制是：只送審權杖直接呼叫 npm publish 會被 npm 拒絕，即使這個權杖被設定成可以略過 2FA 也一樣。也就是說，「略過 2FA」這個選項這次不會讓自動化流程繞過送審這一關；官方同時提醒，只送審權杖仍然要和其他任何寫入權杖一樣小心保管。

這次更新是 opt-in，要自己建立一個新的只送審權杖才會用到；官方寫明這一版不會動到任何既有權杖，也不會拿掉既有權杖直接發布的能力。換句話說，工作流程如果不主動更換權杖類型，9 月 18 日之後仍會照舊運作。

送件、複查、放行三步，以及權杖還能做什麼

官方列出換成只送審權杖的三個步驟：替工作流程需要的套件建立一個 Read and write (stage only) 權杖；把工作流程裡的發布權杖換成這一個，指令從 npm publish 改成 npm stage publish；再請一位維護者用 2FA 複查、核准待審版本。npm 說明中心把兩種讀寫等級並列：Read and write (publish and stage) 可以直接把新版本發布到 registry，Read and write (stage only) 不能直接發布，而是送去待審，由維護者複查後「拔擢」（promote）上架。

只送審權杖不是被拿掉所有寫入權限。npm 說明頁列出它能做的三件事：用 npm stage publish 送出待審版本、把版本標記為棄用（deprecate）、搬移 dist-tag；不能做的只有直接發布新版本——硬發會拿到 E_STAGE_REQUIRED 錯誤。維護者核准時用 npm stage approve 指令搭配 stage-id 與 --otp 參數拔擢上架，或用 npm stage reject 指令丟掉；這幾份官方說明頁沒有寫丟掉後會不會通知，也沒寫保留期限。

為什麼是「送審」而不是「禁止」

2FA 落在核准那一步，不是送件那一步：npm 說明頁寫明 npm stage publish 不需要 2FA，需要 2FA 的是維護者核准的那個動作。說明頁把只送審權杖稱為自動化（例如 CI/CD）比較安全的入口——送件這一步不必過 2FA，要 2FA 的是核准那一步，人與機器的分工就落在這裡。

官方自己也把話講死：只送審只限制新版本的直接發布，它不是一道通用的安全邊界。這句話值得留意——只送審權杖同時保有搬移 dist-tag 與標記棄用的權限，說明頁自己寫明這道限制只收窄了直接發布的風險，並沒有另外限制這個權杖其他的寫入能力，所以它能做的事仍然不只是送件。

另一個容易被忽略的門檻：只送審發布只對已經存在的 npm 套件有效，全新的套件不能用這個方式送審。也就是說，要用這個機制的前提是這個套件本來就已經在 npm registry 上；一個團隊如果要發布全新套件的第一個版本，就走不了這條送審路徑。

2027 年 1 月的預告怎麼讀

2027 年 1 月這個時程不是這次才提出來的。GitHub 在 2026 年 7 月 31 日較早的一則 changelog 就寫著「以 2027 年 1 月為目標」，要讓免 2FA 權杖失去直接發布的能力，發布面縮到只剩讀取私有套件與送出待審版本（再由維護者以 2FA 核准）兩件事；9 月 18 日這則公告又重申一次同樣的目標月份，並寫明「如先前所公告」。

7 月 31 日那一次已經先動一步：設定成略過 2FA 的細緻權限存取權杖，不能再做敏感的帳號、組織與套件管理動作，這些動作改成一律要通過互動式的 2FA 驗證；npm 說明頁講這一類限制時寫的是自 2026 年 8 月起，並列出改 email 或密碼、改動或停用 2FA 設定、建立與管理權杖、增刪套件維護者等項目。7 月 31 日那則也把範圍寫得很清楚，只影響 npm 的細緻權限存取權杖，不影響 GitHub 個人存取權杖、GitHub App 權杖，也不影響 Actions 裡的 GITHUB_TOKEN。

官方頁面講 2027 年這一項時用詞不完全一致：兩則 changelog 都寫「targeting」（以……為目標），範圍限定在「免 2FA 權杖的直接發布」；About access tokens 說明頁卻寫成「will be removed」（會被移除），主詞是「用細緻權限存取權杖直接發布新版本的能力」，範圍看起來比較寬。本文以 changelog 的範圍為主述，兩種寫法都照抄，不擅自選一邊當唯一答案。

截至查核日 2026 年 9 月 20 日，這一刀還沒有落下：npm 的說明頁明寫「目前，免 2FA 權杖仍然可以用來直接發布」，而且四份來源裡寫到這件事的三頁都只印到「2027 年 1 月」這個月份，沒有任何一頁寫出確切日期。

現在實際上要做什麼

已經在發布套件的人，若想知道工作流程符不符合資格，可以對照官方條件：套件必須已經在 npm registry 上、要有發布權限、npm 帳號已啟用 2FA、npm CLI 在 11.15.0 以上，以及 Node.js 在 22.14.0 以上。符合後，步驟是建立一個 Read and write (stage only) 權杖、把 npm publish 換成 npm stage publish，再請維護者用 2FA 核准待審版本。

npm 把只送審權杖定位成一條遷移路徑，提供給還沒改用 trusted publishing（OIDC）的權杖式自動化；已經在用 trusted publishing 的團隊，官方也寫明兩者可以合用，維護者一樣要用 2FA 複查待審套件。只安裝套件、不自己發版的一般工程師，這次不必調整設定——這是本文依報導範圍的判讀，四份來源談的都是發布端的變化，沒有一句話是對安裝端使用者的指示。

2026 年科技新聞總整理：硬體、平台、電信與法規的重點

歐盟《網路韌性法》通報義務上路：9 月 11 日起，誰要多快通報

• 軟體與 App
• 科技與產業
• 科技新聞