讓別的程式叫 agent 做事，先回答兩件事：誰能對它下指令，以及它要動手時，那一問有沒有人收得到。Cursor IDE 的核准卡片只出現在那台電腦的螢幕上；換成程式叫它，同一支 hook 的「要問人」沒人可問，指令照跑。omp 會把那一問送回給叫它的程式，可是它把能送指令進來的都當成你，所以身分要驗在轉送指令的那支程式裡。

Day17 處理的是 agent 自己說「做完了」。今天換一個能力：讓別的程式能叫它做事。一旦旁邊沒有人看著，問題就從「它真的做了嗎」變成「是誰叫它做的」。

今天只回答兩個問題：誰能叫它做事，以及它要動手時，那一問送不送得到你手上。訊息裡夾帶惡意內容留到 Day25 和 Day27，排程留到 Day24，中途喊停留到 Day23，把 agent 包成服務給別人用留到 Day28。金鑰怎麼搬出 agent 碰得到的地方，Day16 講過，今天只講它不能進那條線。

一、情境：週五下午，你要離開電腦三個多小時

週五下午四點，你要搭高鐵回南部，三個多小時沒辦法坐在電腦前。今晚有一批資料要整理，同事也可能要它幫忙跑幾個指令。

你平常在 Cursor IDE 裡用 agent。專案裡一直掛著一支 hook：每一行終端機指令執行前，hook 可以回三種答案：放行、不准、要問人（allow、deny、ask）。你這支一律回「要問人」，附上一句：

The owner must approve this shell command.

你的執行模式是 Run Everything，平常指令都不問就跑；只有這支 hook 回「要問人」時，IDE 才會跳出一張卡片：上面是那行指令，下面寫著「Hook requested approval:」加上這句話，按鈕是 Skip 和 Run。你試過放著不按，它等了四分鐘也沒自己跑；按 Skip，它就不跑。這道關，你一直很放心。

你想讓團隊頻道裡的一句話就能叫它做事，你自己在車上也從頻道叫它。可是 Cursor IDE 沒有讓別的程式把話送進對話框的門。你寫了一支小程式當橋：頻道裡有人標記它，它就把那句話交給你辦公室那台機器上的 Cursor agent，用的是你的 Cursor API key。橋用的是 Cursor 的 SDK，不開 IDE，但跑在同一台機器、同一個專案，讀的是同一份 hook 設定。

你以為它會像在 IDE 裡一樣：有人叫它跑指令，它先問你；你沒回，它就等著。

試了一下很順。你在頻道打一句，請它用終端機跑一行寫檔的指令。十幾秒後它回：指令跑完了，檔案寫好了。它沒有先問你。你沒多想，反正是你自己叫的。

五點多，你在車上。上週剛加進頻道的外包同事標記了它，也請它跑一行終端機指令。你的手機沒有響，沒有任何一則要你點頭的訊息。十四秒後，它在頻道裡回：指令跑完了。他沒有你那台機器的帳號，也沒有你的金鑰。透過這座橋，兩樣他都用到了。

二、Cursor IDE 痛點：那一問只留在 IDE 裡

你連回辦公室那台機器，翻 hook 的紀錄。hook 確實被叫到了，回的是「要問人」。2.1 秒後，紀錄上那行指令已經跑完。它沒有等任何人，那句要給主人看的話也沒有送到任何人手上。

那行指令只是寫一個檔。可是 hook 不看指令寫什麼，每一行回的都是同一句「要問人」，而這一句在這裡等於放行。

你接著找：是誰叫的？hook 收到的欄位裡有指令、session 的編號、對話紀錄的路徑，沒有一個說得出是誰。文件說 hook 會收到登入者的 email，「如果有的話」。從橋叫的這幾次都沒有；在 IDE 裡試的時候，每次都有。就算有，也是你的：頻道裡每個人，都是用你的金鑰在說話。

你把「要問人」改成「不准」，再試一次。這次指令沒跑，它在頻道裡回：「指令沒有跑，被設定好的 hook 擋下來了，檔案沒有建立。hook 說這行指令要主人先核准。hook 的設定可以在 Cursor Settings > Hooks 改。」

這下安全了，可是你自己從車上叫它的指令，也全被擋下。它告訴頻道裡的人「要主人核准」，卻沒有地方可以核准，還順便教他們去哪裡改 hook 的設定。

同一支 hook，換個地方叫它

