Claude Code v2.1.305 加入 Linux 相容性，但須權衡沙盒取捨

Anthropic 發布 Claude Code v2.1.305，加入一項 Linux 相容性選項，並附有明確警告：指令可能繞過沙盒的檔案保護機制。此版本亦處理供應商故障及無人值守重試功能。這些改動共同令實際部署問題，比模型能力的宣傳焦點更值得優先關注。

核心矛盾在於實用自動化與可強制執行的界限之間。開發者希望助理可以完成貼近真實情境的工作，而毋須因環境問題停下來。安全團隊則需要知道，當相容性設定改變時，哪些限制仍然有效。一項指令成功執行，本身並不能回答這個問題。

GitHub Copilot 提供了一個有用的對照，因為其文件同樣以具體限制說明執行控制。這是操作層面的比較，並非聲稱兩款產品採用相同架構。對正在評估編程代理的機構而言，相關問題愈來愈具體：在無人看管時，軟件實際上可接觸甚麼？

Claude Code v2.1.305 的改動

最具影響的新增項目，是一項明確附帶安全代價的相容性設定。

根據發布說明，sandbox.allowNestedUserNamespaces 讓 Linux 指令建立使用者命名空間，令程序可擁有各自獨立的使用者身分及權限視圖。Anthropic 以 Chromium 瀏覽器引擎，以及無須管理員帳戶執行的容器工具 rootless Podman 為例。該公司警告，這容許繞過沙盒的檔案保護機制。

此版本亦為無人值守重試模式新增 CLAUDE_CODE_RETRY_WATCHDOG_USAGE_LIMIT_RECHECK_MS，讓系統可在使用量限制解除時更早偵測。它修正 v2.1.304 的回歸問題；當端點或閘道拒絕工具搜尋時，該問題會影響 Vertex、Bedrock 及其他供應商。Claude Code 現在會在沒有該功能的情況下重試。

其他修正涵蓋 /effort 及 /autocompact 的模型名稱配對、worktree 行為，以及更清晰的全磁碟錯誤訊息。Worktree 是連接至 Git 儲存庫的獨立工作目錄。這些改動關乎設定及執行可靠性，而非新公布的模型。

在判斷這次更新的意義時，這個分別很重要。這些細節沒有證明推理能力更佳、編程準確度更高，或所有環境的安全性均獲改善。眼前的重點，是如何讓代理配合本身存在限制及故障條件的基礎設施。

升級時，這些新增項目亦值得分別處理。透過既有閘道恢復請求的修正，是在處理失效行為；改變指令可執行事項的設定，則需要政策決定。若將兩者都視為例行便利功能，便會掩蓋其不同後果。

對開發團隊而言，這帶來不均衡的版本評估。有些改動值得檢查既有工作流程是否恢復運作；另一些則值得檢查工作流程是否仍在可接受的界限內運作。即使它們同時出現在同一套件中，這仍是兩套獨立的驗收標準。

公開說明反映 Anthropic 對改動的描述，但沒有提供獨立的可靠性量度或完整安全評估。本分析未有測試此版本、重現繞過情況，或量度復原時間。

因此，最清晰的解讀雖有限，卻仍有用。Claude Code v2.1.305 處理真實執行環境中的摩擦，同時揭示一項不能簡化為「指令現在可運作」的決定。相容性有其價值，但附帶的條件同樣重要。

平台團隊承擔相容性決定

負責共用開發環境的人，面對的決策負擔最大。

個別開發者可按個人需要判斷本機實驗。平台團隊則必須判斷，相同設定是否適合套用至不同儲存庫、機器及無人值守工作。可接受的答案取決於這些環境包含甚麼，以及其中程序具備甚麼權限。

設想一個假設情境：團隊要求代理調查瀏覽器測試失敗。調查可能需要啟動瀏覽器、檢查輸出，並修改應用程式程式碼。若執行限制阻止瀏覽器運作，團隊便會面對即時的交付問題。相容性例外看來很吸引，因為它移除了明顯障礙。

