Claude Code 雲端環境 vs 本機怎麼選？設定教學＋雲端不另收費的關鍵差異

💡 核心結論速覽 (TL;DR)

本機環境：Claude Code 直接在你電腦上跑，而且內建一層 OS 級 /sandbox（macOS 用 Seatbelt、Linux／WSL2 用 bubblewrap）就能限制檔案與網路；回饋最快、最省，缺點是多個 agent 會搶同一個 port、隔離要自己管。

Claude Code on the web（雲端）：每個任務開一台 Anthropic 託管的獨立 VM（約 4 vCPU／16 GB RAM／30 GB 磁碟），能關瀏覽器、用手機監看，跑完直接開 PR；要先接 GitHub、設好網路與 setup script。

跟 Codex 最關鍵的不同：Codex 雲端據社群實測跑同一任務約多燒 5 倍 credit，而 Claude Code on the web 官方明說「雲端 VM 不另外收運算費」、只跟你方案內的用量共用額度——這點對成本影響超大。

行動建議：本機留給即時微調、雲端（--remote）丟給能背景跑的長任務；想試雲端，先接 GitHub、用預設的 Trusted 網路跑通一個任務，再慢慢加 setup script。

前陣子我寫過 Codex 的雲端環境怎麼救我那場凌晨 port 大戰。寫完我就想：那 Claude Code 呢？我兩邊每天都在用，總得把它也搞清楚。

結果一查，發現 Claude Code 雲端環境的邏輯跟 Codex 不太一樣——最反直覺的一點是：它的雲端居然不另外收錢。但它也有自己的限制，不是無腦贏。

這篇我把 Claude Code 的本機與雲端整個拆開：先講它其實有「好幾層」隔離選項（不是只有本機 vs 雲端），再給雲端（on the web）的設定教學、兩邊優缺點，最後是我把它跟 Codex 雲端並排比完之後，真正會影響你怎麼選的關鍵差異。

Claude Code 的「雲端」跟「本機」其實有好幾層

先講一個多數人沒搞清楚的事：Claude Code 不是只有「本機」跟「雲端」兩個選項，而是一條從輕到重的隔離光譜。搞懂有哪幾層，你才知道自己其實卡在哪一格。

最輕的是「直接在本機跑」——Claude Code 讀你的工作目錄、直接改檔案，跟你最貼身但也最沒防護。往上一層，本機其實內建一個 OS 級沙箱（用 /sandbox 開），再上去有把整個 process 包起來的 sandbox-runtime、Docker dev container、獨立虛擬機，最重的就是這篇主角之一的 Claude Code on the web——直接在 Anthropic 雲端開一台 VM。下面這張表是官方的隔離選項對照，我精簡成最該記的幾格。

隔離方式	隔離到什麼程度	要 Docker？
直接本機跑	幾乎沒隔離，靠權限提示把關	否
本機 /sandbox	限制每個 Bash 指令的檔案與網路	否
sandbox-runtime	把整個 Claude Code（含工具、hook、MCP）包進沙箱	否
dev container / VM	整個開發環境或整台作業系統	是 / 否
Claude Code on the web	Anthropic 託管的整台 VM	否（要訂閱＋GitHub）

我的觀察是：大部分人只用最左邊（直接跑）跟最右邊（on the web），中間那層本機 /sandbox 幾乎沒人開——但它其實是「我想少點權限提示、又不想開 Docker」的甜蜜點。如果你還在猶豫值不值得學這套工具，我之前寫過非工程師到底該不該學 Claude Code，可以先建立基本概念；想先搞懂「AI agent 到底是什麼」，這篇入門指南也能補上。下一步：先確認你現在在這條光譜的哪一格——只是直接跑，那你連本機 /sandbox 都還沒用到。

Claude Code on the web 怎麼設定？雲端三步驟

直接講結論：雲端（on the web）的設定核心就三件事——接 GitHub、設好環境（網路＋setup script）、用 --remote 丟任務。它跑在 claude.ai/code，每個任務開一台全新的 Anthropic 託管 VM、把你的 repo clone 進去。流程拆開是這樣：

