Claude Code 新增啟動警告:`Bash(git * main)` 這種寫法,匹配的範圍比你以為的大很多

為什麼把 * 放在指令的最前面或最後面通常沒問題,放在中間(子指令前)才特別容易出錯?

關鍵在於子指令的位置。以 Bash(npm run ) 這種寫法為例, 放在最後面,前面 npm run 這個包含子指令的部分完整寫死,所以這條規則清楚限制在「npm run 後面接任何東西」這個範圍,不會意外放行 npm install 這種完全不同的子指令。同樣道理, 放在最前面(例如官方範例裡的 Bash( --version))也是類似狀況,固定的部分在後面,語意上比較容易一眼看出實際涵蓋範圍。

真正容易出問題的是子指令本身也被包在 的匹配範圍裡的寫法——像 git * main 這種,子指令(log、merge、push 都算)夾在兩個固定文字中間,而 又可以匹配任意文字,子指令自然也在可以被替換的範圍內。這種寫法在視覺上「看起來」限制了頭尾,容易讓人誤以為中間也受到某種程度的限制,但實際上中間才是完全開放、決定這個指令具體要做什麼的關鍵部分。

這個問題實際上會造成什麼樣的安全風險,不只是「規則寫錯」這麼簡單嗎?

實際風險在於,一旦子指令落在 * 的匹配範圍裡,連帶會放行你原本完全沒想過要允許的 git 操作。以官方文件舉的例子來看,Bash(git * main) 會放行 git -c core.fsmonitor=<script> diff main 這種帶有 -c 參數的指令——-c 可以讓 git 在執行過程中跑一個你指定的外部程式,這已經不只是「git 操作範圍寫得太寬」的問題,而是這條原本以為只跟 git log 或類似操作有關的規則,實際上打開了一個可以執行任意外部指令的入口。

這也是官方文件特別把這個警告獨立列出來的原因——跟單純「規則太寬鬆,涵蓋了太多 git 子指令」比起來,這種寫法額外的風險在於,它會放行帶有危險參數(像 -c)的變化版本,而這些變化版本表面上看起來仍然是「跟 main 分支有關的 git 指令」,不容易在規則審查時被當成異常。

如果我的專案裡已經存在這種寫法的規則,實際上該怎麼檢查跟修正?

第一步是留意升級到 2.1.246 之後,啟動 Claude Code 時有沒有跳出這個警告——這個警告本身就是最直接的檢查方式,不需要自己手動去翻找設定檔案裡有沒有這種寫法。如果你手上有舊版的設定,也可以直接搜尋 settings.json 裡是不是有 Bash( 開頭、中間帶 *、後面接著非萬用字元文字的規則,特別留意那些看起來像「限定在某個分支」或「限定在某個子指令的變化版本」的規則。

第二步是針對每一條找到的規則,回頭確認原本的意圖是什麼——如果原意是「限制在某個子指令,參數不拘」,正確寫法是把 * 移到子指令之後(例如 git * main 改成 git log * main);如果原意其實就是「這幾種 git 操作,只要對象是 main 分支都放行」,那可能要重新考慮這個規則本身要不要存在,因為子指令不限這件事,本身就代表放行的範圍遠比一般人直覺以為的寬。

第三步是修正之後,實際用幾個你預期會被放行、跟你預期不該被放行的指令做測試,確認修正後的規則行為符合你的原意,而不是只看語法有沒有改對。

除了 git,這個「* 放在子指令前面」的問題,是不是也會發生在其他常用指令上?

會。這個問題本質上跟 git 本身無關,是任何「程式名稱 + 子指令 + 參數」這種結構的指令都可能遇到的匹配陷阱——只要一個工具的行為是由子指令決定(而不是單純的旗標參數),把 * 放在子指令之前,都會讓子指令本身落入可被替換的範圍。常見的例子包括 docker(docker run、docker exec 等子指令行為差異很大)、npm(npm install、npm run 意義完全不同)、或是任何你自己專案裡用到的、具有子指令結構的 CLI 工具。

實務上比較保險的檢查習慣,是每次寫 Bash 允許規則時,先問自己「這個指令的哪一部分,是真正決定它會做什麼事的關鍵字」,確保那個關鍵字(通常就是子指令)寫在 之前、被固定住,而不是讓它落在 可以匹配到的範圍裡——這個原則不是 git 專屬的,而是所有子指令結構的 CLI 工具都適用的通用檢查方式。