會在 push 之前先詢問的 Claude Code Slack bot

為寫程式 agent 設計的 Slack bot 能將 Slack 中的訊息轉為在某人機器上執行的 Claude Code 或 Codex 請求，並將結果回覆到討論串中。muti 為每個 agent 提供擁有自己名稱的專屬 bot。工作區成員可以直接私訊它，或在頻道中提及它；該則訊息就是任務。若發問者不是該 agent 的主人，請求會先進入等待狀態，主人則可在自己的私訊中透過按鈕核准。push、破壞性刪除、花費以及存取憑證，對任何人而言都絕不會自動化。

這篇文章將說明該連接器如何運作、「Allow always」實際上儲存了什麼，以及為什麼將 Slack 視為不可信輸入才是關鍵所在。

大多數橋接器做錯了什麼

典型的橋接器會儲存 bot token、監聽提及事件，並將文字導向本地 CLI。這樣確實能跑，但存在三個問題：頻道成員資格變成了權限模型、沒人核准具風險的操作，而且每個工具呼叫都發送一則訊息導致進度訊息洗版頻道。這些都不是 Slack 本身的問題，而是恰好在 Slack 中浮現的權限問題。

頻道討論串顯示請求與其狀態；核准按鈕位於主人的私訊中；agent 在主人的機器上執行。

每個 agent 一個專屬 bot

你可以使用 muti 為該 agent 產生的 manifest 來建立 Slack app，因此 bot 會帶有 agent 的名稱及其專屬的 event URL。無需任何綁定設定，也不必學習任何指令：

• 私訊 bot，輸入的文字即是任務。該私訊會成為你與 agent 主人共享的房間。
• 在頻道中提及它，初次使用時該頻道便會在 muti 中轉為群組房間。bot 會在討論串中回覆。
• 附加檔案，檔案會作為房間附件傳送，agent 可以讀取，就像網頁上傳一樣。

Slack 使用者會依據 Slack 記錄的 Email 轉換為 muti 使用者，並由 Slack 在主人自己的工作區內完成驗證。若 Slack 隱藏了 Email，bot 會發送一組六位數的連結代碼，在網頁上兌換一次即可。無論哪種方式，權限都是綁定在帳號上，而非顯示名稱。

與網頁端相同的把關機制

每個請求都會通過與網頁端相同的把關機制。主人自己的訊息會立即執行。其他人的訊息則需等待主人核准，除非主人已針對此 agent 總是允許（Allow always）他們。狀態會即時顯示在討論串中：已接受並附上請求 ID、等待中、執行中並附帶工具呼叫摘要、完成並附帶結果。所有內容整合在同一張卡片內就地更新，而不是每個步驟發送一則新訊息。

核准按鈕，以及「always」代表什麼

當來自其他人的請求送達，或執行過程中遇到需要人為介入的工具呼叫時，主人會在私訊中收到一張卡片，上面有三個按鈕：Allow、Allow always、Deny。

Allow 僅適用於該次呼叫。Allow always 則會為 agent 儲存一條與該次呼叫範圍完全相符的嚴格規則：WebFetch 的特定網域、Bash 的特定指令前綴、依名稱指定的 skill、特定唯讀工具。日後符合條件的呼叫將由 muti 自動回應，無需額外提示。這些規則都會列在 agent 的對話方塊中，且可隨時撤銷。

危險類別的呼叫永遠無法建立規則，也永遠不會符合規則：push 至共享分支、破壞性刪除、權限提升、發布與部署，以及讀取或寫入憑證路徑。這些操作一律維持單次審核，且只有 Allow 與 Deny。這就是連接器版本的 agent 執行前務必詢問的四種操作。未回應的核准會在 24 小時後過期，與請求相同。

頻道中能看到什麼

請求內文、狀態與 ID；工具呼叫摘要；diff 路徑與行數；指令輸出的末尾內容；產生的檔案與連結。絕不會顯示：環境變數、金鑰檔案、工作樹或來自其他房間的任何內容。Slack token 以加密形式儲存在 muti 中；主人的機器上不會留存任何 Slack 相關資料，僅維持只出不入的 daemon 連線。詳見 daemon 會上傳什麼。

設定

1. 在主控台中，開啟欲公開的 agent 的 Slack 設定，並從產生的 manifest 建立 Slack app。若有需要，可上傳 agent 的頭像作為應用程式圖示；精靈會為你產生預覽。
2. 貼上來自應用程式設定的兩段字串。muti 會呼叫一次 Slack，透過 Email 找到你，並將你連結為主人，讓核准按鈕能立即生效。
3. 將應用程式安裝至你的工作區。直接私訊 bot，或將它邀請至頻道並提及它。
4. 在私訊中核准來自隊友的第一個請求。僅對狹窄、例行性的呼叫使用 Allow always；危險操作請務必保留詢問。

常見問題

這個 bot 需要我的 Slack 管理員權限嗎？ 將應用程式安裝至工作區通常需要一次管理員核准。該應用程式屬於你，是根據 muti 的 manifest 建立的，因此沒有任何第三方應用程式會持有你的工作區 token。

頻道成員可以自行核准嗎？ 不行。核准權限屬於 agent 的主人，且只會發送到主人的私訊中。成員可以取消或補充背景資訊。

那麼 Feishu、Lark 和釘釘呢？ Feishu/Lark 即將推出，並採用相同的房間與核准模型；請參閱 Feishu 設計。之後則是釘釘。

這和 Claude Code Dispatch 相同嗎？ Dispatch 是將你的 Telegram 訊息轉發至你自己的工作階段。此連接器則是供其他人使用，並具備核准機制；請參閱 Dispatch 與房間的差異。

由房間來處理權限；Slack 只是通往其中的另一扇門。為你的 agent 建立房間。