安全模型

當 AI 代理接到執行時，守護程序會把 AI 程式設計工具（Codex、Claude Code 等）作為子程序啟動。Multica 的安全模型，說的就是這個程序能碰到什麼。

邊界是執行守護程序的那個使用者Copy Anchor Link

預設情況下，每次執行都擁有守護程序所屬作業系統使用者的全部權限。該使用者能讀寫的檔案，執行都能讀寫；該使用者的憑據，執行都能使用；網路訪問不受限制。

Multica 不對檔案系統沙箱作任何保證。目前只有一個狹窄的例外——在 Windows 上顯式開啟 Codex 原生沙箱——而且哪些平臺與配置組合會真正啟用沙箱屬於相容性細節，會隨工具版本變化。請把每一次執行都當作無沙箱來對待，並把邊界放在守護程序之外。

這是有意為之。AI 代理需要安裝依賴、執行構建、使用你的雲 CLI，這些工具都假設自己面對一個正常的 home 目錄。不完整的檔案系統沙箱會以極難排查的方式破壞這些工作——工具報"未登入"，或者悄悄用錯了帳號——同時又保護不了最要緊的東西：它無法阻止執行讀取憑據並透過網路發出去。所以 Multica 不把自己當作邊界，邊界要加在它外面。

推薦部署方式Copy Anchor Link

按從輕到重排列，選擇適合你基礎設施的一種：

1. 專用 Unix 使用者。 建立一個 multica 使用者，只給它 AI 代理需要的倉庫和憑據，用該使用者執行守護程序。你自己的帳號完全不受影響。
2. 容器。 在容器裡執行守護程序，只掛載 AI 代理需要的目錄和金鑰。
3. 虛擬機器。 隔離最徹底，代價是要額外準備一臺機器。

無論選哪種，都應把該環境中可觸達的憑據視為 AI 代理可能會用到的憑據：token 權限盡量收窄，優先使用專用部署金鑰而不是你的個人 SSH 私鑰，也不要把無關的生產憑據留在該使用者的 home 目錄裡。

Multica 確實隔離的部分Copy Anchor Link

以下是真實存在的隔離，但它們屬於便利性與影響面收斂，不是用來防禦主動逃逸的安全邊界：

• 每次執行獨立工作目錄。 每個執行在 ~/multica_workspaces/ 下擁有獨立 workdir，併發執行不會在同一份 checkout 上打架。
• 每次執行獨立的 AI 代理狀態。 Codex 執行擁有執行級 CODEX_HOME，儲存配置、會話與 skill，不會汙染你的 ~/.codex/。
• 執行級 API token。 交給執行的 MULTICA_TOKEN 由服務端繫結到該 AI 代理與該執行，因此執行無法透過 Multica API 以你或其他 AI 代理的身份行事。

不構成邊界的部分Copy Anchor Link

• 程式設計工具自帶的沙箱與審批設定。 Multica 以無人值守方式執行 AI 代理，審批請求會被自動應答。預設路徑下檔案系統沙箱同樣處於關閉狀態：Codex 使用 sandbox_mode = "danger-full-access"，Claude Code 使用 --permission-mode bypassPermissions。例外是 Windows——如果你顯式配置了 Codex 原生沙箱（windows.sandbox = "unelevated" 或 "elevated"），Multica 會尊重這個 opt-in，對這些執行保留 workspace-write。適用場景下值得開啟，但它只覆蓋一個平臺上的一個工具，不改變你應當如何收窄守護程序使用者的權限。
• 你的 HOME 目錄結構。 執行繼承守護程序使用者真實的 HOME 與 XDG_* 變數——正因如此，gh、aws、kubectl、gcloud、glab 等宿主 CLI 在執行內的行為與在你 shell 裡完全一致。這同時也意味著該 home 下的一切都可觸達。

如何確認執行實際以什麼模式執行Copy Anchor Link

執行以無沙箱方式啟動時，守護程序會記錄 warn 級日誌：

multica daemon logs --lines 200 | grep "codex sandbox"

要確認 Codex 的實際生效配置，可以檢視該執行 CODEX_HOME 下 config.toml 中的託管塊——# BEGIN multica-managed 與 # END multica-managed 標記之間的內容由守護程序在每次執行時寫入。