權限提示有 97% 被直接按同意，於是 Claude Code 改用分類器把關

同樣是 Claude Code 跳出來要你點的視窗，使用者的認真程度差了十倍以上。

端出一份計畫請人核准，39% 被打回去。換成單一則權限請求——要不要跑這行指令、要不要改這個檔案——拒絕率只有 3%。

數字不是外界統計的，是 Anthropic 自己寫在 2026 年 8 月 7 日的公告裡，同一份公告還有第三個數字：權限提示的整體核准率，97%。然後公告宣布：8 月 14 日起，Pro、Max、Team 方案的新 session 將以 auto mode 執行，工具呼叫不再逐次跳出來問人，改由一個獨立的分類器模型在執行前逐一審查。

兩天後的 8 月 9 日，是 OpenAI 替獨立版 ChatGPT Atlas 瀏覽器排定的停用日；Atlas 的公告 7 月 9 日就發了，瀏覽器的代理能力併回 ChatGPT 與 Codex。

兩家給的直接理由不同，方向卻一樣：代理式 AI 正在從「使用者要另外去的一個地方」，搬回「預設就在的那個地方」。

8 月 14 日起，Pro、Max、Team 的新 session 預設進 auto mode

先把時間軸釘住。公告日是 2026 年 8 月 7 日，生效日是 8 月 14 日。寫這篇的今天是 8 月 10 日，改動還沒發生。官方部落格的頁面標題用的是現在式，寫成 auto mode 現在就是預設；同一頁的副標與內文卻是未來式，內文寫的是 8 月 14 日起新 session 會以 auto mode 執行，官方說明文件也一樣。時態以內文與說明文件為準。8 月 7 日當天唯一生效的事，是分類器每次工具呼叫要多花的那一小撮 token 不再向 Pro、Max、Team 方案收費。

適用範圍要看清楚。Claude Enterprise、Claude API，以及 AWS 上的 Claude Platform、Amazon Bedrock、Google Cloud 的 Agent Platform、Microsoft Foundry 都維持 opt-in，理由是讓管理員有時間審視改動；至於什麼時候跟上，公告寫的是「計畫在接下來一個月」與雲端夥伴合作改成預設——是計畫，沒有日期。

順帶釐清一個容易撞名的東西：Claude Code 的 auto mode 講的是權限模式，決定要不要跳出確認視窗；Cursor 那個 Auto mode 講的是自動選模型。兩者除了名字沒有關係。第一次接觸這個工具的人，可以先從 Claude Code 對非工程師的入門補背景。

換掉的是確認鍵，不是權限檢查

auto mode 最常被誤讀成「把權限檢查關掉」。官方文件講的不是這回事：改掉的是誰來做判斷。原本每一次工具呼叫都跳出提示、由人按鍵；現在送進一個獨立的分類器模型，在執行前審查，攔下三類東西：超出使用者原本要求範圍的、指向不認得的基礎設施的，以及看起來是被 Claude 讀進來的敵意內容所驅動的。官方用的動詞是 designed to——設計上要在「不想被打斷」與「避開有害動作」之間取得平衡，不是承諾。

分類器有一個刻意留下的盲區：它只看得到使用者的訊息與 agent 的工具呼叫，Claude 自己說的話和工具輸出會被剝掉，官方稱之為 reasoning-blind by design。理由很直白——把 assistant 的文字拿掉，agent 才沒辦法用講的把分類器說服到做出錯誤判斷。

原本的權限規則沒有消失，但多了一條例外：allow 規則仍在分類器之前生效，唯獨寬到足以授予任意程式執行的那種——Bash(python:*) 這類——會在 auto mode 期間被擱置，因為它會讓命令整個繞過分類器。

被擋下來之後還有退場機制：Claude 通常會自己找一條比較安全的路，或直接回頭問人；如果推不動了——連續三次被擋，或單一 session 累計二十次——Claude Code 會退回人工核准。工具呼叫這一層本身也在變形，MCP 2026-07-28 規格解析記過 7 月底的改版怎麼重畫權限與能力的邊界。

權限提示的核准率是 97%，比三月那篇工程文更高

改動的理由是一組關於人的數據。

Claude Code 的權限提示，使用者核准了 97%。官方用的字是 suggests——資料顯示，人工審查可能已經變成習慣動作。緊接著官方自己補了退路：大部分提示很可能本來就是安全的例行指令，但核准率高到這種程度，顯示不少人是反射性地點過去，而不是每一條都讀。