另外，在 IDE 裡按了 Skip，記錄「指令跑完」的那支 hook 一樣會被叫，只是輸出是空的。拿 hook 紀錄當證據時，不能把這一筆當成指令跑了。

文件怎麼寫的（2026-10-02 讀取）：

• Hooks： hook 附上的那句話，文件寫的是「顯示在 client 裡的訊息」。沒有 client 的時候「要問人」會變成什麼，沒寫。執行模式那一頁也沒提 hook；hook 的「要問人」在 Run Everything 下還叫得出卡片，是實測看到的。
• SDK： 文件寫明，local runtime 預設不經核准就執行工具呼叫，「headless 模式沒有 human-in-the-loop 的提示」；要把關，就用 beforeShellExecution 這類 hook，或開沙箱。它要你用 hook 把關，卻沒寫 hook 回「要問人」時會怎樣。實測：放行。
• SDK 的選項： 跟核准有關的只有兩個：交給分類器判斷的 Auto-review，和沙箱。文件寫明，分類器擋下的就直接拒絕，不會轉給人。SDK 的事件清單裡有一種 request，說明是「等使用者輸入或核准」，但文件沒寫怎麼回，SDK 的型別裡也找不到回答它的方法；這幾場也一次都沒出現。沒有一個選項，能把「要不要允許」交回給你的橋。

Cursor 還有哪些路

那 Cursor 有沒有別的路，讓你不在電腦前也叫得動它、又問得到你？文件裡找得到這幾條，都不是 IDE 本身。下表只讀了文件，沒有實測：

最接近故事的是 Remote Control：在 Agents Window 打 /remote-control，之後就能用手機接著指揮，工具還是在你的電腦上跑。可是它只給你本人用，只支援 iPhone 和 iPad；手機上會不會跳出核准卡片，文件沒寫，推播只寫了「agent 完成一輪時」。頻道裡的同事和別的程式，都用不了這條路。

從 Slack 叫的雲端 agent，會把 Slack 使用者對到 Cursor 帳號（文件只在權限表上寫了一句），碰得到的 repo 也不會超過那個人本來碰得到的。但它跑在 Cursor 的機器上，而且從不問你。工具呼叫也可以改到你自己的機器上跑（My Machines），這時要不要問你，文件沒寫。雲端 agent 的設定頁也寫了這條路的風險：權限低的團隊成員，可以藉著指揮一個握有高權限使用者密鑰的 agent，擴大自己的權限。

唯一把核准交給你的程式的，是 CLI 的 ACP 模式：工具要核准時，送一道 session/request_permission 給啟動它的程式，回 allow-once、allow-always 或 reject-once；不回，工具就可能卡著。這跟下一節 omp 的做法是同一種。只是那是 CLI，不是 IDE；hook 在 ACP 下跑不跑，文件沒寫；這次也沒測。

痛點是哪三件

1. 那一問只出現在那台電腦的螢幕上。 在 IDE 裡它真的會等你，但只等坐在那台電腦前的人。文件裡找不到任何一條路，能把這張卡片送到手機、網頁或 Slack 上。
2. 離開 IDE，同一支 hook 默默變成放行。 要讓頻道或別的程式叫它，就得離開 IDE。故事裡的橋走 SDK，你在 IDE 裡設好的那一道關沒人可問，沒有警告，agent 還回報成功。
3. 沒有一層說得出是誰。 IDE 的 hook 收到的是登入的你，SDK 什麼都沒有。頻道裡誰叫的，只有你的橋知道。

Cursor 自己補，補得上，但那一問要你自己送出去。週一回到辦公室，你改寫那支 hook：它不自己回答，先把問題傳到你的手機，等你回覆再轉回去。你試了四次：

• 你回放行：指令跑了。
• 你回不准：指令沒跑。
• 你沒回：hook 等到時限，以錯誤結束。Cursor 把 hook 出錯當成放行，指令照樣跑了。
• 同上，但 hook 加上 failClosed：hook 出錯就擋，指令沒跑。

傳到手機這段要你自己做，hook 也一定要加 failClosed，Day14 看過同一個開關。題目裡一樣沒有「是誰」：hook 只知道那行指令，不知道是頻道裡哪個人要的。

三、omp 如何平替：讓叫它的那支程式，也是回答核准的地方