較不明顯的問題，是該環境中其他可取得的資源。一次在可丟棄機器上執行的測試，與一次在敏感檔案旁執行的測試，風險特徵並不相同。因此，同一項工作描述可因執行地點不同，而合理地採用不同設定。

這正是成功示範的政策價值有限的原因。它證明某一條路徑在特定條件下完成，卻不能證明不相關檔案是否仍受保護，或憑證是否被不必要地暴露。這些問題需要通過測試以外的證據回答。

Anthropic 早前的沙盒架構說明將作業系統限制定位為一種在限制執行範圍的同時，減少重複審批的方法。其理據將自主性與檔案系統及網絡界限連繫起來。這段歷史說明，影響這些界限的改動值得關注。

機構內的壓力來自相反方向。開發者視被阻擋的指令為時間損失；安全審查者則視被削弱的限制為暴露範圍擴大。平台擁有人必須提供一個環境，令預期工作流程可行，同時不讓任何一方假定另一方已處理後果。

明確列出的例外情況，可能比未記錄的變通方法更易管理。它讓審查者有具體事項可討論及記錄。然而，其可見性並不決定它是否恰當。這項決定仍取決於工作、可存取資源及周邊控制措施。

因此，直接回應應以工作負載為本。評估新選項的團隊，需要提出與實際執行要求相關的理由。只因偏好較少中斷，並不足以證明每個開發環境都應接受相同改動。

這亦改變了有用的內部文件應有的內容。只記錄設定值，會令未來維護人員無從得知原有理據。記錄被阻礙的工作負載、環境假設、負責人及審查條件，則令基礎依賴或設施改變時，這項決定仍可理解。

壓力屬於操作層面，而非理論層面。初次排障結束後，必須有人負責該設定。否則，一項原本針對特定需要的例外，可能在合理化它的工作負載消失後仍持續存在。

「沙盒」標籤並不描述整個界限

安全決定取決於實際有效的行為，而非是否出現「沙盒」一詞。

沙盒是限制程式存取周邊資源的執行界限。這個詞並不界定每項受保護資源或程序。其含義取決於實作、設定，以及工作實際運行的路徑。

Claude Code 目前的Shell 沙盒文件區分 Shell 執行、內建檔案工具、hooks 及外部工具伺服器，亦將檔案限制與網絡限制分開。這些區分可避免寬泛的產品標籤，取代對個別控制措施的理解。

新選項應在這個較狹窄的框架下評估。Anthropic 的警告涉及檔案保護，並不表示每項網絡限制均會消失、每種部署均變得脆弱，或該選項已普遍啟用。將主張延伸至這種程度，將超出現有證據。

評估任何界限變更的一個有用方法，是問變更後仍可強制執行甚麼。這比問某項功能整體是否「安全」更有資訊價值。它迫使討論聚焦於具體資源、程序及條件，而非含糊的整體評級。

例如，設想某機構在其編程代理外圍採用可丟棄環境。該環境可能提供獨立於代理設定的限制。這些限制是否足夠，須另行評估。內層控制改變，不應令其存在被假定或被否定。

反向假設同樣薄弱。稱某物為容器，並不能證明當中沒有敏感檔案，或憑證不具廣泛權限。審查者需要檢視實際提供予程序的資源。單靠架構名稱無法回答這些問題。

這正是此版本的核心取捨。擴大執行相容性可幫助代理完成正當工作。若這種擴大削弱了原本依賴的界限，便需要重新評估環境。好處與代價應放在同一項決定中。

相關證據應包括正面及負面行為。正面結果顯示目標工作負載可運行；負面結果顯示目標範圍以外的行動仍被阻擋。若沒有後者，相容性檢查對隔離程度幾乎沒有說明力。

這類檢查應使用無害的測試資源，而非敏感資料。目的是驗證限制，而非在調查期間製造事故。受控測試可揭示宣稱的界限是否符合團隊預期。

當中亦涉及溝通問題。「已啟用沙盒」是方便的狀態訊息，卻將眾多細節壓縮成二元描述。作部署決定的團隊需要更完整的版本：涵蓋哪些程序、限制哪些資源，以及適用哪些例外。

