如何在伺服器上安全執行 Claude Code

在伺服器上安全執行 Claude Code 的含義

若要在伺服器上安全執行 Claude Code，請保持權限提示開啟，使用專用的非特權使用者執行，並為無人值守的執行環境建立實際的隔離邊界，而不是仰賴信任：可使用內建 sandbox、容器，或不存放重要資料的一次性 VPS。--dangerously-skip-permissions flag 會移除模型與 shell 之間的核准步驟。對無人值守的工作而言，這項取捨可能合理，但只能在能限制單一錯誤指令影響範圍的隔離邊界內使用。本指南說明此 flag 實際變更的內容，以及如何逐步建立隔離程度更高的邊界。

Claude Code 在你的主機上可以執行的操作

Claude Code 是在終端機中執行的程式碼代理程式。它會以啟動它的使用者身分讀取檔案、寫入檔案及執行 shell 命令。這就是此工具的全部價值：它可以複製 repository、編輯程式碼、執行測試、讀取失敗訊息，並持續修正程式碼，而不必由你逐一輸入每個命令。如果你尚未在伺服器上設定它，使用 tmux 在 VPS 上執行 Claude Code 會說明安裝與工作階段管理。本頁說明它在主機上執行後，你授予它的權限。

風險可由同一句話重新檢視。以你的使用者身分執行 shell 命令的程序，可以執行你的使用者能執行的任何操作。它可以讀取 ~/.ssh/id_ed25519、~/.aws/credentials，以及你的使用者能開啟的所有 .env 檔案。它可以執行 curl，並將資料傳送到伺服器可連線的任何主機。它可以執行 git push --force。代理程式本身沒有動機。危險在於工作執行錯誤，或它在工作期間讀到由他人寫入的指示，例如它擷取的網頁，或要求它修正的 issue 中的註解。後一種情況稱為 prompt injection，因此「模型通常能合理處理」不能算是安全計畫。指示也可能來自更接近主機的來源，因為同一台主機上的兩個 Claude Code 工作階段可以互相傳送文字，而來自另一個工作階段的訊息，對接收訊息的代理程式而言也只是它會讀取的更多文字。你必須針對錯誤執行進行規畫，而不是只依賴平均情況。

用白話說明權限系統

在 Manual mode 中，Claude Code 會在執行動作前詢問。讀取專案內的檔案會靜默進行，但編輯檔案或執行 shell 命令時，會先顯示確切的編輯內容或命令，並等待你確認。你可以核准單次動作，也可以要求它不再詢問。對檔案編輯而言，後者會持續到工作階段結束；對 shell 命令而言，則會永久儲存到該 repository 與命令，因此你在伺服器上的快速確認，會持續超過目前的工作階段。若有希望刻意保留的規則，可在設定檔中管理永久性的允許、詢問與拒絕清單。例如：允許 git status、對 git push 詢問、拒絕讀取 .env。拒絕規則一律優先。這項預設行為也已改變。Auto mode 會由分類器審查動作，不再由你逐一審查；自 2026 年 8 月 14 日起，它成為 Pro、Max 與 Team 方案新工作階段的預設模式；自 Claude Code v2.1.283 起，除非你已固定預設模式，否則它也是所有方案在互動式終端機與 VS Code 工作階段中的內建起始模式。因此，在決定伺服器應採用哪種模式前，值得先了解各種權限模式實際允許的操作。

這項設計假設有人正在查看終端機；在筆記型電腦上通常如此。但在伺服器上，情況往往是沒有人監看。你在 tmux 中啟動長時間工作後就去睡覺，而代理程式若在凌晨 2 點停止並提出問題，直到早上都不會繼續執行。這段暫停不只耗時，也會增加成本，因為閒置的 Claude Code 工作階段會失去暖身提示快取，下一輪必須付費重新建立快取。這就是人們在伺服器上使用 skip flag 的實際原因，以及它要解決的問題。接下來的內容會說明如何解決這個問題，同時不放棄所有防護機制。

--dangerously-skip-permissions 會變更什麼