❶ 接 GitHub。有兩條路：在網頁 onboarding 授權 Claude 的 GitHub App，或在終端機跑 /web-setup 把你本機的 gh token 同步上去。雲端 session 只吃 GitHub——GitLab、Bitbucket 的 repo 只能用 bundle 上傳，而且改完推不回去。所以沒上 GitHub 的專案，雲端這條路會卡。

❷ 設環境。一個「環境」管三件事：網路存取、環境變數（.env 格式）、setup script。setup script 是一段 Bash，在 session 啟動前以 root 在 Ubuntu 24.04 上跑，用來裝預載沒有的東西。建議控制在 5 分鐘內，因為跑完官方會快照檔案系統當快取，之後的 session 直接帶著你的依賴開機（快取大約 7 天、或你改了 setup／網路設定才重建）。

❸ 分清楚 setup script 跟 SessionStart hook。這是最容易混的地方：setup script 綁在「雲端環境」、只在雲端跑；SessionStart hook 綁在「你的 repo（.claude/settings.json）」、本機跟雲端都會跑。要「只在雲端裝某些東西」，就在 hook 裡用 CLAUDE_CODE_REMOTE=true 這個環境變數判斷。搞混的話，你會在本機重複跑一堆雲端才需要的安裝。

❹ 丟任務、平行跑、拉回本機。設好就能在終端機用 claude --remote "修好 src/auth 的登入 bug" 開一個雲端 session；它從 GitHub clone（所以本機有 commit 記得先 push）。你可以連發好幾個 --remote 平行跑，關掉電腦也沒事，用手機 app 監看；想接手就用 --teleport 把雲端 session 連同 branch 拉回終端機繼續。這套「本機規劃、雲端執行、隨時拉回」的手感，是 Claude Code 雲端最舒服的地方。想看 Claude 這類 agent 還能做到什麼，可以參考 Claude 的 agent、artifact 與電腦操作能力。

🚧 最容易踩的雷：Claude Code on the web 目前沒有專用的 secrets 儲存庫。你放的環境變數會被「能編輯這個環境的人」看到。所以別把正式環境的 API key、資料庫密碼當機密直接塞進去——需要的話用權限受限的測試憑證，並記得這層可見性。

下一步：先用預設的 Trusted 網路、不寫 setup script，跑通一個最簡單的 --remote 任務，確認 GitHub 接通了，再加環境設定。

在雲端（on the web）執行的優點與缺點

先給判斷：雲端贏在「能丟著跑、平行、不另外收費」，輸在「要 GitHub、有資源天花板、機密不好放」。

最有感的優點是成本。官方在限制說明裡寫得很白：Claude Code on the web 的雲端 VM 不另外收運算費，它跟你帳號裡所有 Claude／Claude Code 用量「共用 rate limit」——平行跑越多任務就按比例吃越多額度，但沒有獨立的雲端機器費。這跟 Codex 很不一樣（後面那段我會並排比）。如果你正在算每月該不該升級訂閱，哪些 AI 訂閱真的值得續那篇可以搭著看。

第二個優點是非同步＋平行：session 會持久存在，你可以一次發三個 --remote、關電腦、用手機追進度，跑完還能讓它自動盯 PR 的 CI 失敗去修。對「能放著跑」的工作，這比守在本機有效率太多。

但缺點也很實在。用一個「適合 / 不適合」對照幫你快速定位：

✅ Claude Code 雲端適合你，如果你：程式碼放在 GitHub、想平行推進多個任務、常在沒有開發環境的裝置上想動工、已經吃 Max 額度且不想再多付雲端機器錢。

❌ 雲端先別急著上，如果你：需要秒級即時看畫面、要跑吃記憶體的大型 build（雲端約 4 vCPU／16 GB／30 GB，超過會被終止）、專案沒上 GitHub、或需要把正式機密放進環境。

另外兩個容易忽略的限制：一是額度是跟整個帳號共用的，你平行開很多雲端任務時，本機那邊的 Claude Code 也會更快撞到上限；二是如果你公司有 IP allowlist，雲端 session 從 Anthropic 機房連 API 會被擋。下一步：把雲端留給「值得背景跑」的長任務，先確認你的 repo 在 GitHub、且沒有把正式機密塞進環境變數。

在本機執行的優缺點，還有那個很多人沒開的 /sandbox