97% 有個對照組，而且是同一家公司自己留下來的：2026 年 3 月 25 日的工程部落格，副標寫的是使用者核准 93% 的權限提示。兩篇官方文章之間隔了四個半月，同一個指標從 93% 變成 97%。兩篇都沒有標出各自的統計區間，所以能講的只有「兩次公布的數字一次比一次高」，不是一條量測出來的曲線。

另外兩組數字往同一個方向走。截至 2026 年 6 月，49.5% 的活躍 CLI 使用者手動建立過 Bash allow 規則——5% 直接放行任何 shell 指令，另外 43% 設的是 Bash(python:*)、Bash(node:*) 這類官方認為實務上等價的直譯器規則，而比例還在以每 5 週約 5 個百分點的速度往上爬。再往外一圈：62% 的使用者用過 bypassPermissions 或在 Bash 上按過「不要再問」，25% 的互動式 session 一開場就在 bypass 模式裡。

官方沒有把 39% 與 3% 的落差解釋成使用者不夠認真，用的詞是「習慣化」。設計上要人守的那道關卡，最後到底守在誰身上，是這次改動真正在回答的問題。

找 1,053 個人來測，人越用越不看

公告裡最有畫面的一段，來自一場 1,053 人的測試：受試者使用 Claude Code 的過程中，某一則權限提示被換成一條明顯危險的指令，記錄的是他們會不會按下同意。

人抓到那條指令的比例是 13.6%，1,053 次裡的 143 次；同一批指令交給 auto mode，擋下 89%，937 次。直接對打的數字更直白：auto mode 擋下 800 條人類已經核准的指令，人類擋下 auto mode 放行的只有 6 條。

而人的表現會隨時間衰減。session 前段，人擋下約 17% 的危險指令；累積超過 50 則提示之後，掉到約 5%。分類器的攔截率則不隨 session 長度變動。

官方在同一段裡寫了兩個限定。第一，受試者是在為這場研究專門搭建的測試環境裡工作，不是在自己的程式庫、不是真實專案。第二，受試者知道自己正在被評估，只是照盲測設計沒被告知測的是哪個行為；按下同意也不會真的執行任何危險的東西，被換掉的只有提示上的文字。

Apollo Research 的紅隊測試則讓分類器的漏接率從 12% 降到 7%，代價是漏掉約 2% 原本抓得到的攻擊。官方對這個 7% 附了一句警告：那些攻擊是合成的、對抗式設計的，專門用來找出分類器會壞在哪裡，不該被當成真實流量上的漏接率。

Anthropic 三月自己寫過：對逐條審核的人，這是一種退步

auto mode 不是八月才出現的東西。2026 年 3 月 24 日，Anthropic 以 Team 方案 research preview 的形式推出 auto mode，同一頁後來補了一筆更新註記：2026 年 7 月 10 日對所有使用者正式推出。從 3 月 24 日推出到 8 月 14 日成為預設，是 143 天；從 7 月 10 日全面開放算起，是 35 天。

推出的隔天，Anthropic 的工程部落格發了一篇談 auto mode 分類器的長文。裡面有一段，是整件事最該被讀到的一段。

那篇文自己問：分類器 17% 的漏接率可不可以接受？答案取決於拿什麼來比。對本來就在跑 --dangerously-skip-permissions 的人，這是明顯的改善。對本來逐條仔細核准每個動作的人，Anthropic 自己的用字是 it's arguably a regression—you're trading your own judgment for a classifier——可以說是一種退步，你是拿自己的判斷，去換一個有時候會犯錯的分類器。同一段還寫了：auto mode 針對的是第一種人，以及第二種人手上那些核准成本不值得那點邊際安全的任務；而它不是高風險基礎設施上人工審查的替代品。

四個半月之後，8 月 14 日起，這個交換將成為預設值。

那段話裡的 17%，和 1,053 人測試裡的約 17%，是兩件完全不同的事。三月工程文的 17% 是分類器自己的漏接率，母體是 52 筆真實的「過度行動」樣本，從員工否決過或事後被標記的 session 裡挑出來，完整管線在那組樣本上的成績是誤攔 0.4%、漏接 17%；1,053 人測試裡的約 17%，講的則是人在 session 前段擋下危險指令的比率。