claude --dangerously-skip-permissions 會關閉核准步驟。編輯會直接執行，不再顯示提示。Shell 命令也會直接執行，不再顯示提示。通常用來保護敏感位置的受保護路徑檢查也會略過。您明確設定的 deny 規則仍然有效，少數極端操作仍會停止並要求確認，但整體原則很簡單：模型決定執行的任何操作，都會直接執行。

在伺服器上，這個旗標有兩點需要注意。第一，在 Linux 和 macOS 上，Claude Code 以 root 或透過 sudo 執行時會封鎖這個旗標，因為沒有提示的 root 可以變更機器上的任何檔案或服務。代理程式本來就應使用自己的非特權帳號，而這個旗標會強制執行這項要求。第二，這個旗標不會以任何方式變更模型的行為。它只會將人員移出核准流程，其他部分完全不變，因此原本可能被提示攔下的每個錯誤，現在都會直接執行。

因此，實際的評估方式如下。略過權限後，安全性問題會從「代理程式是否會執行不當操作」變成「一次錯誤操作可能造成多大損害」。您不再試圖控制每個決策，而是開始控制影響範圍。答案是進行隔離，而隔離可分成多個層級。

內建的 Claude Code sandbox

在介紹各級設定之前，請先了解 Claude Code 現在已為所執行的命令提供 OS 層級的 sandbox，這已消除使用 skip flag 的大多數理由。在 Linux 上，它使用 bubblewrap 進行檔案系統隔離，並透過 socat 將網路流量導向 proxy。sandbox 內的命令只能寫入專案目錄與工作階段暫存目錄，且只能透過 proxy 存取網路；proxy 會依 allow list 檢查每個網域。命令首次要求存取新網域時，Claude Code 會詢問你；在 auto mode 中，則由 classifier 審查新的主機。

在工作階段中使用 /sandbox 命令啟用。Ubuntu 與 Debian 必須先安裝所需的 2 個套件：

sudo apt install bubblewrap socat

在 Ubuntu 24.04 及後續版本中，預設的 AppArmor policy 會阻止 bubblewrap 建立所需的 user namespace。sandbox panel 會在缺少元件時提示你，Claude Code sandboxing 文件也提供可修正此問題的簡短 AppArmor profile。

sandbox 提供 auto-allow mode：sandboxed 命令不會顯示提示，因為現在由強制執行的邊界取代原本由提示執行的管控。無法在 sandbox 內執行的命令會回到一般的 permission flow，因此真正不尋常的操作仍會要求確認。對大多數伺服器工作流程而言，這是 skip flag 的正確替代方案，因為你取得的是更少的提示與 OS 強制執行的邊界，而不是完全沒有邊界。

請務實看待它的限制。依預設，sandboxed 命令仍可讀取大部分檔案系統，包括 credential 檔案，除非你拒絕對這些路徑的存取；sandbox.credentials 設定正是為此用途而存在。網路 proxy 會檢查網域名稱，但不會檢查流量內容，因此像 github.com 這樣寬鬆的 allow 仍可能讓資料外傳。Docker 無法在其中運作。sandbox 能大幅提高最低安全水準，但不是完整的隔離邊界，因此下方各級設定仍然重要。

隔離層級

共有3個層級，隔離程度依序增加。請根據伺服器上還有哪​​些內容，選擇符合需求的最低層級。

層級1：專用的非特權使用者。 為 agent 建立專用帳號、專用家目錄與專用專案目錄，且不授予 sudo 權限：

sudo adduser --disabled-password --gecos "" agent

帳號邊界可讓 agent 無法存取你的檔案，包括 SSH keys 以及機器上的其他專案。這也讓 skip flag 能夠使用，因為該 flag 拒絕以 root 身分執行。這與讓每項服務都以非特權使用者執行的原則相同，只是套用在 agent 上。層級1無法限制網路，以及伺服器上所有使用者都可讀取的內容。