在 Cursor IDE 裡，核准卡片是 IDE 畫出來的，所以只會出現在 IDE 裡。omp 的 RPC 模式把這個角色交給叫它的那支程式。

把同一座橋接到 omp，用的是它的 RPC 模式。omp 只走 stdin 和 stdout：從 stdin 一行一行讀指令，從 stdout 把結果和事件送回去。橋啟動 omp，握著它的 stdin，也讀它的 stdout。你在 IDE 裡看到的東西，在這裡都變成一行 JSON：

差別在第二列：那道選擇題送到叫它的程式手上。橋可以把它轉到你的手機，你按哪個，橋就把那個字送回去。

我用 --approval-mode write 啟動 omp：寫檔不問，執行類的工具，像 bash，用之前要先問。模型想跑那行寫檔的指令時，回答的是測試程式，代替手機上的你：

• 回 Deny：指令沒跑，檔案沒出現。模型收到「Tool call denied by user: bash」，回報它沒有跑，因為被拒絕了。
• 回 Approve：指令跑了，檔案出現。
• 一直不回：omp 就一直等。那一場等了 1 分 44 秒，測試程式放棄、斷了線，這次呼叫以「橋在回答前就斷線」的錯誤結束，指令沒跑。

原始碼裡，這道選擇題沒有設時限：沒人回答就不跑，但 session 也一直卡著。Day16 測過另一種情況：沒有互動介面時，同樣的設定，bash 在執行前就直接被拒。RPC 的差別在於，互動介面就是橋。

這一段不用寫任何程式，是 omp 原生就有的。Cursor 要做到同一件事，文件上只有 CLI 的 ACP 模式。

可是 omp 不驗身分，它假設能寫進 stdin 的就是你。下一節數一數，能寫進 stdin 的，還能做什麼。

四、解決前的 omp 能力：那一問送得出去，門卻不只一扇

能寫進 stdin 的，不只一句話。我用預設設定、什麼憑證都沒帶，一行一行送進去：

文件裡還有讀整段對話、匯出到指定路徑、換到另一個 session 檔這類指令，一樣不驗身分。這些沒測。

再看核准模式。預設是 yolo，什麼都不問：上表那句「建一個檔」，模型直接寫了，橋上沒有出現任何一道題。write 是寫檔不問、執行類要問；always-ask 連寫檔都要問。我用 always-ask 再請它建同一個檔：橋收到一道題，標題是「Allow tool: write」，附上路徑和整份內容；回 Deny，檔案就沒寫。核准模式在啟動時就定了：RPC 的指令和那 45 個斜線指令裡，都沒有能在中途改它的。這點是原始碼確認、未實測。

write 模式擋得住模型，擋不住 bash 這扇側門。RPC 的 bash，跟你在 omp 的終端機介面打 ! 開頭的指令，走的是同一條路：omp 認定是你本人要跑，所以不經模型，也不問核准。開了 write 之後，同一行寫檔的指令照樣直接跑了。

攔得到它的只有一個 hook，叫 user_bash。它可以回一個結果代替執行，omp 拿到結果就不跑那行指令。可是這個 hook 壞掉時不會擋：我放了一支一定丟錯的版本，omp 送出一則擴充出錯的通知，然後照樣把指令跑完，檔案出現了。原始碼也是這樣寫的：攔模型工具的 hook 壞掉時會擋下，這個 hook 沒有這條退路。超過 30 秒沒回也一樣照跑，這點是原始碼確認、未實測。

omp 還有一個讓人遠端驅動它的入口：/collab。文件寫明，拿到完整連結的人能下指令，也能回答主機上的選擇題，而核准就是一道選擇題；名字只是顯示用。文件自己的說法是，持有連結就是信任邊界。今天沒測。

把原生 omp 在這個情境的能力收成一張表：

方向很單純：omp 不驗身分，它假設能寫進 stdin 的就是你，所以橋就是信任邊界。橋要做三件事：驗是誰、只轉一句話、要動手的先問你。omp 這邊要做兩件事：用 write 以上啟動，讓要問人的時候真的去問；bash 這扇側門要有鎖。

五、解決後的 omp 能力比較：補上兩樣，再跟 Cursor 並排

補上的兩樣