三月那篇文還自承了一種修不掉的失敗模式：分類器會找到「看起來像核准」的證據就停手，不會再往下確認那份核准是否涵蓋動作實際的波及範圍。官方寫的是，繞著這一點做過 prompt engineering，但沒找到划算的解法。

要公平地說，Anthropic 沒有把保留意見藏起來。八月公告的結語同樣寫著：auto mode 對多數使用者降低風險，但它仰賴分類系統，因此並未消除風險；對正式環境基礎設施的高風險變更，官方仍建議自己看過 Claude 做了什麼。

差別在於，三月那句保留意見寫給的是「要不要自己打開它」的人；到了 8 月 14 日，沒有動手改設定的人，會被預設歸到 auto mode 所針對的那一邊——按三月那篇文的分法，那一邊是本來就跳過權限提示的人，外加逐條審核者手上那些「核准成本不值得那點邊際安全」的任務。這不是說 auto mode 等於跳過檢查：官方文件把 auto 描述成「全部放行，但有背景安全檢查」，bypassPermissions 才是純粹的「全部放行」。差在預設把你歸進哪一類使用者。

Atlas 的停用日排定在 8 月 9 日，能力併回 ChatGPT 與 Codex

另一邊的動作，公告日早得多。OpenAI 在 2026 年 7 月 9 日公告要收掉 Atlas，官方說明頁的原句是：正在淘汰 Atlas，並把以瀏覽器為基礎的代理能力移進 ChatGPT 與 Codex，同時延續從 Atlas 學到的東西，在 ChatGPT 裡支援更完整的瀏覽器體驗，包含多分頁、下載、更好的導覽與帳號登入支援——句尾帶著 where available，在支援的版本與地區才有。

官方用的動詞是 scheduled to stop working，不是已經停止：排定於 2026 年 8 月 9 日停止運作，將要求使用者在那之前匯出或保存重要資料；過了那天，Atlas 可能不再能開啟、瀏覽，或支援瀏覽器代理工作流。同一頁的 FAQ 補了節奏：公告日 7 月 9 日，給約 30 天的緩衝期。理由與 Anthropic 那邊完全不同：瀏覽器需要持續的安全維護，OpenAI 不希望使用者留在一個已終止的瀏覽器上，那可能逐漸劣化或不再收到安全更新。

資料則要自己搬：書籤不會自動轉移，得在停用日前匯出再匯入 Chrome 之類的瀏覽器；分頁與瀏覽紀錄可能不會自動轉移；cookie 在支援的情況下提供匯出選項。

把整段壽命放進來看：Atlas 在 2025 年 10 月 21 日發表，當天只在 macOS 上推出，Windows、iOS、Android 寫的是即將推出；發表日到排定的停用日是 292 天，9 個月又 19 天，而至停用時，官方管道未見 macOS 以外版本的推出公告。官方 release notes 的最後一筆停在 2026 年 3 月 10 日，前 5 個月則幾乎每週一版——這不等於沒有靜默修補的建置，只是公開的版本說明停在那裡。

7 月 9 日那天也不是只收 Atlas 一項：同一天，ChatGPT 停止讓使用者建立新的群組聊天，推出 ChatGPT Work，並推出把 Chat、Work、Codex 併在一起、內建瀏覽器的新桌面 App。是一次整併，不是單點砍產品；ChatGPT Work 與 Cowork 的對比在 7 月就記過一筆 Atlas 開始退場。TechCrunch 的定調則是：the browser is a feature, not the destination。

ChatGPT 這邊的瀏覽器有三條路，能力上限差很多

「併回 ChatGPT 與 Codex」聽起來像換個殼，實際上使用者會遇到三樣能力上限不同的東西。混著講就會誤解，尤其是登入這一項。官方停用公告點名的去路只有兩條——桌面 app 與 Chrome 擴充功能／側欄；把 cloud browser 一起放進來比較，是本文的整理。

第一樣是桌面 app 的內建瀏覽器，入口開在 Work 與 Codex 兩個介面裡。它有自己的瀏覽器狀態，支援較完整的登入、自動填入、密碼管理、擴充功能、下載與導覽，官方註明可用功能可能取決於方案與工作區設定。停用公告裡講的帳號登入支援，指的是這一個。