層級2：容器。 Anthropic 提供參考用的 devcontainer，讓 Claude Code 以非 root 使用者執行，並透過防火牆規則限制 agent 可連線的主機。自行建立的容器也能達到相同效果。檔案系統會縮小為你掛載的 volumes，對外連線範圍則縮小為容器規則允許的內容。當伺服器還承載其他重要服務時，這是適合的中間層級。其限制在於容器共用主機 kernel，而一個不慎設定的掛載就可能破壞這道邊界；將 /var/run/docker.sock 提供給容器後，它就能存取整台主機。

層級3：專用 VPS。 最強的層級也是最直接的做法：提供一台完整機器給 agent，且其中不包含任何重要內容。小型 VPS 每月只需幾美元。依照新 VPS 上線後前10分鐘的執行手冊完成設定，建立乾淨狀態的 snapshot，然後讓 agent 執行工作。該伺服器不放置其他內容。不放個人 SSH key，只放限定於單一 repository 的 deploy key。不放 cloud credentials，也不放 production data。執行失敗時，或只是想重新開始時，可以在幾分鐘內還原 snapshot，或銷毀並重建伺服器。爆炸半徑就是 VPS 租金。在這種設定中，--dangerously-skip-permissions 不再令人擔心，因為最壞的實際結果只是重建伺服器並撤銷一個 token。

這些層級可以疊加。讓 agent 在 disposable VPS 上以非特權使用者執行並套用 sandbox，幾乎不會增加成本，也能讓失敗情境變得單調。單調正是目標。

保護憑證

這項規則是其他所有措施的基礎：agent 使用者不得讀取屬於其他用途的 secret。

只將 API key 提供給 agent，不要提供給其他用途。將它放在由 agent 使用者擁有且權限為 600 的檔案中，並在 shell 啟動時載入：

install -m 600 /dev/null /home/agent/claude.env
echo 'export ANTHROPIC_API_KEY=your-key-here' >> /home/agent/claude.env
echo 'source ~/claude.env' >> /home/agent/.bashrc

