# Claude Code 2.1.268：deny 規則與 MCP 修正了什麼

> Claude Code 2.1.268–2.1.269 修正了四項權限問題，以及 /mcp 中的機密資訊外洩。本文說明受影響的對象、更新方式，以及如何檢查規則。

Source: https://ailoot.ai/blog/zh-hant-tw/claude-code-2-1-268-fixes/
Canonical: https://ailoot.ai/blog/zh-hant-tw/claude-code-2-1-268-fixes/
Language: zh-Hant-TW
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-040
Revision: sha256-dbcafb6356442a18a1b3e137e2b69af3e6a95ba4671f52e56718113f8f999fad


Claude Code 2.1.268 版於 2026 年 9 月 10 日發布，隔天接著發布 2.1.269。請立即更新：有兩種情況下，你用來封鎖代理程式存取 `.env` 和服務資料夾的 deny 規則悄悄失效了。此外，`/mcp` 指令可能會在終端機中印出設定檔裡的機密資訊。

以下內容皆根據資料來源日期，也就是 2026 年 9 月 17 日當時的 Anthropic 官方變更記錄與文件整理。該日的最新版本是 2.1.274。我們根據這些項目說明錯誤的運作方式；並未在有漏洞的版本上重現這些繞過情況。

如需 Ailoot 的其他使用說明，請參閱[文件](https://ailoot.ai/docs/)。



## Claude Code 2.1.268 和 2.1.269 修正了什麼？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section takeaway">

本節重點

修正了四項權限問題。透過符號連結存取路徑時，deny 和 ask 規則沒有生效；而在包含 `env -C` 或 `eval` 的行上，Read 或 Edit 的 deny 可能失效。含有「!」的規則套用範圍超出其設定檔。`tee` 指令可以寫入檔案，而不受 Edit 的 deny 規則封鎖。此外，`/mcp` 和 `claude mcp list` 會顯示設定檔中的機密資訊，外掛程式錯誤則會顯示 Git URL 中的權杖。

</div>

有四項修正與權限規則相關：

1.  **符號連結上的拒絕規則沒有生效。** 對符號連結目錄（macOS 上的 `/etc`、`/tmp`、`/var`，以及 Linux 上的 `/bin`）設定的 deny 和 ask 規則，在路徑以實際位置指定時不會觸發。Bash 指令也會忽略透過符號連結路徑設定的 deny 規則。
2.  **搭配 `env -C` 或 `eval` 時，讀取和編輯的拒絕規則會失效。** 如果同一個指令行中含有權限檢查無法解析的語法，Read 或 Edit 的 deny 可能不會觸發。
3.  **含有「!」的規則套用範圍超出預期。** 以 `!` 開頭的 deny 或 ask 規則會套用到其設定檔以外的範圍。現在規則只會套用於自身的來源中，單獨的否定符號 `!` 則會被忽略。
4.  **`tee` 繞過拒絕規則寫入檔案。** `Edit()` 的 deny 規則和寫入路徑檢查不會套用到 Bash `tee` 指令建立的檔案。`Bash(tee:*)` 權限不再涵蓋工作目錄以外的寫入操作。

這些版本也修正了兩項涉及機密資訊外洩的問題。WebFetch 不再無限期等待持續保持連線的伺服器回應：要求現在會在 300 秒後失敗，並可透過 `CLAUDE_CODE_WEBFETCH_DEADLINE_MS` 變數設定逾時時間。此外，也修正了長時間閒置工作階段中持續高 CPU 使用率的問題。

## Claude Code 的拒絕規則如何運作？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section takeaway">

本節重點

規則寫在 `settings.json` 的 `permissions` 區塊中：deny 會封鎖操作，ask 會要求確認，allow 則允許操作而不需確認。檢查順序為 deny、ask、allow。規則格式為 `Tool` 或 `Tool(detail)`，例如 `Read(./.env)`。

</div>

Claude Code 有三類規則清單：**deny**（一律禁止）、**ask**（執行操作前先詢問），以及 **allow**（無須確認即可執行）。代理程式準備執行操作時，會嚴格依照這個順序檢查規則。符合條件的 deny 會取消同一操作的 allow：allow 規則不能例外允許已被拒絕的操作。

規則儲存在三個位置：使用者規則位於 `~/.claude/settings.json`，專案規則位於儲存庫中的 `.claude/settings.json`，本機規則位於 `.claude/settings.local.json`。以下是拒絕讀取含有金鑰檔案的設定範例：

```json
{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(rm *)"
    ]
  }
}
```

在工作階段中執行 `/permissions`，即可查看所有啟用中的規則，以及每條規則所屬的檔案。如果規則封鎖了讀取操作，拒絕訊息會指出該規則，這對下方的檢查很有幫助。



## 哪些錯誤影響了拒絕規則和規則的適用範圍？

這些錯誤影響路徑和指令檢查，也影響來自不同設定檔的規則適用範圍。

**第一種情況：符號連結。** 在 macOS 上，`/etc`、`/tmp` 和 `/var` 是指向 `/private` 底下實際資料夾的符號連結；在 Linux 上，`/bin` 通常也是類似的符號連結。如果你針對某種路徑寫法設定 deny 規則，但代理程式以另一種寫法存取（例如使用實際位置而非符號連結），規則就不會觸發。Bash 指令也會忽略針對符號連結路徑設定的拒絕規則。2.1.268 修正了這兩種情況：無論使用哪種路徑寫法，規則現在都會生效。

**第二種情況：同一行中的 `env -C` 和 `eval`。** 權限檢查會解析指令，以判斷它將存取哪些檔案。它無法解析 `env -C` 或 `eval` 等語法。問題在於，當這類語法出現在該行時，Read 或 Edit 的 deny 可能不會套用。因此，指令可能繞過對受保護檔案讀取或編輯操作的拒絕規則。

**第三種情況：含有「!」的規則套用範圍超出自身界線。** 以 `!` 開頭的規則應只在其所寫入的設定檔中生效。2.1.269 之前，它也會套用到其他設定來源。現在適用範圍限制在其自身檔案中，單獨的 `!` 規則則會被忽略。

**第四種情況：透過 `tee` 寫入。** Bash 的 `tee` 指令可以寫入檔案。寫入路徑檢查和 `Edit()` deny 規則不會套用到該檔案。同時，`Bash(tee:*)` 權限涵蓋了工作目錄以外的寫入操作。2.1.269 開始將這些檢查套用到透過 `tee` 的寫入：檔案上的拒絕規則會生效，而 `Bash(tee:*)` 只涵蓋工作目錄。

如果你使用針對特定項目的拒絕規則來封鎖 `.env`、幾個服務資料夾或危險指令，也應檢查這些規則。步驟如下。

## 為什麼 /mcp 可能會顯示你的金鑰？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section takeaway">

本節重點

MCP 設定檔中的金鑰通常透過 `${VAR}` 變數提供。`/mcp`、`/plugin`、`claude mcp list` 和 `claude mcp get` 指令，以及 MCP 登入錯誤，都會顯示替換後的值，也就是金鑰本身。2.1.268 已將輸出中的機密資訊遮蔽。

</div>

MCP 伺服器設定檔通常會將金鑰存放在環境變數中，並透過 `${VAR}` 參照，讓檔案可以存放在儲存庫中而不包含機密資訊。問題在於，檢視指令（`/mcp`、`/plugin`、`claude mcp list`、`claude mcp get`）和 MCP 登入錯誤訊息，會顯示已替換變數值的設定檔。金鑰本身因此出現在畫面上。

另一項修正涉及外掛程式和市集錯誤：這些錯誤可能會顯示來源 Git URL 中的權杖或密碼。

如果舊版的 `/mcp` 或 `claude mcp list` 輸出曾出現在串流、螢幕截圖、傳給同事的訊息，或離開你電腦的記錄檔中（包括自動傳送的內容），請假設 MCP 設定檔中的金鑰已外洩，並進行輪替。如果輸出從未離開你的電腦，更新即可。我們另有 MCP 伺服器和現成設定指南：[Claude Code MCP 伺服器](https://ailoot.ai/blog/zh-hant-tw/mcp-servers-claude-code/)。

## 這些版本中的其他變更

**WebFetch 和成品。** 先前，deny 或 ask 中未指定詳細資訊的 `WebFetch` 規則，也會套用到已發布成品的讀取和修改操作。從 2.1.268 開始，該規則不再套用到成品。若要封鎖成品，你需要另外設定 `Artifact` 規則或網域規則，例如 `WebFetch(domain:claude.ai)`。如果你仰賴一般的 WebFetch 拒絕規則來防止讀取成品，請重新檢查設定：原本的規則不再封鎖這些操作。

**WebFetch 現在設有逾時。** 對持續保持連線且不結束回應的伺服器所發出的要求，現在會在 300 秒後失敗。先前這類要求可能會無限期掛起。可透過 `CLAUDE_CODE_WEBFETCH_DEADLINE_MS` 變數設定此行為；將其設為 0 可停用逾時。

**已修正閒置工作階段中持續高 CPU 使用率的問題。** 在長時間閒置的工作階段中，Claude Code 的閒置迴圈可能導致 CPU 使用率持續偏高。此錯誤已在 2.1.268 修正。長時間整天保持工作階段開啟的使用者也可能受到影響。

**安裝最新版本。** 2.1.269 出現了一個新錯誤：工作階段執行很長一段時間後，只讀取資料的 Bash Git 指令開始要求權限。此問題已在 2.1.270 修正。因此，請更新至最新版本（截至 2026 年 9 月 17 日，最新版本是 2.1.274）；不要停留在 2.1.268 或 2.1.269。

## 如何更新並確認拒絕規則有效？

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Section takeaway">

本節重點

使用 `claude --version` 查看版本，更新至最新版本，接著用不含機密資訊的安全檔案進行測試：為檔案新增 deny 規則，要求代理程式讀取檔案，並確認拒絕訊息指出你的規則。

</div>

1.  **確認目前版本。** 在終端機中執行 `claude --version`。上述問題的修正分別在 2.1.268 和 2.1.269 發布。如果版本號低於 2.1.268，表示你的版本尚未包含這些修正；不過你是否受到各項問題影響，取決於你使用的路徑、指令和規則。
2.  **更新。** [如何將 Claude Code 更新至最新版本](https://ailoot.ai/blog/zh-hant-tw/update-claude-code/)指南提供逐步說明和疑難排解資訊。請選擇最新版本，不要停留在 2.1.268。
3.  **測試拒絕規則。** 不要用真正的 `.env` 測試規則：如果拒絕失效，代理程式就會看到真正的金鑰。請建立測試檔案，例如 `secret-test.txt`，並在其中放入任意文字，例如「這是測試」；在專案 `.claude/settings.json` 的 deny 清單中加入規則 `"Read(./secret-test.txt)"`；重新啟動工作階段，然後詢問：「讀取 secret-test.txt 檔案，並告訴我裡面有什麼。」預期結果是系統拒絕讀取並指出你的規則。如果代理程式讀取了檔案，代表這次測試中的拒絕規則沒有生效。請先檢查上方章節中的語法，並開啟 `/permissions` 查看啟用中的規則及其載入來源檔案。單靠測試結果無法判斷原因。一次拒絕只能證明針對該檔案的規則有效，無法說明其他規則的狀況；請用相同方式逐一檢查。
4.  **如果你使用這些路徑，請檢查符號連結情況。** 如果你在 macOS 上針對 `/tmp`、`/etc` 或 `/var` 設定拒絕規則，或在 Linux 上針對 `/bin` 設定拒絕規則，請在更新後針對這些路徑重做測試。
5.  **檢查含有「!」的規則。** 如果你使用了這類規則，請確認每條規則都寫在預期套用的檔案中。

如果拒絕規則有效，但 Claude Code 仍無法看到你需要的檔案，請參閱另一篇說明：[為什麼 Claude Code 無法看到專案檔案](https://ailoot.ai/blog/zh-hant-tw/claude-code-cant-see-project-files/)。

## 如果你現在無法更新

有時你必須延後更新：你無法變更環境、電腦由公司管理，或你需要先完成目前的工作。在更新之前，你可以採取以下措施降低風險：

- 針對路徑的兩種寫法，也就是符號連結和實際位置，都設定 deny 規則（在 macOS 上，實際路徑位於 `/private` 底下）；
- 不要在同一行組合多個指令，並避免在要求代理程式執行的指令中使用 `env -C` 和 `eval`；
- 不要向任何人展示 `/mcp`、`/plugin`、`claude mcp list` 或 `claude mcp get` 的輸出；如果 MCP 設定檔中的金鑰可能落入他人手中，請輪替這些金鑰；
- 請記住，`tee` 會繞過 Edit 的 deny 規則寫入檔案——如果 Bash 已獲准，就不要認為檔案受到保護。

這些措施可以降低特定繞過情況發生的可能性，但不能取代修正。請盡快更新，並執行前一節中的測試。

## 簡短總結

2.1.268 和 2.1.269 版本修正了 Claude Code 的四項權限問題：符號連結、含有 `env -C` 和 `eval` 的行、套用範圍超出自身檔案的「!」規則，以及透過 `tee` 寫入的問題。此外，也修正了 `/mcp` 輸出中的機密資訊外洩，以及外掛程式錯誤中顯示權杖的問題。請確認版本號、更新至最新版本，並使用上方章節中的測試檔案執行測試。拒絕訊息指出你的規則，表示該規則在這次測試中有效。只確認設定中存在規則，並不足以驗證它是否有效。

<div class="section" role="doc-bibliography" aria-label="Sources">

### 來源

- Claude Code，官方變更記錄（2.1.268、2.1.269、2.1.270 的項目）：<https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md>
- Claude Code，npm 上的版本發布日期：<https://www.npmjs.com/package/@anthropic-ai/claude-code>
- Claude Code，權限文件（deny/ask/allow 語法）：<https://code.claude.com/docs/en/permissions>
- Claude Code，GitHub 上的發布版本：<https://github.com/anthropics/claude-code/releases>

</div>





如需繼續使用模型，請前往 [Ailoot](https://ailoot.ai/)。

## 常見問題：Claude Code 2.1.268：deny 規則與 MCP 修正了什麼

### 如何在不暴露真實機密的情況下測試 deny 規則？

建立只含無害文字的測試檔，禁止 Read 讀取該檔，重新啟動工作階段後請代理讀取。預期應拒絕並指出你的規則。可能失敗的測試絕不能拿真實 .env 檔執行。

### 一次成功拒絕，就證明全部權限都安全嗎？

不能；只驗證了該檔案與該存取路徑。先在 /permissions 檢查生效規則，再測試你依賴的其他路徑和情境；涉及符號連結時也要測試相應寫法。


## Ailoot · 公司及其專案組合

Ailoot以累積的營運經驗、廣大的客戶群、穩定的服務及持續的KPI管理為基礎。

公司及其專案組合：數百萬客戶，每月銷售額達數十億。

Ailoot將這些營運經驗用於API存取，讓客戶的產品、代理、應用程式及自動化流程使用AI功能。