這並不表示沙盒化沒有幫助，而是表示具體說明不可或缺。清楚描述、刻意限制的控制措施，比起讓讀者各自詮釋的籠統保證更有用。

供應商復原突顯另一項可靠性問題

代理必須先符合周邊服務合約，其編程能力才有意義。

此版本中的供應商修正涉及另一種界限：客戶端與接收其請求的服務之間的介面。閘道是路由或管理這些請求的中介層。其可接受的能力可能與客戶端預期不同。

對企業用戶而言，即使模型本身可用，被拒絕的請求也可能看似模型故障。實際結果相同：有用的推理尚未開始，工作已經停止。診斷原因時，必須將服務可用性與請求相容性分開。

這種分別賦予後備行為操作上的意義。可選功能不應自動成為通用可用性的必要條件。同時，在缺少某項能力下復原亦引出另一個問題：當請求成功時，操作人員能否知道哪些功能仍然可用？

假設某個代理在調整要求後能完成工作。從使用者角度而言，成功復原固然值得歡迎；但從營運人員角度而言，記錄亦應說明當中有何變動。否則，表面上不一致的行為日後可能難以追查。

這是一項更廣泛的可靠性原則，並非聲稱此版本有未公開記錄功能。復原與可觀測性需要相輔相成。可觀測性是指擁有足夠紀錄，以理解系統的行為。當重試的成因與後果可見時，成功重試便更值得信賴。

無人值守復原的時機亦帶來相關問題。即使阻礙工作的條件已改變，工作仍可能處於停滯狀態。對依賴夜間執行的團隊來說，有用的結果是工作完成，而不只是最終得知工作已可進行。

然而，更快復原並不代表復原必然正確。無人值守的代理亦需要保留工作狀態，並避免對先前進度作出缺乏根據的假設。營運人員應評估恢復執行後的結果，而非把活動本身視為成功證明。

GitHub 的 agent firewall controls 展示了另一款產品對受管控執行的處理方式。其文件說明受限的互聯網存取，並明確指出限制。防火牆控制網絡流量；它無法回答所有關於檔案、權限或應用程式行為的問題。

這項比較支持一個審慎的結論。編碼代理愈來愈多在具有多項獨立控制措施的系統中運作。請求閘道、檔案系統限制及網絡防火牆處理的是不同問題。在其中一個邊界成功，無法證明在其他邊界亦成功。

這令實際評估比展示編碼能力更具挑戰。採購方需要評估代理能否透過其實際基礎設施完成具代表性的工作。他們亦需要證據證明復原路徑會保留其機構所要求的限制及紀錄。

壓力落在供應商身上，要解釋行為；亦落在客戶身上，要測試真實條件。當通過的展示掩蓋了生產基礎設施會拒絕的假設時，雙方都不會受益。

此版本未能證明的事項

已記錄的修正是預期變更的證據，而非普遍部署成功的證明。

現有版本資料足以支持報道新增功能與修正內容。但它並未證明這些變更能在每種 Linux 設定、閘道政策或工作負載中有效。這項限制應保持清晰可見，因為這些環境可能在營運層面存在重要差異。

引用資料中沒有獨立基準測試，顯示無人值守完成率改善多少。此處亦沒有重現的安全評估，界定新相容性選項的完整後果。因此，將其歸因於任何效能提升或普遍嚴重性評級，都缺乏支持。

最有力的懷疑觀點涉及證據質素。某項設定即使有清楚文件說明，仍可能需要在本機驗證。供應商可以準確描述修正，卻未必涵蓋每位客戶的設定。這些可能性足以支持測試；但不足以假定此版本失敗。

設定範圍帶來另一項複雜因素。Claude Code 的 settings precedence 文件區分個人、專案及受管控來源。在某個檔案可見的值，不一定能解釋實際生效的設定。審查者需要理解在受評估工作階段中，究竟載入了甚麼。

這在團隊比較結果時尤其重要。開發人員可能以為測試了相同設定，但其環境對設定的解析方式不同。在把差異歸因於模型行為前，審查者應先確認執行條件是否足夠接近，以支持該結論。