第二樣是 cloud browser，能做的事少得多：推出時只能處理公開頁面，不接受憑證、不使用自動填入或密碼管理器、不能登入網站、不能完成付款，網站只要要求其中任何一步，任務就停在那裡。它開放給 Free 與 Go 以外的付費方案，限於支援的地區。

第三樣是 Chrome 擴充功能：當任務需要既有的 Chrome 設定檔、已登入的 session、開著的分頁或既有的擴充功能時，官方建議用 Codex 的 Chrome 擴充功能。Codex 本身怎麼工作，Codex 錄製與重放有更細的拆解。

一個容易被忽略的反差：Atlas 的 agent mode 在官方 release notes 裡明文寫著不能在瀏覽器裡執行程式、不能下載檔案、不能安裝擴充功能，而接手的桌面內建瀏覽器把下載寫進了功能說明。至少在下載這一項上，收掉舊殼之後拿到的東西比舊殼多。OpenAI 在文件裡也把網頁內容當成不可信的輸入：任務要具體，核准存取之前先看清楚網站，開到錯的帳號或頁面就把任務停掉——這條和 Anthropic 分類器要攔的第三類動作指向同一個威脅。

兩家收回的東西不一樣

把兩件事並排放，形狀才看得清楚。

項目	Anthropic（Claude Code）	OpenAI（ChatGPT Atlas）
公告日	2026 年 8 月 7 日	2026 年 7 月 9 日
關鍵日期	8 月 14 日起新 session 以 auto mode 執行（尚未生效）	排定 8 月 9 日停用，官方用 scheduled to
收掉的東西	例行工具呼叫的人工確認鍵	一個獨立的瀏覽器外殼
官方理由	核准率 97%，人工審查已成習慣動作	瀏覽器需要持續的安全維護
接手的東西	一個分類器模型，在執行前逐一審查	官方點名桌面 app 與 Chrome 擴充功能／側欄；cloud browser 是本文一併比較的第三條路
適用範圍	Pro、Max、Team；Enterprise 與 API 仍 opt-in	依方案與地區而異，官方一再寫 where available
使用者要做的事	想維持逐次確認得自己改設定	書籤等資料得自己在停用日前匯出

表格排得整齊，但有三件事排不進去。

第一，兩家的動作不是同一種決定。Anthropic 收的是產品裡的一個互動，按 Shift+Tab 就能換回來；OpenAI 收的是一個獨立的軟體，連同它的更新責任，而且排定了一個日子之後就不再維護。

第二，兩家給的直接理由不同。一邊講的是人不看確認鍵，一邊講的是瀏覽器養不起持續的安全維護。方向相同不代表動機相同。

第三，兩家的官方說法都是移動，不是刪除：OpenAI 的原句是把以瀏覽器為基礎的代理能力「移進」ChatGPT 與 Codex，Claude Code 公告的副標講的則是讓自主工作跑得更久。能自己逐項核對的只有一件——Atlas 的 agent mode 不能下載檔案，桌面內建瀏覽器可以；完整的功能增減對照，兩家都沒有公布。兩家工具日常怎麼互相換手，Claude 與 Codex 互為備援與Claude Code 與 Codex 的選型對照有更完整的比較。

長年追蹤 prompt injection 的人，把 89% 讀成另外 11%

Simon Willison 在 8 月 8 日寫了看法。他從 2022 年就在寫 prompt injection，是這個題目最持續的追蹤者之一——那個詞他自己是在 2022 年 9 月用上的，而他後來也在自己的網站上註明，另有人早他四個月就用過同一個說法。

他接受前提，說他完全相信 auto mode 是比「要人不斷核准動作」更好的解法：確認疲勞是真的，每幾步就要人按一次「OK」，顯然不會導向安全的行為。但他把 89% 翻到反面讀——那仍然留下 11% 的情況，是 auto mode 不會擋下來的。

他更擔心的也不是刪錯檔案、清掉正式資料庫那類意外，而是 prompt injection：有人把惡意指令夾帶在 agent 從外部讀進來的內容裡。對官方公布的數字，他要的是更多獨立驗證；他自己的結論則是往另一個方向走：找出一種跑 agent 的方式，讓 agent 根本碰不到那些一旦被錯誤觸發就會造成傷害的資料與工具。

