為您的組織管理 mods
使用受管設定控制 Claude Code mods:停止使用者安裝的 mods、僅允許您自己的 mods、檢查 mod 可以執行的操作,以及使用您自己的 mod 強制執行政策。
mod 是在 Claude Code 內執行程式碼的外掛程式,具有安裝它的使用者的權限。Mods 不是沙箱化的。透過受管設定,您可以決定 mods 是否在使用者的機器上執行、執行哪些 mods,以及執行順序。您也可以安裝自己的 mod,用來監視或拒絕其他 mods 的操作。
此頁面適用於為 Claude Code 部署受管設定的人員,無論是作為檔案、透過 MDM 或從 claude.ai 管理員主控台部署。在 Claude Code v2.1.287 及更新版本中,mods 預設為開啟。從與您要執行的操作相符的部分開始:
- 排除使用者自己的 mods,無論是否有您自己的 mods:停止使用者安裝的 mods 載入
- 查看當您不做任何更改時使用者會獲得什麼:了解預設情況下會發生什麼
- 保持 mods 開啟並設定其他限制:選擇允許的程度
這些情況在其他頁面上涵蓋:
- 您之前未部署過受管設定:從部署受管設定開始
- 您想控制使用者可以安裝哪些外掛程式:請參閱為您的組織管理外掛程式
停止使用者安裝的 mods 載入
若要防止使用者帶來的每個 mod 載入,請在內建防護上設定 allowManagedModsOnly 選項,這是一個政策 mod,Claude Code 在使用者安裝的每個 mod 之前載入。該選項位於受管設定中的 pluginConfigs 下,由 cc-plugin-sec-default@builtin 鍵入:
{
"pluginConfigs": {
"cc-plugin-sec-default@builtin": {
"options": {
"allowManagedModsOnly": true
}
}
}
}
設定受管設定中的選項後:
- 使用者帶來的任何 mod 都不會載入:這涵蓋使用者安裝的外掛程式中的 mod、使用
--plugin-dir載入的 mod,以及 Claude 在工作階段期間編寫的 mod - 您組織的 mods 仍然會載入:計為您組織的 mod 不會被檢查。所有其他 mod 都計為使用者的 mod,不會載入。這包括您從 GitHub 或其他遠端市場啟用的外掛程式中的 mod,以及您的組織為其成員在 claude.ai 上開啟的 mod。如果沒有計為您的,則不會載入任何已安裝的 mod。
- 使用者無法撤銷它:防護只從受管設定讀取選項,因此使用者、專案或本機設定檔中的相同項目,或使用
--settings傳遞的檔案中的項目,不會改變任何內容 - 檔案或 MDM 政策涵蓋每個提供者:當您以檔案或透過 MDM 方式提供選項時,它在 Amazon Bedrock、Google Cloud 的 Agent Platform 和 Microsoft Foundry 上的工作方式相同。如需從 claude.ai 管理員主控台進行交付,請參閱平台可用性
- 使用者的其他自訂設定保持有效:他們設定檔中的 hooks、狀態行和
/goal不受影響 - 內建 mods 保持執行:內建於 Claude Code 的 mods(例如
AGENTS.md支援)各有自己的開關
若要確認使用者機器上的選項,請使用 --plugin-dir 和包含 mod 的目錄路徑(例如 claude --plugin-dir ./first-mod)在該處啟動 Claude Code。mod 的 hooks 不會執行,文字記錄和偵錯日誌會有防護的訊息,其中命名 mod 和 allowManagedModsOnly。如果 mod 載入,請參閱檢查政策是否有效和決定選項是否生效的規則。
如果您在早期存取期間將 CLAUDE_CODE_ENABLE_FUNCTION_HOOKS 設定為 0,請用此選項替換它。Claude Code v2.1.287 及更新版本在任何值下都會忽略該變數,因此其中的 0 會保持 mods 開啟。
了解預設情況下會發生什麼
如果您沒有自己的 mod 設定,這就是您的使用者會獲得的:
-
Mods 已開啟。 使用者可以安裝包含來自您的外掛程式設定允許的任何市場的 mod 的外掛程式,或使用
--plugin-dir從目錄載入一個。 -
內建防護首先執行。 Claude Code 在使用者安裝的每個 mod 之前載入名為
sec-default@builtin的內建 mod。使用者無法將其關閉。/plugin和偵錯日誌將其列為cc-plugin-sec-default。防護在以下任一情況為真時載入:- 機器有受管設定
- 使用者使用 Team 或 Enterprise 計畫登入 Claude Code
使用 API 金鑰進行驗證的使用者,或透過 Amazon Bedrock、Google Cloud 的 Agent Platform 或 Microsoft Foundry,只有在具有受管設定的機器上才能獲得防護。
-
防護保護您管理的內容。 使用者的 mod 無法更改您的受管 hooks 接收或決定的內容、系統提示、您的受管
CLAUDE.md和其他受管指示、任何 mod 讀取的設定內容,或您的受管 MCP 伺服器的工具和描述。 -
允許所有其他內容。 防護不添加其他限制。使用者的 mod 仍然可以讀取和寫入檔案、啟動程序、發出網路請求、重寫工具呼叫和提示、拒絕工具呼叫、批准否則會提示的呼叫,以及在介面中繪製,所有這些都具有該使用者的權限。
-
拒絕規則和您的受管 hooks 優先。 防護載入的地方,使用者的 mod 無法批准
deny規則拒絕的呼叫,無論哪個設定檔持有該規則。來自受管設定中PreToolUsehook 的塊也是最終的。兩者都適用於 Claude 的工具呼叫。兩者都不適用於 mod 自己的$.fs和$.process呼叫:拒絕Read(.env)後,mod 仍然可以使用$.fs.read讀取該檔案或啟動執行該操作的程式。若要限制這些呼叫,請防止 mod 載入或在政策 mod 中掛接呼叫。 -
其他權限檢查可以被覆蓋。 批准工具呼叫的使用者 mod 可以批准
ask規則會提示的呼叫,或受管設定外的PreToolUsehook 阻止的呼叫。在自動模式下,mod 批准的呼叫執行時不進行分類器檢查。
防護的來源在 Claude Code 儲存庫的 mods/sec-default 目錄中是公開的。
了解哪些控制仍然適用
Mods 不會取代您已有的控制:
- 設定 hooks 保持有效。 設定檔和外掛程式
hooks/hooks.json中的命令、HTTP、提示和代理 hooks 像以前一樣執行,與 mods 並行。它們沒有任何內容已棄用。 - 拒絕規則在防護載入的地方優先。 使用者的 mod 無法批准
deny規則拒絕的呼叫,除非您設定allowModsToOverrideDenyRules。 - 受管 hooks 首先執行。 受管設定中的
PreToolUsehook 在任何 mod 看到工具呼叫之前執行,其塊是最終的。如果 mod 隨後重寫呼叫,您的受管 hooks 在重寫的呼叫上再次執行,因此塊仍然適用。來自其他設定檔和外掛程式的PreToolUsehooks 在最後一個 mod 之後執行,因此返回自己結果代替執行工具的 mod 會防止這些執行。請參閱 mods 執行的順序。 - 網路政策涵蓋
$.http.fetch。 如果您的組織關閉網路擷取,或工作階段關閉非必要網路流量,Claude Code 會拒絕 mod 使用$.http.fetch發出的網路請求。該政策不涵蓋 mod 使用$.process.run啟動的程式。該程式使用使用者自己的存取權限到達網路。 - 外掛程式控制涵蓋 mods。 Mod 是外掛程式,因此限制使用者可以安裝的設定(例如
strictKnownMarketplaces)決定是否可以安裝它。 - Mods 無法更改權限提示。 Mod 可以重新設定 Claude Code 介面的大部分,但不能重新設定權限提示,因此無法更改提示顯示的內容。Mod 仍然可以在提示出現之前批准或拒絕工具呼叫,如了解預設情況下會發生什麼所述。
- 信任提示優先。 在使用者尚未信任的目錄中的互動工作階段中,在他們回答信任提示之前,沒有 mod 載入。
--safe-mode關閉已安裝的 mods,包括您的。 使用claude --safe-mode啟動工作階段以檢查 mod 是否導致問題。
這些控制都不會沙箱化 mod。您允許的 mod 以使用者身份執行,具有使用者對檔案、程序和網路的存取權限。
決定是否保持 mods 開啟
Mod 可以做的比外掛程式的其他部分更多,因為它在 Claude Code 內執行。它看到每個提示和工具呼叫,可以更改它們,並可以在權限提示出現之前允許或拒絕工具呼叫。
使用者可以載入為 mod 的內容取決於您已有的外掛程式控制:
| 您今天的外掛程式控制 | 使用者可以載入為 mod 的內容 |
|---|---|
| 無 | 來自任何市場、任何目錄(使用 --plugin-dir)或 Claude 在工作階段期間編寫的 mod |
| 市場允許清單 | 來自您允許的市場的 mod,或來自任何目錄(使用 --plugin-dir)的 mod。Claude 在工作階段期間編寫的 mod 只有在允許清單包含 skills-dir 時才會載入。 |
市場允許清單和 disableSideloadFlags |
來自您允許的市場的 mod |
為您的組織管理外掛程式列出外掛程式載入的每種方式和控制每種方式的設定。
若要在使用者安裝市場中的 mods 之前檢查它們,請參閱檢查 mod 可以執行的操作。若要在您完成此操作之前排除使用者的 mods,請參閱停止使用者安裝的 mods 載入。
檢查 mod 可以執行的操作
您可以看到 mod 能夠執行的操作而無需執行它。在您的 shell 中,在外掛程式的目錄上執行 claude plugin validate:
claude plugin validate ./some-mod
輸出中的兩行描述 mod 的程式碼:
❯ ./register.js hooks: session.start, tool.call, ui.render{component=Pane}
❯ ./register.js calls: $.fs.read, $.http.fetch, $.store.set, $.ui.open
hooks: 行列出 mod 接收的事件。calls: 行列出其程式碼呼叫的 mods API 方法。mods API(在 mod 的程式碼中寫為 $)是 mod 到達檔案、程序和網路的方式。Claude Code 拒絕載入以此命令無法讀取的方式使用 mods API 的 mod。
查看 calls: 行以了解這些:
| 呼叫 | 它的意思 |
|---|---|
$.fs.read, $.fs.write |
讀取或寫入使用者可以存取的任何地方的檔案 |
$.process.run, $.process.spawn |
以使用者身份啟動程式 |
$.http.fetch |
發出網路請求 |
$.env.get, $.settings.read |
讀取環境變數和設定,可以保存 API 金鑰。輸出中的 env reads: 行命名每個變數。 |
$.env.set |
為 Claude Code 和它啟動的每個命令和 MCP 伺服器設定環境變數,可以更改這些程式執行的內容。env writes: 行命名每個變數。 |
$.mcp.call |
在連接的 MCP 伺服器上呼叫工具,受工作階段的權限規則約束 |
$.model.complete |
使用使用者的計畫或 API 金鑰進行模型呼叫 |
$.prompt.submit |
提交提示,可以將其作為使用者自己的話語發送 |
$.session.send |
發送另一個工作階段或子代理的 Claude 讀取的訊息 |
在 hooks: 行中,tool.call 和 prompt.submit 表示 mod 看到每個工具呼叫和每個提示,並可以更改它們。session.append 表示 mod 可以在儲存前重寫對話的每一行。ui.render{component=AskUserQuestion} 表示 mod 可以重繪 Claude 用來詢問使用者問題的對話框。tool.check 表示 mod 可以在權限提示出現之前批准或拒絕工具呼叫。了解預設情況下會發生什麼列出您的哪些規則和 hooks 優先於其答案。
選擇允許的程度
Mod 政策的範圍從根本沒有已安裝的 mods 到使用者選擇的任何 mod,以及您自己的 mod 檢查其他 mods,每一個都是幾個受管設定。在第一列中找到您想要的政策,並設定第二列命名的內容。部署受管設定涵蓋受管設定的位置。
| 您想要的 | 設定 |
|---|---|
| 沒有已安裝的 mods,hooks 保持不變 | 設定 allowManagedModsOnly 並且不部署您自己的 mods |
| 沒有已安裝的 mods 和根本沒有 hooks,包括您的受管 hooks | 將 disableAllHooks 設定為 true |
| 僅您組織的 mods | 設定防護的 allowManagedModsOnly 選項,並安裝您的 mods 使其計為您的 |
| 來自您批准的市場的任何 mod | 保持您的市場限制,並將 disableSideloadFlags 設定為 true |
| 任何 mod,您自己的 mod 檢查其他 mods | 安裝您的 mod,並在 prependPlugins 中與 sec-default@builtin 一起列出它 |
每個設定的作用:
allowManagedModsOnly:內建防護上的選項。使用者自己的 mods 不會載入,他們的設定 hooks、狀態行和/goal保持有效。停止使用者安裝的 mods 載入列出它涵蓋的內容。allowManagedHooksOnly:更廣泛的設定。只有您組織的 mods 和內建於 Claude Code 的 mods 載入。使用者自己安裝的 mod 不會。該設定也會阻止使用者自己設定檔中的 hooks。在設定之前,請閱讀在allowManagedHooksOnly下執行的內容。disableAllHooks:最廣泛的設定。在受管設定中,它停止每個已安裝外掛程式中的 mods,包括您的,並關閉設定檔中的每個 hook,因此您受管設定中的PreToolUsehook 不再阻止任何內容。自訂狀態行和/goal也停止工作。在設定之前,請閱讀disableAllHooks。disableSideloadFlags:在啟動時拒絕--plugin-dir和--plugin-url,因此沒有人從目錄載入 mod,並防止 Claude 在工作階段期間編寫的 mods 載入。該設定也拒絕--agents和--mcp-config。在設定之前,請閱讀disableSideloadFlags。
內建於 Claude Code 的 Mods(例如 AGENTS.md 支援)不受這些設定影響。每個都有自己的開關。
未載入 mod 的使用者在其偵錯日誌中找到原因。拒絕訊息列出 allowManagedHooksOnly 和 disableAllHooks 的行,來自內建防護的訊息有 allowManagedModsOnly 的行。
在內建防護上設定選項
內建防護採用兩個選項。在受管設定中的 pluginConfigs 下設定它們,由 cc-plugin-sec-default@builtin 鍵入,如停止使用者安裝的 mods 載入中的範例所示。
該表格給出您的使用者在每個選項未設定和設定為 true 時獲得的內容:
| 選項 | 未設定 | true |
|---|---|---|
allowManagedModsOnly |
使用者自己的 mods 載入 | 只有您組織的 mods 和內建於 Claude Code 的 mods 載入。Claude Code 拒絕所有其他 mods,包括使用者安裝的或使用 --plugin-dir 命名的。 |
allowModsToOverrideDenyRules |
拒絕規則優先於使用者的 mods | 批准工具呼叫的使用者 mod 可以批准 deny 規則拒絕的呼叫 |
這些規則決定選項是否生效:
- id 在這裡有一個拼寫:Claude Code 只在
cc-plugin-sec-default@builtin下讀取選項。prependPlugins也接受sec-default@builtin,而pluginConfigs不接受。 - 只有受管設定計數:使用者、專案或本機設定檔中的相同項目,或使用
--settings傳遞的檔案中的項目,既不設定選項也不鬆動選項 - 防護必須載入:如果您設定
prependPlugins,在清單中命名防護。防護不載入的地方,選項都不適用。 - 防護失敗關閉:如果防護無法讀取受管設定,它拒絕每個使用者的 mod 在載入時。如果它無法檢查使用者的 mod 批准的呼叫的拒絕規則,它拒絕呼叫。
來自內建防護的訊息是您的使用者在任一選項適用時看到的。
執行您組織自己的 mods
您可以將您自己的 mods 部署到每個使用者,選擇它們相對於使用者 mods 的執行位置,並使用一個來強制執行政策。
安裝您組織的 mods 並設定順序
您組織的 mods 在使用者 mods 不載入的地方載入,並可以在它們之前執行,因此 Claude Code 必須能夠判斷 mod 來自您。它只在所有這些都為真時才將 mod 視為您組織的:
- 受管
enabledPlugins將 mod 的外掛程式設定為true - 受管設定按絕對路徑命名外掛程式的市場為使用者機器上的目錄。
extraKnownMarketplaces項目執行此操作並為使用者註冊市場。 - 市場按相對路徑列出外掛程式,因此 Claude Code 從該目錄就地載入它
為了滿足它們,讓您的裝置管理將市場目錄複製到每台機器上的相同路徑。使目錄和其上方的每個目錄只能由管理員寫入,如受管設定檔案一樣。任何可以在那裡寫入的人都可以重寫您的 mod。您從 claude.ai 管理員主控台交付的受管設定可以攜帶金鑰,但它們無法將目錄放在機器上。
該目錄持有市場的清單和外掛程式:
/opt/acme/claude-plugins/
├── .claude-plugin/
│ └── marketplace.json
└── plugins/
└── acme-guard/
├── .claude-plugin/
│ └── plugin.json
└── hooks/
├── hooks.json
└── register.js
清單按相對於該目錄的路徑列出外掛程式:
{
"name": "acme-tools",
"owner": { "name": "Acme" },
"plugins": [
{ "name": "acme-guard", "source": "./plugins/acme-guard", "description": "Acme policy mod" }
]
}
Claude Code 複製到其快取中的外掛程式計為使用者的,即使受管 enabledPlugins 啟用它。這涵蓋來自 GitHub、git、URL 或 npm 來源的每個外掛程式。其 mod 在使用者 mods 中執行,prependPlugins 和 appendPlugins 跳過它,它不在 allowManagedModsOnly 或 allowManagedHooksOnly 下載入。使用者的偵錯日誌有一行以外掛程式的 id 和 is enabled by managed settings, but 開頭。
Claude Code 每次即將採取行動(例如執行工具)時都會引發事件,並依次將其傳遞給每個 mod。計為您的 mod 在使用者 mods 之前執行,即使您在任何地方都沒有列出它。若要設定其位置,請在兩個設定之一中列出其 id。id 是外掛程式的名稱、@ 和市場的名稱,例如 acme-guard@acme-tools。
prependPlugins:您的 mod 在任何使用者的 mod 之前看到每個事件,並在之後看到每個結果。它可以更改事件、拒絕它或跳過使用者的 mods。appendPlugins:您的 mod 在每個使用者的 mod 之後執行,因此它只看到這些 mods 傳遞的事件,以及它們傳遞的形式
此範例在 /opt/acme/claude-plugins 聲明 acme-tools 市場,從中啟用 acme-guard,並首先執行該 mod,內建防護在其後:
{
"extraKnownMarketplaces": {
"acme-tools": {
"source": { "source": "directory", "path": "/opt/acme/claude-plugins" }
}
},
"enabledPlugins": { "acme-guard@acme-tools": true },
"prependPlugins": ["acme-guard@acme-tools", "sec-default@builtin"]
}
每個金鑰執行一項工作:
extraKnownMarketplaces:命名持有acme-tools市場的目錄。path是包含.claude-plugin/marketplace.json的目錄的絕對路徑。enabledPlugins:為接收這些受管設定的每個使用者開啟acme-guardprependPlugins:將acme-guard放在首位,內建防護放在第二位,兩者都在使用者安裝的任何 mod 之前。Claude Code 遵循您列出的順序。
若要確認使用者的機器收到了設定,請參閱檢查政策是否有效。
若要確認 mod 執行的位置,請在該機器上使用 claude --debug 啟動工作階段,並在偵錯日誌中搜尋 mod 的 id:
hooks module acme-guard@acme-tools loaded,帶有tier prepend:mod 計為您組織的並首先執行- 相同行帶有
tier user:Claude Code 將其視為使用者的 mod。第二行prependPlugins names acme-guard@acme-tools, which is not an enabled managed plugin with a hooks module; skipped表示清單跳過了它。
這些規則決定兩個清單中的哪些 ids 生效:
- 清單替換預設值:當您在受管設定中設定
prependPlugins時,在其中命名sec-default@builtin以保持內建防護。防護是內建的,不需要enabledPlugins項目。 - 您自己的 ids 必須計為您的:在受管設定中,Claude Code 跳過其外掛程式不符合組織 mod 三個條件的 id
- 儲存庫無法設定它們:Claude Code 從受管設定讀取兩個設定,從不從儲存庫的設定檔讀取。使用者可以在
~/.claude/settings.json中設定它們以在沒有受管設定的機器上排序他們自己的 mods,並且只有在他們未使用 Team 或 Enterprise 計畫登入時。在其他任何地方,Claude Code 忽略使用者設定中的兩個金鑰。那裡的清單既不添加也不移除內建防護。
使用您自己的 mod 強制執行政策
若要排除每個使用者的 mod,您不需要您自己的 mod。設定 allowManagedModsOnly。當您想要允許某些使用者的 mods 並拒絕其他的,或記錄 mods 執行的操作時,編寫政策 mod。
每次另一個 mod 即將載入時,您的 mod 會在名為 plugin.register 的事件中接收 claude plugin validate 列印的清單。prependPlugins 中的 mod 可以讀取該清單並拒絕 mod。它也可以按名稱掛接任何 mods API 呼叫以記錄或拒絕每個其他 mod 的該呼叫。名稱是沒有 $. 的方法,因此 fs.write 上的掛接看到每個 $.fs.write 呼叫。
此政策 mod 拒絕任何使用者的 mod,其自己的程式碼呼叫 $.process.run 或 $.process.spawn。它也保持審計日誌,將每個工具呼叫和每個 mod 寫入的檔案寫入偵錯日誌。因為它首先執行,日誌記錄在任何使用者的 mod 更改它之前請求的內容。將其儲存為 acme-guard/hooks/register.js:
// 沒有使用者的 mod 可能呼叫的方法,每個拼寫為 namespace.method
const BLOCKED_CALLS = ['process.run', 'process.spawn']
export function register(on) {
// 每次另一個 mod 即將載入時執行
on('plugin.register', async ($, e, next) => {
// 保持該 mod 程式碼中在阻止清單上的呼叫
const blocked = e.uses.calls.filter((call) => BLOCKED_CALLS.includes(call))
if (e.tier === 'user' && blocked.length > 0) {
// 返回 refuse 防止 mod 載入,文字是原因
return { refuse: 'Acme policy: mods may not call ' + blocked.join(', ') }
}
// 讓所有其他 mod 載入
return next(e)
})
// 記錄每個工具呼叫,然後讓它繼續不變
on('tool.call', async ($, e, next) => {
$.ui.log('audit tool.call ' + e.tool, { to: 'debug' })
return next(e)
})
// 記錄哪個 mod 寫入了檔案,然後是路徑,引用因為 mod 選擇了它
on('fs.write', async ($, e, next) => {
$.ui.log('audit fs.write by ' + next.origin.plugin + ' ' + JSON.stringify(e.path), { to: 'debug' })
return next(e)
})
}
該檔案註冊三個 hooks:
plugin.register:決定另一個 mod 是否載入。它拒絕呼叫阻止方法的使用者 mod,並傳遞所有其他 mod。tool.call:為每個工具呼叫寫入一行(例如audit tool.call Bash)到偵錯日誌,並不改變任何內容fs.write:為每個$.fs.write呼叫另一個 mod 發出寫入一行(例如audit fs.write by reader "/tmp/notes.md"),並不改變任何內容。mod 的名稱首先出現,路徑被引用,因此 mod 選擇的路徑無法通過作為該行的另一個欄位。
plugin.register hook 讀取事件的兩個欄位:
e.tier:mod 將執行的位置,prepend、user、append或builtin之一。每個人安裝的每個 mod 都是user。e.uses.calls:mod 呼叫的 mods API 方法,每個拼寫為namespace.method(例如process.run),不帶claude plugin validate列印的$.
當使用者安裝呼叫 $.process.run 的 mod 時,mod 不會載入,其偵錯日誌有一行以 refused by acme-guard: 和您的原因結尾。拒絕也到達熱重新載入外掛程式目錄的工作階段中的文字記錄。若要阻止呼叫而不拒絕整個 mod,請從該呼叫名稱上的 hook 返回 { deny: 'your reason' }。
若要將審計行發送到偵錯日誌以外的地方,請從相同的 hooks 呼叫 $.http.fetch。
工作階段可以在沒有您的 mod 的情況下執行。如果執行已安裝 mods 的工作執行緒崩潰三次,Claude Code 卸載每個不是內建的 mod,包括您的,直到使用者執行 /reload-plugins 或啟動新工作階段。使用者使用 --safe-mode 啟動 Claude Code 時,執行時沒有已安裝的 mods,包括您的。
建立 mod涵蓋 mod 需要的檔案。測試判斷其他 mods 的 mod有此政策 mod 的測試檔案。
當您的檢查失敗時拒絕 mods
如果您的 plugin.register hook 拋出或超過其時間限制,Claude Code 跳過 hook,因此檢查失敗開啟,它正在檢查的 mod 載入。若要失敗關閉並拒絕使用者的 mods,請將檢查移到命名函數中,並添加返回拒絕的 .catch 處理程式。此檔案版本僅顯示 plugin.register hook,因此保持第一個版本中的兩個審計 hooks 在 register 中:
const BLOCKED_CALLS = ['process.run', 'process.spawn']
// 與之前相同的檢查,移到其自己的函數中
async function checkMod($, e, next) {
const blocked = e.uses.calls.filter((call) => BLOCKED_CALLS.includes(call))
if (e.tier === 'user' && blocked.length > 0) {
return { refuse: 'Acme policy: mods may not call ' + blocked.join(', ') }
}
return next(e)
}
export function register(on) {
// 處理程式僅在 checkMod 拋出或超過其時間限制時執行
on('plugin.register', checkMod).catch(async ($, e, next) => {
// 讓您組織的 mods 和內建 mods 載入
if (e.tier !== 'user') return next(e)
// 拒絕無法檢查的使用者 mod
return { refuse: 'Acme policy check failed, so this mod was not loaded' }
})
}
處理程式就位後,在檢查拋出或超時時正在檢查的 mod 不會載入,拒絕行帶有第二個原因,如 refused by acme-guard: Acme policy check failed, so this mod was not loaded。處理程式將 user 層外的每個 mod 傳遞給 next(e),因此失敗的檢查不會停止您組織列出的 mods。處理失敗的 hook涵蓋其他事件的 .catch。
後續步驟
- 外掛程式安全性:任何外掛程式在使用者機器上可以執行的操作,以及如何在安裝前檢查一個
- Mods 概述:什麼是 mod 以及它與 hooks、skills 和 MCP 伺服器的比較
- mods 執行的順序:
prependPlugins和appendPlugins如何與使用者 mods 配合 - 設定和環境變數:此頁面上命名的每個設定在一個表格中