1. 把 bash 這扇側門鎖上。 我寫了一支擋門的檢查，掛在 user_bash：只放行兩行唯讀的 git 指令，其餘一律回「不准」的結果。上一節看過，這個 hook 丟錯就放行，所以它的寫法是：讀不懂、不確定，都回「不准」，從不丟錯。最好的做法，是橋根本不送 bash；這支檢查是第二道鎖，橋有 bug 時還擋得住。程式在文末。

2. 橋：驗身分、只轉一句話、問題只送到你手上。 這一段光靠 omp 做不到，要寫在橋裡。最少要有這五條：

1. 驗身分。 用聊天平台給的使用者 ID 比對白名單，不用顯示名稱。不在名單上的，訊息不轉。用 webhook 收訊息的話，先驗平台的簽章。
2. 只轉一句話。 一律包成 prompt 送進去，訊息長得像 JSON 也只當成一句話。不送 bash、get_state 這類指令，/ 開頭的訊息不轉。
3. 問題只送到你手上。 收到選擇題，私訊給你，附上是誰要求的、哪一行指令。只收你的回答，在頻道裡回的不算。幾分鐘沒回，橋自己回 Deny，並告訴要求的人。
4. 啟動時就把門關小。 用 --approval-mode write 以上啟動，--tools 只開需要的工具，載入擋門的檢查。
5. 金鑰留在橋那邊。 聊天平台的 token 和 Cursor 的 key，都不進頻道，也不進那條線。這次 20 場的紀錄裡都找不到它。但 omp 的 shell 還讀得到 key，Day15 測過；要搬走，照 Day16 第 5 件。

我照這五條寫了一座參考用的橋，大約 150 行，接上真的 omp 和模型。聊天平台那一端是模擬的訊息，扮演三個人：你、名單上的同事，和那位不在名單上的外包。

證據： 已實測，但橋是 omp 之外的元件，這是我寫的參考版本。真的私訊、驗平台的簽章，要接你用的聊天平台。

真的跑一次：未授權的指令，停在哪一層

先不經過參考橋，由測試程式直接寫進 omp 的 stdin；要回答核准時，也由它代替你回：

沒有一層問過「是誰」。這一欄，只有橋填得了。

接上參考橋之後，omp 一樣是 write 模式、載入擋門的檢查。題目出現 1.5 秒後，由測試程式扮演的你回覆：

六場裡，橋寫進 omp 的只有兩種東西：一句話，和你的回答。那行原樣貼上的 bash 指令，直接寫進 stdin 時不問就跑了；經過橋，它只是一句要模型去做的話，得先過你這一關。

補上前和補上後

跟 Cursor 並排看

Cursor IDE 那一欄說明，同一支 hook 在 IDE 裡是有用的：執行模式是 Run Everything，所有指令本來都不經核准，hook 一回「要問人」，它還是停下來問人。只是它問得到的，只有坐在那台電腦前的人。要讓頻道或別的程式叫它，就得離開 IDE；離開之後，那一問要你自己在 hook 裡送出去。omp 把題目放在同一條線上交給橋，橋決定送給誰，也知道是誰要的。

還沒補上的

可以先從哪裡做起？

第一步，橋只聽你一個人。 不要把它加進團隊頻道，改成只收你的私訊；橋用平台給的使用者 ID 認你，不認顯示名稱。只是自己在路上用手機叫它，做到這一步，再加上第二步，通常就夠了。

第二步，要動手的先問你。 omp 用 --approval-mode write 啟動，--tools 只開需要的。橋把選擇題私訊給你，只收你的回答，幾分鐘沒回就回 Deny。

第三步，只開一扇門。 橋只送 prompt，/ 開頭的不轉，長得像 JSON 的也只當成一句話。omp 載入擋 bash 的檢查，當第二道鎖。要讓同事一起用，至少做到這一步，並改用 always-ask。引用來源裡的參考橋，做的就是這三步。

第四步，把後果關小。 橋記下誰在什麼時候要了什麼、誰按了允許。金鑰搬出 agent 碰得到的地方（Day16 第 5 件），整個 omp 放進容器（Day16 第 2 件）。要讓團隊以外的人、或別的程式自動叫它，要做到這一步。

留在 Cursor 的話：從 IDE 以外叫它時，不要指望 hook 的「要問人」。改寫成會去找你的 hook，加上 failClosed；橋的身分檢查一樣要做。

你可以怎麼確認自己讀懂了？

回到那趟高鐵，試著問自己三個問題。

第一題：Cursor IDE 的 hook 回「要問人」時，真的會停下來等你。為什麼還說這是痛點？

