AI 代理打開一個專案，會自己讀哪些檔案？

你把一個不是自己寫的專案抓下來，叫代理「看一下」。它讀進去的不只是程式碼——專案裡有一批檔案是設定，讀到就生效，而你以為會攔住它的那道信任提示，攔的範圍比你想的窄。

三層：指示、設定、版本控制

指示層是代理啟動時當成指令讀進去的文字。Claude Code 官方文件寫明，CLAUDE.md、CLAUDE.local.md 與 .claude/rules/ 底下沒有 paths 的規則都在 session 開始時載入；Codex 走 AGENTS.md，從全域目錄一路走到你的工作目錄。這些檔案只要在專案裡就會被讀，不會問你。會跳對話框的只有一種：@ import 指到專案外面的路徑。

設定層是會叫起程式的那些鍵：settings 檔裡的 hooks 與 env、apiKeyHelper 這類 helper 指令、.mcp.json 裡的 MCP server、專案 skill 自己帶的 hooks。

版本控制層是 .git/config。git 把設定分成幾個範圍，只有 system、global 與命令列這三個算「受保護的設定」，專案自己的 .git/config 不在裡面。

兩道防線問的都不是「內容是誰寫的」

git 有一道自保。官方文件寫，預設情況下 git 拒絕解析一個屬於別人的儲存庫的設定檔，更不會跑它的 hook。注意它問的是這個資料夾屬於誰——你自己 clone 下來、自己解壓縮出來的東西，擁有者就是你，這道檢查根本不會啟動。

代理那一道問的是「你信不信這個資料夾」，但它不是全有全無。Claude Code 官方有一張表，逐列寫出你只信任了上層資料夾時哪些東西照樣生效：settings 檔裡的 hooks、env、helper 指令與專案 skill 的 hooks，那一格寫的是 Used；permissions.allow 與 additionalDirectories 那一列寫的是 Not used，要你接受對話框才算。

擋下來的是「給你權限」的那一半，跑起來的是「跑指令」的那一半。 這是文件上的事實，不是推論。

同一頁還寫了一件對做自動化的人更要緊的事：信任對話框只在互動 session 出現，claude -p 與 SDK 從來不顯示它。你排程裡那個代理，沒有這道門。

四個你自己查得到的問題

1. 這個代理有沒有寫明它啟動時讀哪些檔案？ Claude Code 與 Codex 都有這份文件。
2. 信任提示預設開嗎？ Cursor 官方文件自己寫它預設是關的，並建議不信任的 repo 直接用純文字編輯器開。
3. 哪些東西在你按下信任之前就生效？ 去讀那張表，不要問人。
4. 非互動模式有沒有這道門？ -p、CI、排程都算。

第四題最容易漏。Codex 把「不信任」做成少讀東西：在使用者層的設定檔把專案標成 trust_level = "untrusted"，專案層的設定、hooks 與 rules 就整組停用。

這不是假設題

9 月 2 日 Manifold Security 公布的 GitSpawn 走版本控制層，我寫過。同一家 7 月揭露的另一件走設定層：Cursor CLI 讀專案自己帶的一個 JSON 就跑起指令，時點在信任提示之前、沙箱寫死關閉，官方 7 月 23 日的版本改成信任之後才跑。再往前，repo 裡的 skill 與符號連結那次踩的是指示層。

三層都出過事，補法卻各自為政：git 的檢查看的是擁有者，代理的提示看的是資料夾，廠商的修補看的是版本號。我還沒看到哪一家寫出「打開一個專案，這三層各自跑了什麼」的完整清單。那份清單出現以前，只能一層一層自己問。

查核備註：Cursor 那件的機制與時間線來自 Manifold 的揭露，我沒向 Cursor 求證；三家的檔案載入順序都以各自官方文件為準，我沒有實測任何一款代理的行為。