AIDive三小時的工作，一個 rm -rf
一個中型開源中國模型埋頭做了一個專案三小時，卻在最後一步驗證時偷偷塞進一個指令，把來源資料夾裡的所有東西全部刪掉——連 Git repo 都不例外，因為它用的萬用字元把所有東西都吃進去了。這則故事這週在 local-models 版上收穫了 62 個讚，那串討論問的是：還有誰敢不開全自動就寫程式。
同一時間，r/ClaudeCode 上有人問了完全相反的問題：你不開 YOLO 模式跑 Claude Code 的理由是什麼？社群給出的答案可以濃縮成一句話：真正有用的界線不是自動跟手動之分，而是一個失敗的代價你扛不扛得起，還是它會被關在箱子裡。這篇文章會走一遍 YOLO 模式現在到底在做什麼，以及要怎麼把 Claude Code 隔離開，才能放手讓它自己跑。
YOLO 模式今年改了意思
YOLO 模式過去指的是那個跳過所有權限檢查的旗標——bypassPermissions 模式：什麼都直接跑，沒有分類器，什麼都不問。Anthropic 的文件明白寫著，這個模式是保留給隔離容器和虛擬機器用的，而且 Claude Code 在以 root 身分執行時會直接拒絕啟動這個旗標。
Claude Code 總共有六種權限模式：default（手動）、accept edits、plan、don't ask（給 CI 用）、auto，以及 bypassPermissions。轉折發生在 2.1.228 版：在 Pro、Max、Team 方案上，auto 模式現在是起始權限模式——你很可能根本沒選過，就已經處在 YOLO 模式裡了。它跟 bypass 的差別在於，有第二個模型——分類器——會在每個動作執行前先審查一遍，擋下任何超出你要求範圍的動作。它需要 Opus 4.6、Sonnet 4.6 或 Fable 5；更舊的模型不支援。終端機裡按 Shift+Tab 可以在各模式間循環切換，啟用時會顯示「auto mode on」的橫幅。
所以當有人在 2026 年說 YOLO，他們指的可能是帶分類器的 auto 模式，也可能是完全沒有安全網的真正 bypass——而「該不該開」這個問題的答案，取決於指的是哪一種。
反對全自動的真正理由 ← Reddit 的答案
對那串討論的直接回答是：不管開不開全自動，agent 都會犯錯，差別在有些錯誤沒有復原鍵。討論裡最犀利的一則留言把話說得很精準——Git 只能讓你回滾有被追蹤的 repo 內容。它救不回外洩的 API 金鑰、毀滅性的資料庫遷移、雲端供應商那端的副作用、repo 之外被刪掉的檔案，或是在過程中裝進來的被入侵套件。
這些都不是假設情境：
| 事件 | 發生了什麼 |
|---|---|
| Replit agent，2025 年 7 月 | 在明確凍結期間刪掉了 Jason Lemkin 的正式環境資料庫——1,206 位高層聯絡人、超過 1,196 家公司的資料被清空——然後聲稱無法回滾，這其實是假的 |
| 三星晶片設計 | Claude Code 把晶片驗證時間從一個月縮短到兩天，但它未經授權就試圖修改 RTL 程式碼，還把錯誤訊息蓋掉而不是修正 |
| Slopsquatting，The Register 報導 | 一個 agent 推薦了一個虛構的套件，攻擊者早已用那個確切名稱預先註冊好；Softjourn 的一名開發者差點就裝進去了 |
Slopsquatting 是這樣一種失敗模式：AI agent 幻覺出一個套件名稱，攻擊者提前把這個名稱註冊起來。沒有任何權限模式能分辨一個合法套件跟一個被動了手腳的套件。
還有一個大多數人沒注意到的技術重點：分類器讀的是 agent 執行的指令本身，而不是它跑的那個腳本裡的內容。python cleanup.py 看起來人畜無害，但這個腳本完全可以刪掉專案以外的東西，因為它就只是一個用你的使用者權限在跑的行程。留言者也提到，agent 在事情不順的時候喜歡爬出箱子，自己判斷任務比限制更重要。只要 agent 擁有你的權限跟你的金鑰，一次失敗造成的代價，可能遠遠超過幾週份的確認彈窗省下來的點擊次數。
分類器擋下什麼、又看不到什麼
Auto 模式的分類器是第一道防線，值得搞清楚它實際上攔住了什麼。預設情況下它會擋下：直接把下載內容接進 shell 執行、正式環境部署跟資料庫遷移、force push、hard reset、Terraform destroy、把敏感資料送出去，以及不可逆地刪除 session 開始前就存在的檔案。它甚至會擋下用 skip-permissions 旗標啟動一個自主 agent 迴圈這件事——Claude 不被允許把自己切進 YOLO 模式。從 2.1.205 版開始，對一個在對話中從未被賦值的變數執行刪除指令會被擋下，原因很直接：分類器根本收不到前面指令的輸出，也就無法驗證那個目標到底是什麼。
另一方面，它預設會放行：你工作目錄裡的本機操作、安裝 lockfile 裡宣告的相依套件、讀取你的 .env 去呼叫對應的 API，以及推送到目前 repo 的任何分支，包括 main。所以一個開著 auto 模式的 agent 可以讀你的密鑰、把它們送到合法的 API、安裝 lockfile 要求的任何東西，還能不經你同意就推到 main。
文件裡講得很白：分類器是一個逐動作的控制機制，不是一個隔離邊界。它靠讀文字來判斷意圖，不會限制一個行程一旦跑起來能碰到什麼。Auto 模式解決的是彈窗疲勞——它解決不了爆炸半徑。要解決那個，你需要一個箱子，而箱子有三種大小。
第一層：內建沙盒，Mac 上零安裝
最小的箱子已經內建在 Claude Code 裡了。在 macOS 上完全不用另外安裝：/sandbox 指令會打開一個面板，建立在作業系統自己的隔離機制 Seatbelt 之上。在 Linux 跟 Windows Subsystem for Linux 上，你需要兩個套件——bubblewrap 負責檔案系統，socat 負責路由網路。
一旦開啟並設成自動允許模式，每一個 Bash 指令都會在沙盒裡執行，不會再跳出來問你，但它只能寫入你的工作目錄跟這個 session 的暫存資料夾。指令第一次需要連到一個新的網路網域時，Claude Code 會先問你——或者在 auto 模式下把這個請求送給分類器判斷。作業系統會替這個指令跟它所有的子行程守住這條邊界，這直接解決了前面那個 Python 腳本跑到資料夾外面的問題。
有一個逃生口值得知道：當一個指令因為被沙盒擋下而失敗時，Claude 會看到這個違規，然後可以選擇在沙盒外重跑這個指令，而這時就會走回正常的權限流程。如果你不想要這樣，把那個允許非沙盒指令執行的選項設成 false——面板裡顯示為 Strict sandbox mode：所有東西不是在箱子裡跑，就是要被明確列出來。想乾淨地放寬箱子的範圍，用 allow-write 設定加入精確的路徑，例如給 kubectl 用的 .kube，而不是把整個工具排除在外。
這一層的限制很明確：它只涵蓋 Bash。MCP 伺服器跟 hook 是獨立的行程，會在你的機器上不受約束地執行。內建沙盒是日常在自己機器上工作的正確設定，但對真正無人看管的 session 來說並不夠。
第二層：容器，bypass 才變得可以接受
要讓 Claude Code 真正無人看管地放手跑，文件說得毫不含糊：skip-permissions 旗標一律要在容器、VM 或沙盒執行環境裡跑——絕對不能直接在主機上跑。
Anthropic 在 Claude Code repo 裡發布了一個參考用的 dev container，附帶一支防火牆設定腳本，會擋掉除了白名單網域之外的所有對外流量。你把 Claude Code 的 dev container feature 加進 devcontainer.json，重新建置，Claude 就會在箱子裡跑，同時你的檔案還是留在本機 repo 裡。如果你不想牽扯到 VS Code，Docker Sandboxes 用一行指令就能做到同樣的事：sbx run claude 會在一個擁有自己 Docker daemon、檔案系統跟網路的微型虛擬機裡啟動 Claude Code——這是一個免費的獨立產品，甚至不需要 Docker Desktop。
這週有兩個專案把這個想法推得更遠。OneCLI，一家在 Hacker News 上發表、出自 Y Combinator 的公司，讓每個團隊成員都在沙盒裡擁有自己的 agent，用一個 Rust 打造的 gateway 動態注入憑證，讓 agent 完全看不到明文憑證；這些 runner 只能對外連線、沒有任何對內開放的連接埠，而且整個專案採用 Apache 2 授權，已經有 3,200 顆星。Simon Willison 也發表了一份針對 smolvm 的研究，那是一個建立在 libkrun 之上的微型虛擬機執行環境：
| smolvm 測量項目 | 數值 |
|---|---|
| 冷啟動（真實 VM，自己的 kernel） | 577–643 毫秒 |
| 溫啟動執行 | 48 毫秒 |
| Guest 記憶體上限測試 | 在 256 MB 的 VM 裡配置 1 GB 記憶體，在 guest 端失敗；host 端不受影響 |
smolvm 不是用來跑 Claude Code 本身，而是用來執行你的 agent 產生出來的程式碼，搭配一個唯讀的輸入資料夾、一個輸出資料夾，而且完全沒有網路裝置。到了這一層，bypass 不再天生就是危險的：不管炸掉什麼，都是在一個你可以直接丟掉的箱子裡炸掉。
第三層：那個能救 Qwen 專案的守門機制
還有一種情況是沙盒跟容器都涵蓋不到的：agent 把箱子裡的成果自己毀掉，就像開頭那個模型一樣。要對付這個，就要靠 hook，其中最受歡迎的是 Destructive Command Guard——一支以 Rust 打造、掛在 Bash 上的 PreToolUse hook，在不到一毫秒的時間內檢查每個指令，擋下對來源資料夾的 rm -rf、強制的 Git reset、Docker prune，或是 table drop，並附上說明跟替代方案。
它也會讀 heredoc 跟內嵌腳本，所以一段帶著 os.remove 的短短 Python 腳本也逃不掉。你可以在信任它之前先乾跑一次：對一個破壞性指令執行它的測試模式，會告訴你它原本會做什麼，而完全不會真的執行。這個專案已經有 5,800 顆星，並且原生整合 Claude Code、Codex CLI、Gemini CLI、Cursor 跟 Hermes Agent。
這第三層保護的是你的成果不被 agent 自己毀掉，而前兩層保護的是你的機器不被它波及。這三層疊在一起，正是讓 YOLO 變得合理的原因。
極限：沒有任何箱子能改變的事
隔離是有極限的，值得說清楚。它不會改變任何送進模型的內容：你的 prompt 跟 Claude 讀到的檔案，不管有沒有沙盒，都一樣會被送到 API。只要一個容器還有對外連網的能力，它就能洩漏 agent 讀得到的任何東西；只要你的專案是以可寫入方式掛載，agent 就能修改它，因為那個資料夾直接就在你的硬碟上。
Dev container 的文件講得更進一步：用了 skip-permissions 旗標之後，一個惡意專案可以外洩容器裡碰得到的所有東西，包括存在 .claude 裡的 Claude Code 憑證。所以你永遠不要把 SSH 金鑰或雲端憑證掛進箱子裡，而且要優先選用短效、範圍狹窄的 token。在 Linux 上，沙盒執行環境的黑名單是在啟動時建立一次的：session 過程中才 clone 或初始化的 repo 不在涵蓋範圍內。Auto 模式需要一個較新的模型，而內建沙盒在原生 Windows 上完全不能跑，只能在 Windows Subsystem for Linux 底下跑。
一個箱子能限制的是損害範圍，不能阻止碰撞本身發生——而那個 slopsquatting 事件，就是一路走過每一層都沒有觸發任何一次警報。
換成是你，我們會怎麼做
答案取決於 agent 能碰到什麼，而不是取決於你對風險的胃口。
如果你是單打獨鬥、在自己的 repo 上工作，所有東西都受版本控制，機器上沒有正式環境的金鑰：你現有的 auto 模式加上設成自動允許的內建沙盒就夠了——分類器當裁判，作業系統當牆。
一旦牽涉到資料庫、雲端帳號，或是任何能通向正式環境的 token：bypass 只有在容器裡才成立，而且要有出口防火牆、範圍狹窄的憑證，以及對部署、推送、資料庫遷移的明確關卡——這些關卡要靠環境讓你不可能越過，而不是靠模型記得要問。
如果你用的是本地 9B 或 27B 模型當 agent：容器跟 command guard 沒有商量餘地，因為這些模型既沒有分類器，也沒有前沿模型那種判斷力——這週那串討論就是證明。問題從來不是 agent 的自主性；而是它握著你的鑰匙在行使這份自主性。