因為它只等坐在那台電腦前的人。要讓頻道或別的程式叫它，就得離開 IDE；故事裡的橋走 SDK，同一支 hook 的「要問人」沒人可問，2.1 秒後指令跑完，agent 還回報成功。文件要你在 SDK 裡用 hook 把關，卻沒寫「要問人」在那裡會變成什麼。要它真的問你，得自己寫一支會去找你的 hook，而且加上 failClosed；不然沒人回的時候，照樣放行。

第二題：omp 開了 write 模式，模型要跑 shell 都會先問，為什麼還說 bash 是個洞？

RPC 的 bash 走的是「你本人在終端機打 ! 指令」那條路，不經模型、不經核准，write 模式下照跑。攔得到它的只有 user_bash 這個 hook，而這個 hook 一丟錯就放行。

第三題：擋門的檢查和核准都裝好了，為什麼身分還是要驗在橋那一端？

因為兩邊都不知道是誰送的。omp 的指令沒有這個欄位；Cursor 的 hook 在 SDK 裡收不到，在 IDE 裡收得到登入者的 email，但那是金鑰主人，不是頻道裡說話的人。核准擋的是「它要做什麼」，擋不了「是誰叫的」。參考橋擋下外包、不轉同事在頻道裡打的 Approve，靠的都是只有橋知道誰是誰。

讓別的程式叫 agent 做事，那條線的另一端就是你。先決定誰能站在那一端，再讓它動手前問你，而且那一問要真的有人收得到。

明天 Day19 換一個能力：長期記憶。一段餌被記住之後，下次開機還會不會被讀回來，hook 又看不看得到它。

今天的 5 分鐘小練習

第 1 步：在 Cursor 專案的 hook 設定裡掛一支 beforeShellExecution，回 ask。先在 IDE 裡請 agent 跑一行寫檔的指令，看卡片怎麼問你，按一次 Skip。如果你也用 @cursor/sdk，在同一個專案再跑一次，看檔案會不會出現。

第 2 步：用你平常的模型參數，加上 --mode rpc --approval-mode write --tools read,bash 啟動 omp，貼一行：

{"id":"1","type":"prompt","message":"Use your shell tool to run exactly this command, then stop: echo hi > hi.txt"}

它會印出好幾行。找 type 是 extension_ui_request、method 是 select 的那一行，用它的 id 回 Deny：

{"type":"extension_ui_response","id":"<那一行的 id>","value":"Deny"}

看 hi.txt 有沒有出現。

第 3 步：同一個 session 再貼 {"id":"2","type":"bash","command":"id -un"}。它不問就跑了，這就是側門。

第 4 步：把你的橋會轉進去的每一種訊息列出來：一般的話、/ 開頭的、看起來像 JSON 的。每一種都問一次：送的人是誰，橋怎麼知道？

今天對應的威脅： T3（人藉 AI 越權）。

引用來源：

正文用事情本身來講，場次代號和檔案路徑收在這裡。

擋門的檢查是 hooks/rpc-bash-gate.ts。會丟錯的那支只用來測，是 verification/day18/throwing-bash-gate.ts。參考橋是 verification/day18/bridge.ts，實測用 run-bridge.ts 驅動。會去問你的 Cursor hook 是 verification/day18/cursor-hooks/ask-external-hook.mjs，實測用 run-cursor-ask.mjs 驅動。