同樣的審慎態度亦適用於預設值的說法。新設定的存在，並不代表它在所有地方都已啟用。版本警告亦不能證明某個機構目前正暴露敏感檔案。這些說法需要關於該機構部署情況的證據。

公平的評估應保留正面理據。相容性改善可以移除對有用工作而言合理的障礙。更清晰的復原行為可以減少可避免的中斷。這兩項好處都不需要聲稱每個部署都應採用每個選項，或所有不確定性已消失。

對採購方而言，實際風險是把這些區別壓縮成單一審批。升級決策與例外決策值得分開推理。前者關乎新版本的行為；後者關乎機構選擇授予的權限。

對開發人員而言，風險是在疑難排解成功後失去背景資料。一旦受阻的指令能夠執行，記錄變更的即時誘因便會減弱。然而，未來維護人員正正需要這份解釋，因為可運作的設定已不再揭示當初導致問題的原因。

團隊可以將這些決策保留在其 technical knowledge base 中。有用的紀錄包括觀察到的行為、假設及未解決問題。它應幫助日後的審查者重建決策，而毋須依賴某人的記憶。

適當的結論是有條件的。此版本提供值得按受影響工作流程評估的變更。這些變更是否值得更廣泛部署，取決於代理實際運作環境所取得的證據。

Claude Code v2.1.305 推出後值得留意的事項

下一批有用訊號是可重現的邊界測試、復原證據及設定可見性。

第一個訊號，是在真實條件下對 Linux 相容性選項進行有文件記錄的測試。重要結果應結合成功執行，以及關於剩餘限制的證據。報告應識別環境，並區分觀察到的行為與對沙箱運作方式的假設。

如果合法工作負載能夠運行，同時獨立強制執行的邊界仍然有效，這將加強受控採用的理據。如果審查者無法判斷哪些內容仍受保護，信心便應維持有限。單靠通過的瀏覽器測試，無法解決安全問題。

最有用的報告亦會區分代理的內部限制與周邊基礎設施。這種區分可幫助讀者理解每項保護由哪個元件提供。否則，成功結果可能被錯誤地推廣至缺乏相同外層控制的部署。

第二個訊號，是來自受影響供應商及無人值守工作流程的證據。團隊應在其正常閘道規則下，尋找完成具代表性工作的結果。他們亦應檢視復原紀錄能否足夠清楚地說明發生了甚麼，讓營運人員調查非預期行為。

持續完成工作將支持 Anthropic 對這些已測試條件所作的可靠性說法。反覆失敗而需要更廣泛權限，或出現無法解釋的設定變更，則會削弱對部署結果的信心。兩種結果都比泛泛地說更新感覺更好更有參考價值。

第三個訊號，是對實際生效設定提供更清晰的可見性。日後若文件或介面變更能揭示改變邊界的例外情況，這些決策便更容易審核。對範圍及後果作出明確說明，亦可減少不同團隊對同一狀態作出不同解讀的機會。

如果相容性設定變得更易理解及審查，這種取捨便更易管理。如果例外情況在沒有明確擁有人的情況下累積，營運複雜度便會增加。這是觀察準則，並非對 Anthropic 下一個版本的預測。

這些訊號令焦點保持在能改變部署決策的證據上。它們避免把無關的模型公告當作執行可靠性的替代指標。更佳的編碼能力本身，無法解決有關檔案存取、閘道行為或無人值守復原的不確定性。

對考慮使用 Claude Code v2.1.305 的團隊而言，應先從令更新變得相關的工作負載開始。識別預期好處是涉及已修正的請求路徑、恢復自動化，還是執行例外。然後，應按照實際環境而非一般產品展示來評估該好處。

選擇一項具代表性的工作，並在評估此版本前定義成功標準。記錄預期輸出、獲准使用的資源，以及應繼續被阻擋的行為。將相容性決策與升級決策分開，並保留足夠證據，讓另一名審查者理解兩者。若例外情況屬必要，應指定負責人，並提供與工作負載相關的理由。若證據仍不完整，便應保留這種不確定性，而非把一次成功執行化為廣泛保證。將 Claude Code v2.1.305 視為回答具體問題的機會：這個代理能否在團隊可解釋及驗證的邊界內完成預期工作？