先講優點，因為太明顯了：本機快、直接、能用 local server，而且 Claude Code 本機就內建一層 OS 沙箱，你可能根本沒在用。

本機的爽度在於它直接讀你的檔案、連你的 local 資料庫，改完馬上 localhost 重整就看到——這種秒級回饋是雲端那套「丟出去等回來」給不了的。對要一直看畫面、一直微調的前端工作，本機完勝。

真正被低估的是那層本機沙箱。用 /sandbox 開啟後，Claude Code 會用作業系統原語（macOS 的 Seatbelt、Linux 與 WSL2 的 bubblewrap）限制每個 Bash 指令的檔案與網路：預設只允許寫工作目錄，第一次要連新網域時會問你。它的代價是只管 Bash——Read、Edit 這些內建工具和 MCP、hook 不在這層內；要連那些都包進去，得用 sandbox-runtime 或容器。原生 Windows 不支援，要走 WSL2。

但我得誠實提醒一件事：沙箱降低風險，不等於零風險。官方文件自己就警告隔離「減少破口影響、但不消除」；2026 年初也確實被資安研究者揭露過 Claude Code sandbox 的網路繞過漏洞（官方已修補）。所以你要跑真正不信任的程式碼，別只靠本機 /sandbox，該上獨立 VM 或雲端。我自己用 AI agent 跑自動化時也踩過坑，那次自動化反而害我 AdSense 出問題的紀錄就是提醒：放手給 agent 之前，先想清楚它能碰到什麼。

本機最大的痛還是老問題——多個 agent 會搶 port。這點我在 Codex 那篇講得很細，解法（固定埠號、容器隔離、把一個丟雲端）兩邊通用。下一步：今天就先在本機跑一次 /sandbox 感受一下，等於免費幫你的本機加一層保護。

Claude Code 雲端 vs Codex 雲端：我比完的關鍵差異

直接講結論：兩個都是「把 GitHub repo 丟到雲端容器、跑完給你結果」，但在收費、快取、搬移方式上差很多。我把每天都在用的兩邊並排，整理成這張表。

面向	Claude Code on the web	Codex 雲端
雲端運算費	官方說不另收，與帳號用量共用額度	據社群實測約多燒 5 倍 credit
環境快取	約 7 天	約 12 小時
網路層級	None／Trusted／Full／Custom	None／常見依賴／全開
本機雲端搬移	`--remote` 丟上去、`--teleport` 拉回來	以非同步任務為主
程式碼來源	GitHub（非 GitHub 可 bundle）	GitHub

最該記住的就是第一列：成本邏輯完全不同。Codex 雲端那 5 倍 credit，是因為它把開容器、拉 repo、裝依賴都算進你的用量；Claude Code on the web 則是把雲端 VM 當成你訂閱內的功能，不另外計運算費，只是平行多任務會更快吃掉共用額度。所以如果你已經在養 Claude 的 Max 方案、又想平行跑一堆任務，Claude 雲端的邊際成本感覺起來會友善很多。

反過來，如果你主力在 OpenAI 生態、習慣 Codex 的 --attempts 一次產生多版本，那留在 Codex 雲端那套流程也很合理。這跟我一貫的主張一樣：不是選一個贏家，是讓對的工具做對的事——我把這個分工邏輯寫成過用五種場景把工作分給三家 AI，原則完全適用在這裡。下一步：如果你 Claude 跟 OpenAI 都有訂閱，先用各自的雲端跑同一個任務比一次，用實際扣的額度決定主力放哪邊。

那 Claude Code 該用雲端還本機？適合誰

給我的答案：即時互動用本機、能背景跑用雲端——跟我上一篇給 Codex 的建議一樣，因為這是工具型態決定的，不是哪個比較強。

我會這樣分。本機留給「需要一直看畫面、連 local 服務、秒級微調」的主力開發；雲端（--remote）丟給「能描述清楚、放著跑、跑完看 diff／開 PR」的長任務與平行探索。兩個 agent 在本機打架時，先做隔離（固定埠號、容器），而不是急著加硬體。