實驗條件：SDK 和 omp 的每種組合跑一次。2026-10-02 另外把 C18-ask-only、R18-rpc-deny、B18-outsider 各重跑一次，結果相同；C18-ask-only 那次，從 hook 回「要問人」到指令跑完是 6.5 秒，SDK 記下那行指令本身就跑了 7.1 秒（原本 2.4 秒），兩次都沒有停下來等人。5 分鐘小練習的第 2、3 步也照文中的字原樣貼進 omp 跑過：印出的 45 行裡只有一道選擇題，回 Deny 後 hi.txt 沒出現；id -un 不問就跑了。Cursor IDE 那 6 次：Cursor 3.21.9，遠端 SSH 的 workspace，送指令的是 IDE 裡的 agent（Opus 5.5），按卡片的是我；hook 用 matcher 只接含測試字串的指令，測完就拿掉。6 次裡有 5 次按了 Run，1 次放了四分鐘後按 Skip；按了什麼是我自己回報的，時間來自 hook 紀錄。執行模式是 Run Everything：卡片左下角和 Cursor Settings 的 Run Mode 都是，設定頁寫明這個模式下所有指令不經核准、分類或沙箱就直接跑，所以那幾張卡片都是 hook 叫出來的。omp 的模型是 cursor-sdk/claude-opus-5-5，--thinking off，關掉 skills、rules、LSP 和自動標題，每場只開需要的工具（預設那場是 read、write、edit、bash、todo，其餘是 read、bash）。Cursor SDK 的模型是 claude-opus-5-5，context=1m、effort=low、fast=false，工具只開 shell 和 read，只讀專案層的設定；hook 腳本和紀錄放在工作目錄外的暫存資料夾。C18-ask 和 C18-deny 另掛了一支回 allow 的 preToolUse，那是測試程式較早的版本；文件寫明多支 hook 合併時 deny 勝過 ask、ask 勝過 allow，C18-ask-only 拿掉它重跑，結果一樣。兩支檢查的那兩場只送 bash 指令，沒有叫模型。R18-alwaysask-write 只開 read、write、edit、todo，沒有 bash。C18-owner-* 由測試程式扮演手機上的你，在題目出現 1.5 秒後回覆，hook 實際等了 1.6 到 1.7 秒；hook 的逾時，放行和不准那兩場設 60 秒，沒回的兩場設 30 秒，hook 自己等 4 秒就放棄。B18-* 的橋，名單上是你和同事，題目時限 20 秒；聊天那一端是寫好的訊息，代替私訊的那一段在題目出現 1.5 秒後回覆，B18-outsider 和 B18-slash 沒有叫到模型。「2.1 秒」是 beforeShellExecution 到 afterShellExecution 兩筆 hook 紀錄的時間差；「1 分 44 秒」是 session 裡那次工具呼叫到斷線錯誤的時間差；「四分鐘」是 IDE 第 6 次從 hook 回「要問人」到按下 Skip 的 246 秒。「所有紀錄裡沒有金鑰」是把 verification/day18/ 底下 135 個檔逐一比對的結果；IDE 的紀錄裡也沒有任何 email。Cursor 的文件在 2026-10-02 讀取，頁面上沒有標更新日期。omp 的行號，docs/ 相對原始碼根目錄，其餘相對 packages/coding-agent/src/。

• 每場的原始紀錄在 verification/day18/runs/（summary.json、RPC 或 SDK 的事件串流、hook 紀錄、session）；每一場的說明在 runs/README.md
• 實驗用的檔案：verification/day18/run-rpc.ts、run-cursor.mjs、run-cursor-ask.mjs、run-bridge.ts、bridge.ts、cursor-hooks/ask-hook.mjs、cursor-hooks/ask-external-hook.mjs、make-fixture.sh
• Cursor IDE 的實測：verification/day18/ide/（ide-ask-hook.mjs、hook-log.jsonl、卡片截圖 probe5-card.png、設定頁截圖 settings-run-mode.png、README.md）
• 10-02 的重跑和小練習：verification/day18/recheck/（說明在 README.md；小練習的腳本是 exercise.ts，實際貼進 stdin 的字在 exercise/sent.txt）
• hook 層測試（不呼叫模型），會去問你的 Cursor hook 4/4：verification/day18/ask-external-hook-layer.sh、ask-external-hook-layer-output.txt
• omp 18.2.8 文件
  • docs/rpc.md:3-6（只走 stdin、stdout）、117、130、169、182-183、192（指令）、232（prompt 也收斜線指令）、592-636（Extension UI；給了時限才有預設值）、796
  • docs/approval-mode.md:16-22（三種模式，預設 yolo）、162（subagent）
  • docs/extensions.md:374-377（user_bash 可以用結果代替執行）
  • docs/collab.md:3、107-108、120、122-136（完整連結能下指令、能回答選擇題；名字只是顯示用；持有連結就是信任邊界）