獨立驗證確實值得多說兩句。八月公告裡的第三方評測，是 Anthropic 委託 Trajectory Labs 執行的，測的是截至 2026 年 7 月 17 日 Claude Code 與 Codex 的最新公開版本。結果是 720 次攻擊嘗試——72 個間接提示注入情境，每個測 10 次——對跑 auto mode 的 Claude Fable 5、Opus 5、Sonnet 5 全數失敗。這個數字要配著三件事一起看。射程限制官方自己標了：測的是 Trajectory Labs 自製的瀏覽器整合，兩家第一方瀏覽器整合內建的防護沒有被測到，結果應視為對底層模型的量測，而不是對某個實際部署裡完整防護組合的量測。Trajectory Labs 與 Anthropic 另有商業往來，曾參與 Opus 5 系統卡的外部紅隊測試，並非完全中立的第三方。

最有力的煞車正是來自執行評測的廠商自己——Trajectory Labs 在官網寫著：自動化系統能把已知攻擊測得很好，卻難以發現新的攻擊，所以自動化攻擊成功率低，並不算是模型安全的有力證據。

也有人把 Atlas 收攤讀成完全相反的訊號。The Browser Company（Arc 與 Dia 的開發商）執行長 Josh Miller 在同一天說，他對「瀏覽器之於 AI，等同於手機之於智慧型手機」的信心從未如此強烈。利益揭露：他是同市場的競爭者，發言不是中立評估。

不想被改成預設，有四個地方可以動

已經自己設過別的預設模式的，可能會收到一次性詢問；已經把預設釘住的，什麼都不會變。其餘使用 Pro、Max、Team 方案的人，8 月 14 日之後開的新 session 會直接落在 auto mode。想維持逐次確認，有四個地方可以動。

一，臨時切換：CLI 裡按 Shift+Tab 循環權限模式，桌面 app 用模式下拉選單。

二，把預設釘住：在使用者家目錄的 ~/.claude/settings.json 設 defaultMode。

三，在組織層面關掉：managed settings 裡把 permissions.disableAutoMode 設成 "disable"，auto 會從 Shift+Tab 的循環裡移除，啟動時帶 --permission-mode auto 也會被拒絕。

四，在 auto mode 裡留下人工檢查點：permissions.ask 規則會在分類器之前評估，一定會跳出提示。官方的說法很直接——明確寫下的 ask 規則，代表使用者已經表明希望在那個動作上被詢問。

一個容易踩的坑：defaultMode 設成 auto 時刻意不吃專案層設定檔，較新版本的 Claude Code 會忽略那些檔案裡的 auto，避免一個 repo 自己授予自己 auto mode。要生效就得寫在使用者家目錄裡。

給非工程師的一句話

手上只要有會自己動手的 AI 工具，花一分鐘去看它現在的預設是什麼——預設會被改，而改的那天不一定會問你。更值得問的問題不是「AI 安不安全」，而是「上一次認真讀完一個確認視窗，是什麼時候的事」；Anthropic 公開提出的第一個理由，就是這個問題的答案。

事實分級說明

取自官方一手文件：

• Anthropic 2026 年 8 月 7 日 auto mode 公告，與 Claude Code 說明文件的權限模式、auto mode 設定兩頁。
• Anthropic 2026 年 3 月 24 日 auto mode 發表頁與同頁 7 月 10 日更新註記，以及 3 月 25 日工程部落格。
• OpenAI 說明中心的 Atlas 停用頁與 FAQ、ChatGPT release notes、內建瀏覽器與 cloud browser 說明頁、Atlas release notes 與發表頁。

本站自行整理：

• 兩家對照表為本站彙整，欄位對應的原句分散在上列文件中。
• 三個天數為官方日期相減：292 天、143 天、35 天。媒體給的 Atlas 存活月數基準不一，本文不採用。
• 具名外部評論僅採 Simon Willison 2026 年 8 月 8 日的文章；Josh Miller 的發言附利益揭露。
• 截至 2026 年 8 月 10 日，OpenAI 官方說明頁仍為 7 月 16 日版本，仍寫 scheduled to stop working，本文因此不把 Atlas 寫成已完成停用。
• 第三方評測只引用 Claude 三個模型在 auto mode 下的結果；同一份評測也測了另一家工具，其攻擊成功率數字受同一組射程限制影響，本文未引用，亦不對兩家的安全性下總評。