✅ 偏雲端：repo 在 GitHub、想平行、在意成本（不另收費這點對重度使用者很香）、想用手機或沒環境的裝置動工。✅ 偏本機：要即時看畫面、依賴本機服務、處理不能上雲的機密、或單純想要最快的回饋。

還有一個常被忽略的小錢坑：這些訂閱多半要付美金，刷卡的海外刷卡回饋信用卡那 1.5% 回饋跟手續費長期也是一筆。如果你考慮的是「乾脆租一台雲端開發主機」，我在自架 AI agent 到底要花多少錢跟中小團隊怎麼租雲端算力兩篇把成本算得很細。

想搞懂 Claude 各模型怎麼選（雲端跟本機都吃同一批模型），可以看 Claude 模型選擇指南；還在三大付費 AI 之間猶豫該把主力放誰，我把它們怎麼選整理成一篇幫你一次看完。下一步：先決定「主力本機＋雲端跑長任務」這個分工，再依成本微調比重。

FAQ 常見問題

Claude Code on the web 要另外付錢嗎？

不用額外付雲端運算費。官方在限制說明裡寫明：雲端 VM 沒有獨立的 compute 收費，它跟你帳號裡所有 Claude／Claude Code 用量共用 rate limit。換句話說，你平行跑越多雲端任務就吃越多額度，但不會多一筆機器錢。這也是它跟 Codex 雲端（據社群實測約多燒 5 倍 credit）最大的成本差異。

Claude Code 雲端 vs Codex 雲端，我該用哪個？

看你主力在哪個生態跟怎麼計費。已經吃 Claude Max 額度、又想平行跑很多任務，Claude Code on the web 不另收雲端費這點很划算；習慣 OpenAI、想用 Codex 一次產生多版本解法（--attempts），就留在 Codex。兩個都要 GitHub、都是非同步容器。最準的方法是用各自雲端跑同一任務、比實際扣的額度。

本機的 /sandbox 要開嗎？開了會不會綁手綁腳？

建議開，尤其你想少點權限提示時。它用 OS 原語限制每個 Bash 指令：預設只能寫工作目錄、連新網域會先問你，對日常開發幾乎無感，卻多了一層保護。代價是它只管 Bash，Read／Edit／MCP／hook 不在內；要全包就用 sandbox-runtime 或容器。原生 Windows 不支援，要走 WSL2。

Claude Code on the web 一定要用 GitHub 嗎？

要 clone 和 push 基本上是。雲端 session 從 GitHub clone、把結果 push 回去開 PR。沒上 GitHub 的本機 repo 可以用 bundle 直接上傳跑，但那種 session 推不回遠端。GitLab、Bitbucket 同理——能送上去跑，但結果拿不回 remote。所以雲端流程最順的前提就是 repo 在 GitHub。

sandbox 安全嗎？跑不信任的程式碼可以嗎？

沙箱降低風險，但不等於零風險。官方自己就警告隔離「減少破口影響、不消除」，2026 年初也有已修補的 sandbox 繞過漏洞被揭露。所以跑你不信任的程式碼，別只靠本機 /sandbox，該用獨立 VM 或 Claude Code on the web 這種整台隔離的環境，並維持最小網路權限。

結論：兩套雲端都懂，才知道什麼時候用哪個

把 Claude Code 跟 Codex 的雲端並排比完，我最大的收穫其實不是「哪個比較好」，而是它們適合的場景不一樣。Codex 雲端那套「開容器、算用量」很適合你要它一次跑多版本、深度探索；Claude Code on the web 不另收雲端費、又能用 --remote／--teleport 在本機跟雲端之間自由搬，對「平行很多任務、又想隨時接手」特別順。

本機則是兩邊共通的主場：最快、最直接，而且 Claude Code 還多送你一層 /sandbox。真正的解法從來不是選邊，是把即時互動留本機、能背景跑的丟雲端，再用隔離解決多 agent 打架。

我自己現在就是兩套雲端都接著、本機留給主力專案。AI 沒有讓我更清閒，但至少現在我知道每個任務該丟去哪一格。如果你還沒看過我拆 Codex 那一篇，Codex 雲端環境 vs 本機環境的設定與取捨可以接著讀，兩篇一起看會更完整。覺得有幫到你的話，可以訂閱我的部落格，我會不定期把這類踩坑筆記寄給你。