• omp 18.2.8 原始碼（packages/coding-agent/src/ 底下）
  • modes/rpc/rpc-mode.ts:1284-1312（get_state 回傳的內容）、1496-1499（bash 直接執行）、625-659、726-774（選擇題沒給時限就一直等）、352-361（回答只比對題目編號）、1712（斷線時的錯誤）、1072-1087（RPC 把橋當成互動介面）
  • extensibility/extensions/wrapper.ts:308-322（沒有互動介面就拒絕，Day16 的 L9）、325-342（Approve／Deny，被拒時的錯誤）
  • extensibility/extensions/runner.ts:896-898（有沒有互動介面）、1486-1527（攔模型工具的 hook 壞掉時擋下）、1529-1562（user_bash 沒有這條退路）、1277-1362（丟錯或逾時怎麼處理）、92（30 秒）
  • session/bash-runner.ts:80-92、114（user_bash 給了結果就不執行，否則照跑）
  • modes/controllers/command-controller.ts:1388（終端機介面的 ! 指令走同一個 executeBash）
  • extensibility/extensions/types.ts:859-868、1116-1120（user_bash 的事件和回傳值）
  • config/settings-schema.ts:4083-4086（tools.approvalMode 預設 yolo）
  • slash-commands/（沒有任何斜線指令碰核准模式；/force 只指定下一輪用哪個工具，builtin-control.ts:8-10）
• Cursor 官方文件（2026-10-02 讀取）
  • Hooks：beforeShellExecution 的 permission（allow、deny、ask）和 user_message（message shown in client）、共通欄位的 user_email（if available）、failClosed 和 timeout、hook 出錯預設放行、多支 hook 合併時 deny 勝過 ask 勝過 allow
  • Run Modes：Run Everything 是「Every tool call runs automatically.」；整頁沒提 hook；雲端 agent「never asks you to approve an action」
  • TypeScript SDK：「there's no human-in-the-loop prompt in headless mode」、要把關就用 hook 或沙箱、Auto-review 擋下的「denied rather than escalated」、事件 request（Awaiting user input or approval）沒寫怎麼回
  • Deeplinks：「The user must review and confirm the prompt before it gets executed. Deeplinks never trigger automatic execution.」
  • iOS 與 Remote Control：只在 Agents Window、iPhone 和 iPad、「Only you can control your agents.」、推播只寫了 agent 完成一輪；沒寫核准
  • 雲端 agent、安全、設定：跑在 VM、會跑專案的 hook、「Access is inherited, never widened.」、Team follow-ups 那段的權限擴大風險
  • Slack：users:read「Matches Slack users with Cursor accounts for permissions and secure access」
  • My Machines：迴圈在 Cursor 的雲端，工具呼叫在你的機器上
  • CLI 的 ACP：session/request_permission、allow-once／allow-always／reject-once、「If your client does not answer permission requests, tool execution can block.」；整頁沒提 hook
• @cursor/sdk 1.0.32：dist/esm/options.d.ts:157-162（autoReview）、179（sandboxOptions）、180-190（customTools 不需要核准）；dist/esm/agent.d.ts:14-19（agent 的方法只有 send、close、reload 這類，沒有回答核准的）
• 本系列 Day14、Day15、Day16

附：橋收到的那道選擇題，和側門的鎖

模型想跑 shell 時，橋從 stdout 收到的那一行（取自回 Deny 的那一場，R18-rpc-deny）：

{"type":"extension_ui_request","id":"1595565391ca7eaf","method":"select","title":"Allow tool: bash\nCommand: echo probe > model-bash.txt","options":["Approve","Deny"]}

橋送回 stdin 的回答：

{"type":"extension_ui_response","id":"1595565391ca7eaf","value":"Deny"}

擋 bash 側門的檢查，啟動時用 -e 載入：

// Day18: gates the RPC `bash` command — the direct shell door that skips the model and the approval gate.
// omp sends that command to `user_bash`, not to `tool_call`, and a handler that throws there lets the
// command run. So this handler never throws: anything it cannot positively allow is answered with a
// refusal result, and the command is never executed.
const ALLOWED = new Set(["git status --short", "git log --oneline -5"]);

function refusal(command: string) {
	const output = `blocked by rpc-bash-gate: direct shell commands over RPC are not allowed: ${command}`;
	return {
		output,
		exitCode: 126,
		cancelled: false,
		truncated: false,
		totalLines: 1,
		totalBytes: output.length,
		outputLines: 1,
		outputBytes: output.length,
	};
}

export default function (pi) {
	pi.on("user_bash", async event => {
		try {
			const command = typeof event?.command === "string" ? event.command.trim() : "";
			if (ALLOWED.has(command)) return undefined;
			return { result: refusal(command) };
		} catch {
			return { result: refusal("<unreadable>") };
		}
	});
}