接著限制另一個方向。在較舊的 Debian 和 Ubuntu 安裝環境中，以及安裝期間建立的帳號，其 home directory 可能會被主機上的所有使用者讀取，因此請收緊自己 home directory 的權限：chmod 750 /home/youruser。使用 ls -ld /home/* 檢查，並修正 agent 帳號能夠列出的任何內容。

限制每個 token 的權限範圍。將細粒度 GitHub token 限制在單一 repository，或使用每個 repository 專用的 deploy key。如此一來，即使憑證外洩，也只會影響一個專案，而不是整個帳號。若使用 sandbox，請加入其憑證設定，讓即使是讀取操作也會拒絕 ~/.ssh 和 ~/.aws。此外，請完全不要將 production credentials 放在該主機上，因為 agent 無法外洩從未存在的 secret。若這些 secret 存放在自架的 password manager 中，請將它放在與 agent 不同的主機上，並個別進行檢查，因為 Vaultwarden 的弱點在於 admin token 和備份檔案，而不是加密的 vault 本身。

Git 是安全網

代理程式提交的每項變更都能供檢閱，也能還原。只要讓代理程式在分支上工作，並持續提交，git 就能免費提供這兩項保障：

git switch -c agent/refactor-auth

代理程式從未提交的工作沒有這種保護：git reset --hard 會捨棄受追蹤檔案中的未提交變更，而 git 完全不會涵蓋儲存庫以外的內容。執行完成後，先使用 git diff main...agent/refactor-auth 檢視它提交的內容，再在該分支上執行 git status 和 git diff HEAD，確認它留下哪些未提交變更。保留有價值的內容；如果這次執行沒有產生可用結果，就刪除該分支。只修改 3 個檔案的執行結果，遠比重寫半個模組容易在早餐時讀完；實務上可透過要求代理程式採用能正常運作的最小變更的技能達成這點。在 forge 端保護 main 分支，讓代理程式的 token 無法推送至該分支，也無法在任何位置強制推送。提交歷程也會成為你休息期間發生之事的稽核日誌，其價值遠高於終端機捲動記錄的任何數量。

網路屬於影響範圍

代理程式可以執行 curl。這句話說明了完整的對外連線問題：代理程式能讀取的任何內容，也能傳送到其他位置，而且遭到提示注入的代理程式可能真的會這麼做。一般未具特殊權限的使用者完全無法限制這件事，因為任何使用者都能連線到伺服器可連線的所有位置。沙箱可透過代理伺服器，依網域限制對外連線。容器可透過自己的防火牆規則限制對外連線。專用 VPS 則從一開始就限制可外洩的資料，這是三者中最穩健的做法。

不要只依賴 ufw 解決對外連線問題。ufw 預設允許所有對外流量，而撰寫同時允許 apt、npm、git 和 Claude API 的對外規則相當繁瑣，也可能在未明顯提示的情況下失效。應在沙箱、容器或機器層級設定界線，讓網域允許清單或獨立機器乾淨地完成相同工作。

如果你是直接使用 API 建立自己的代理程式，而不是執行 Claude Code，同樣的思考方式仍然適用。在 VPS 上使用 Claude 建立 AI 代理程式涵蓋這條路徑，而該代理程式同樣應使用專用使用者、範圍受限的 token，以及可丟棄的機器。

先強化主機

無論選擇哪一級，agent 部署前仍須先完成主機的基本防護：僅允許 SSH key 登入、停用 root 登入、設定預設拒絕的防火牆，以及啟用自動安全更新。在此產生檢查清單，並依序完成一次：

FAQ

在伺服器上使用 --dangerously-skip-permissions 是否安全？

單獨使用並不安全。此旗標會移除所有核准提示，因此模型產生第一個錯誤指令時，該指令就會立即執行。當爆炸半徑受到限制時，這才可能是合理的取捨：至少使用專用的非特權使用者；若要真正無人值守地執行，則使用只存放一個專案和一個具有限定範圍 token 的容器或一次性 VPS。絕不要在存放正式環境憑證或不可遺失資料的機器上使用。

Claude Code 有 sandbox 嗎？

有。Claude Code 提供內建 sandbox，可使用 /sandbox command 開啟。在 Linux 上使用 bubblewrap，在 macOS 上使用 Seatbelt；它會限制對專案目錄的寫入，並透過只允許核准網域的 proxy 傳送網路存取。其 auto-allow mode 會在不顯示提示的情況下執行 sandbox command，因此在維持作業系統強制隔離邊界的同時，也能像 skip flag 一樣減少中斷。這不是完整的隔離邊界，因此對於無人值守的執行，仍應搭配專用使用者或專用機器。

為什麼 skip flag 拒絕以 root 執行？

因為 root 在沒有權限提示的情況下，可以修改系統上的任何檔案與服務。Claude Code 在 Linux 和 macOS 上以 root 或 sudo 執行時，會封鎖 --dangerously-skip-permissions。正確作法不是繞過這項檢查，而是為 agent 建立非特權使用者，並以該使用者執行；這個帳號邊界是最先應採用、成本最低的隔離層。

Claude Code 能讀取我的 SSH keys 和 .env files 嗎？

它可以讀取執行該程式的使用者能讀取的所有內容。即使是 sandbox 的預設政策，在你拒絕之前，也允許讀取 credential paths。因此，請讓 agent 以專用使用者執行，將自己的 home directory 權限設為 mode 750 或更嚴格，在 sandbox settings 中拒絕 credential paths，並將正式環境 secrets 完全移出該機器。機器從未存放過的 secret，就不可能被讀取或外洩。

無人值守執行 Claude Code 的最安全方式是什麼？

使用僅供 agent 工作的低價專用 VPS：在 10 分鐘內完成強化設定，建立乾淨 snapshot，讓 Claude Code 以開啟 sandbox 的非特權使用者執行；使用 mode-600 檔案存放 API key，為每個 repository 使用專屬 deploy key，並將所有工作放在合併前由你審查的 branch 上。如果執行出錯，只需撤銷一個 token 並還原 snapshot，不會影響你擁有的其他資源。