Codex 雲端環境 vs 本機怎麼選？兩個 AI agent 在我電腦搶 port 的解法

Q: 本機的 Codex 檔案好幾十 G，可以清嗎？

可以，但先搞清楚是什麼在吃空間。Codex CLI 的狀態在 ~/.codex（Windows 是 %USERPROFILE%\.codex），裡面的 session log 會越積越大，官方 issue 有人回報單檔上看 GB；再加上各專案的 node_modules 跟快取，就是幾十 G 的來源。可以定期清理舊 session log、用 node_modules 清理工具，或把不常動的專案歸檔。與其搬到新電腦，先瘦身往往更實際。

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

本機環境：直接讀你的硬碟、跑你的 local server，回饋最快、最省用量（雲端跑同一個任務據社群實測大約多燒 5 倍 credit）；代價是兩個 agent 會搶同一個 port、互相把對方的 dev server kill 掉。

Codex 雲端環境：每個任務開一個獨立容器、可同時並行多個、跑完直接給你 diff，乾淨又能丟著跑；代價是啟動要約 1–5 分鐘、單一任務大約幾分鐘到 30 分鐘、預設斷網，而且要先接 GitHub＋寫 setup script。

多 agent 打架的真相：git worktree 只隔離「檔案」，不隔離「port／資料庫／服務」——光開 worktree 救不了搶 port，要嘛固定埠號約定、要嘛用容器做 runtime 隔離。

行動建議：先別急著買第二台電腦。把「需要常開本地預覽」的專案留本機、把「能丟著跑」的長任務丟雲端，這個分工比搬幾十 G 檔案到另一台機器省得多。

凌晨一點，我盯著兩個終端機視窗發呆。左邊 Claude Code 正在 port 3000 上跑前端預覽，我切到右邊另一個專案讓 Codex 也 build 起來——「砰」，兩邊的 dev server 開始互相把對方的 process 殺掉、又各自重啟，像兩隻搶同一個碗的貓。

後來我才認真去查：Codex 雲端環境其實可以把任務丟到 OpenAI 的容器裡跑，根本碰不到你本機的 port。但它不是萬靈丹——會慢、要設定、還會多燒用量。本機跑快歸快，兩個 AI agent 卻會在同一台電腦上打架。

這篇我把雲端環境跟本機環境的差別整個拆開，附上雲端環境的設定教學，再老實講兩邊的優缺點。最後是我覺得最有價值的部分：如果你跟我一樣，電腦裡同時養著好幾個 AI agent（像會操作畫面、產 artifact 的 Claude agent 跟 Codex），它們互相衝突時到底該怎麼解？答案可能跟你想的不一樣。

Codex 雲端環境 vs 本機環境，到底差在哪？

一句話：本機環境是「在你自己的電腦上跑」，Codex 雲端環境是「把任務送到 OpenAI 的容器裡跑、跑完回傳結果」。差別不只是地點，而是整套工作方式都不一樣。

先把名詞理清楚。OpenAI Codex 其實有三個面貌：在你終端機裡跑的 Codex CLI、塞在 VS Code 之類編輯器裡的 IDE 擴充，以及這篇的主角——在 ChatGPT 裡操作、跑在雲端容器的 Codex 雲端。本機 CLI 會讀你當下的工作目錄、直接改檔案、在一個限定資料夾的沙箱裡跑指令；雲端則是另一條路，你丟出任務、它在 OpenAI 那邊開容器、做完把一份 diff 還給你。

我自己的體感是這樣：本機像「站在你旁邊跟你一起改」，雲端像「你發一張工單給遠端同事，他做完再把成果寄回來」。前者即時、黏在你的環境上；後者是非同步、乾淨、可以同時發很多張工單。下面這張表是我覺得最該先記住的幾個差異。

面向	本機環境（CLI / IDE）	Codex 雲端環境
跑在哪	你自己的電腦，讀本機硬碟與檔案	OpenAI 的隔離容器，從 GitHub 拉程式碼
啟動速度	幾乎即時	約 1–5 分鐘建容器（快取後較快）
互動方式	即時對話、邊看邊改	非同步，丟著跑、跑完給 diff
同時跑幾個	受本機資源與 port 限制	可並行多個任務
網路	全開（用你的網路）	agent 階段預設斷網，要手動開白名單
用量成本	相對省	同一任務據實測約多燒數倍（約 5×）

看懂這張表，你大概就能猜到後面的故事：本機贏在「快」跟「直接」，雲端贏在「並行」跟「乾淨隔離」。如果你還在猶豫要不要踏進 AI agent 開發這條路，我之前寫過一篇用 Codex、Claude、Gemini 一起蓋一個網站的實作對照，可以先看那篇感受一下這些 agent 平常怎麼分工。下一步：先確認你的專案是「需要一直開本地預覽」還是「可以丟著跑」，這個答案決定你該偏本機還是雲端。

Codex 雲端環境怎麼設定？從接 GitHub 到第一個任務

直接講結論：雲端環境的設定核心就一件事——告訴 Codex「拿到你的程式碼之後，要怎麼把開發環境準備好」。設定一次，之後每個任務都用同一套環境開容器。聽起來抽象，我把流程拆成步驟你就懂了。

整個設定發生在 Codex 的 settings 裡。根據 OpenAI 官方的雲端環境文件，一個「環境（environment）」會幫你定義：用哪個基底映像檔、釘哪些語言版本、有哪些環境變數與 secrets、開機要跑什麼 setup script、以及網路權限。實際操作大致是這幾步：

❶ 接上 GitHub。雲端 Codex 是從 GitHub repo 拉程式碼的，所以第一步是授權 ChatGPT 的 GitHub 連接器、把要給它碰的 repo 開放權限。沒接 GitHub，雲端這條路就走不了——這也是它跟本機最大的門檻差異。

❷ 選基底映像檔。預設是 OpenAI 維護的 codex-universal，一個大致預載常見語言與工具的容器（據技術社群拆解，它以 Ubuntu 24.04 為底，預載 Python、Node、Go、Rust 等多種 runtime，外加 poetry、pnpm 這類工具）。多數情況直接用預設就好。

❸ 釘版本、設環境變數與 secrets。你可以指定 Python、Node 的版本，避免「雲端跟我本機版本對不上」。要特別記一個重點：secrets（像 API key、資料庫密碼）只在 setup 階段可用，agent 開始工作前就會被移除，這是刻意設計，避免機密被寫進產出的程式碼裡。

❹ 寫 setup script。這是整個環境的靈魂。常見的套件管理器（npm、yarn、pnpm、pip、poetry⋯）Codex 會自動偵測 lockfile 幫你裝；複雜一點的就自己寫一段 bash。重點是這個 script 跑的時候有完整網路，讓你把依賴一次裝好。

❺ 設網路權限，然後丟第一個任務。存好環境後，建立任務時 Codex 會：開容器、checkout 你指定的 branch/commit、跑 setup script、套用網路政策、進入 agent 迴圈（改檔、跑指令、自我驗證），最後把 diff 給你。

🚧 最容易踩的雷：setup 跟 agent 是兩個獨立的 bash session。你在 setup script 裡 export 的環境變數，到 agent 階段是不會保留的。要持久化請寫進 ~/.bashrc 或用環境變數設定，不要傻傻 export。我第一次設就栽在這，agent 一直說找不到變數，查半天才發現是這個。

還有一個省時間的機制要知道：容器狀態最多會快取約 12 小時。第一次跑會完整裝一遍，之後在快取有效期內再開任務，就只跑一個輕量的 maintenance script 同步依賴，快很多。但你只要改了 setup script、環境變數或 secrets，快取就會失效、得重裝。所以別頻繁改 secrets，不然每次都在等重建。如果你想更系統地理解這些 agent 工具怎麼用，非工程師到底值不值得學 Claude Code 這篇裡的入門心法也適用在 Codex 上。下一步：先用預設 codex-universal 跑通一個最簡單的任務，再慢慢加 setup script，不要一開始就想把環境調到完美。

在雲端環境執行的優點與缺點，值得嗎？

先給判斷：雲端環境最大的價值是「並行」跟「乾淨隔離」，最大的代價是「慢」跟「貴」。它解決的是「我想同時推進很多事、又不想搞髒本機」的問題，不是「我想要更快的即時回饋」。

我自己最有感的優點是——可以丟著跑、還能一次發好幾個。本機跑一個大重構，我得守在電腦前；雲端我可以同時開三個任務，去煮個咖啡回來看哪個結果最好。Codex 雲端甚至有個 --attempts 之類的玩法，讓它一次產生好幾個解法版本讓你挑。對於「探索型」的工作，這比本機一次只能試一條路有效率太多。

第二個優點是環境乾淨、可重現。雲端每個任務都是從同一套環境開全新容器，不會有「在我電腦上好好的、換台機器就壞」的問題。而且 agent 階段預設是斷網的，這點官方在網路存取文件裡講得很清楚：setup 階段有網路裝依賴，但 agent 真正工作時預設不能連外，要連得自己開白名單（None／常見依賴預設／全開三檔，還能限制只允許 GET 這類唯讀方法）。這是為了防 prompt injection、資料外洩跟惡意依賴——對於碰到機密程式碼的團隊，這層隔離是本機很難做到的。

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

✅ 雲端環境適合你，如果你：有能丟著跑的長任務（大重構、批次修改）、想同時並行多個任務或多個 repo、在意環境乾淨與機密隔離、程式碼本來就放在 GitHub 上。

❌ 雲端環境先別急著上，如果你：需要秒級即時回饋的細修、需要一直開本地預覽看畫面、很在意用量成本（雲端約多燒數倍）、專案沒上 GitHub 或重度依賴本機服務。

講白一點的缺點清單：啟動有延遲（建容器約 1–5 分鐘，雖然快取後會快）；單一任務有時長上限（大約幾分鐘到 30 分鐘，跑不完就得拆小）；非同步本身有切換成本，你得習慣「發出去、晚點回來收」的節奏；還有用量更燒——據社群實測，雲端跑同一個任務大概要多花好幾倍（約 5 倍）的 credit，因為它幫你做了開容器、拉 repo、裝依賴這些「本機你自己早就做好」的事。如果你正在精算每月該不該續這些 AI 訂閱，我把帳算給你看過：哪些 AI 訂閱真的值得續那篇可以搭著看。下一步：把雲端環境留給「值得等、值得多花」的長任務，別拿它做你五秒就想看到結果的小改動。

在本機環境執行的優點與缺點，問題出在哪？

先講優點，因為它太明顯了：本機就是快、直接、省。它直接讀你的檔案、用你的環境變數、連你的 local 資料庫，改完馬上 localhost 重整就看到。這種「秒級回饋」的爽度，是雲端那套「丟出去等回來」永遠給不了的。對於要一直看畫面、一直微調的前端工作，本機完勝。

用量也省。同樣一個任務在本機跑，不用付雲端那些開容器、拉 repo 的「平台代工費」。如果你是預算敏感的個人開發者，本機是默認首選，雲端是「特定情境才動用」的工具。這也是為什麼幾乎所有人都從本機開始用 AI agent。

但本機的麻煩，正是這篇文章的起點——當你電腦裡不只一個 agent，它們會打架。我遇到的就是最經典的那種：兩個專案的 dev server 都預設搶 port 3000，誰後啟動誰就把前一個頂掉。

這不是我一個人的幻覺。Claude Code 的 GitHub issue 區就有人專門回報「多個 session 競爭同一個 port、互相 kill」，還提了動態分配 port 的 feature request。CLI agent 連 OAuth 登入回呼都會去搶隨機 port，衝突點其實不只 3000。

第二個本機的隱形負擔是磁碟肥大，這點剛好戳中很多人的痛——「Codex 本機檔案怎麼莫名其妙好幾十 G」。Codex CLI 的資料放在 ~/.codex（Windows 在 %USERPROFILE%\.codex），裡面塞了設定、每一次的 session 記錄（JSONL）跟 log。

官方 issue 就有人回報單一 session 的 log 檔長到好幾百 MB、甚至上看 GB；再加上每個專案各自的 node_modules、各種快取，幾十 G 一點都不誇張。這也是為什麼「搬到另一台電腦」會讓人卻步——要搬的不只程式碼，還有這一大坨環境跟歷史。

📌 本機的兩個隱藏成本：① port／runtime 衝突——多個 agent 搶同一組埠號與本機服務；② 狀態肥大——session log、快取、各專案依賴越積越多，讓「換機器」變成大工程。這兩件事，正是把人推向雲端、或推向「買第二台」的主因。

下一步：先打開你的 ~/.codex 跟各專案的 node_modules 看一下到底是什麼在吃空間，再決定要清理、要隔離、還是要把一部分工作搬上雲。

兩個 AI agent 在同一台電腦打架，我的解法順序

這段是我最想分享的。先講一個多數教學沒講清楚、害很多人白忙的真相：git worktree 只隔離「檔案」，不隔離「port、資料庫、服務」。所以如果你以為「幫每個 agent 開一個 worktree 就不會搶 port」——錯，它們還是會搶。

先解釋一下 git worktree 為什麼這麼紅。它讓你從同一個 repo 切出多個工作目錄、各自在不同 branch，共用同一個 .git，所以每個 agent 有自己的檔案空間、改動不會互相覆蓋。Claude Code、Codex、Cursor 現在都原生支援，是跑多個並行 agent 的主流隔離法。

但關鍵就在這——它隔離的是檔案系統，不是執行階段。兩個 worktree 裡的 dev server 一樣會去搶 port 3000、一樣連同一個本機資料庫。我就是吃了這個虧才想通：worktree 解的是「改壞同一份檔案」，不是「搶同一個 port」。

所以真正要解衝突，得分兩層想：檔案層用 worktree，runtime 層另外處理。我自己會照成本由低到高試這個順序：

❶ 固定埠號約定（最便宜，先做這個）。給每個專案釘死不同的 port，別讓它們都搶 3000。Next.js 用 next dev -p 3001 或在 .env 設 PORT；Vite 在 config 裡設 server.port 並把 strictPort 開成 true（不然它會偷偷跳號，你反而搞不清誰在哪）。光是這一步，就解掉我八成的日常衝突。

❷ 用容器做 runtime 隔離（要徹底就上這個）。把每個專案包進 Docker 或 Dev Container，各自有獨立的 port 對映、獨立的服務。docker compose 裡用 127.0.0.1:3001:3000 這種寫法把容器埠對到不同的本機埠，或乾脆用 Docker 內網讓容器之間用服務名互通、不對外開埠。要注意一個雷：worktree 跟 devcontainer 直接併用會卡，因為 worktree 的 .git 是檔案不是資料夾，容器裡的 git 操作容易壞，這兩個我不會硬湊在一起。

❸ 把其中一個 agent 丟上雲端（不占本機資源）。這就回到前面講的 Codex 雲端環境——讓需要「常開本地預覽」的那個專案留在本機獨佔 port，把另一個「能丟著跑」的長任務交給雲端容器。雲端根本不碰你的本機 port，衝突自動消失。這是我覺得最優雅、又不用多買硬體的一招。如果你另一邊跑的是 Claude Code，它的雲端（on the web）邏輯不太一樣、官方還說不另外收運算費，我寫成了對照的姊妹篇：Claude Code 雲端環境 vs 本機。我自己用 AI agent 跑自動化時也踩過不少坑，那次自動化反而害我 AdSense 出問題的紀錄就是血淚教訓，有興趣可以看。

❹ 把不同 agent 分流到不同帳號／工作流，而不是擠在同一個情境。與其讓兩個 agent 在同一個專案同一個埠搶資源，不如照「工作型態」分工——本機 agent 做需要即時互動的細修，雲端 agent 做能背景跑的批次。這個「分工」思路其實跟我寫過的用五種場景把工作分給三家 AI 是同一套邏輯：不是選一個贏家，是讓對的工具做對的事。

下一步：今天就先做 ❶——把你兩個常衝突的專案各釘一個固定 port，這是 0 成本、5 分鐘、立刻見效的解。

那到底要不要買第二台電腦？遷移幾十 G 划算嗎？

直接給我的答案：多數情況不用。「一台跑 Claude、一台跑 Codex」聽起來乾淨，但你已經發現它的隱藏成本了——幾十 G 的環境、session、依賴要搬，而且以後每裝一個新工具、每改一個設定，都要兩台同步，維護負擔加倍。為了解一個 port 衝突去買一台電腦，是用大砲打蚊子。

我會這樣排優先順序給你參考。先問自己：衝突的根因是「資源不夠」還是「沒有隔離」？如果是後者（大部分人都是），那前一段的固定埠號＋容器隔離＋雲端分流就解決了，根本不用動到硬體。真正值得考慮第二台或雲端主機的，是「資源真的不夠」——例如你要同時跑好幾個吃記憶體的本地模型或 build。

你的情況	我會建議
只是 port／服務互搶	固定埠號 + 容器隔離，不用買機器
想要一個能丟著跑的乾淨環境	用 Codex 雲端環境，按用量付費
本機資源真的不夠（記憶體/CPU 滿載）	考慮租雲端開發主機，而非買第二台實體機
要處理機密、需要強隔離與稽核	雲端環境或公司配發的隔離環境

如果你真的需要「第二台」，我會優先想雲端開發主機而不是再買一台實體電腦。租一台雲端虛擬機當開發箱，要用才開、不用就關，照用量付費，省掉搬幾十 G、省掉兩台同步的痛苦；真的需要更重的算力時再升級規格就好。關於「自己租機器、自架 agent」這條路的真實成本（包含 VPS、雲端主機、API 用量這些常被低估的開銷），我在自架 AI agent 到底要花多少錢那篇算得很細；想更宏觀理解「租雲端算力」這件事，也可以看中小團隊怎麼租雲端算力。

還有一個常被忽略的小錢坑：這些 agent 多半要付美金訂閱，刷卡的海外刷卡回饋信用卡那 1.5% 回饋跟手續費，長期下來也是一筆。順手提一下，因為很多人只算工具錢、忘了算金流成本。至於工具本身的訂閱怎麼取捨，免費版到底夠不夠用、$20 該不該付我另外算過一篇帳。下一步：先把「換隔離方式」試到底，真的撞到資源天花板，再考慮雲端主機；買第二台實體機放到最後。

FAQ 常見問題

Codex 雲端環境跟本機環境，新手該先用哪個？

先用本機。本機即時、省用量、不用接 GitHub 也不用寫 setup script，學習曲線最低，適合摸清楚 Codex 怎麼跟你協作。等你遇到「想同時推進好幾件事」「想丟著跑長任務」「兩個 agent 在搶 port」這些情境，再去設雲端環境。把雲端當成進階工具，不是入門起點。

用 git worktree 就能解決兩個 agent 搶 port 的問題嗎？

不能。這是最多人誤會的一點。worktree 只隔離檔案系統——讓兩個 agent 改不同檔案不打架；但它們的 dev server 還是會去搶同一個 port、連同一個本機資料庫。要解 port 衝突，得另外做：最便宜是給每個專案釘固定埠號，最徹底是用 Docker／Dev Container 做執行階段隔離。worktree 跟容器隔離是兩件事，要搭配用。

Codex 雲端環境執行為什麼比較慢、比較貴？

慢是因為它每次要建容器、checkout 程式碼、跑 setup script 裝依賴，這些本機你早就準備好了，雲端得現做（首次約 1–5 分鐘，12 小時內有快取會快一些）。貴是因為這些「代工」都算用量——據社群實測，同一個任務雲端大約多燒 5 倍 credit。所以雲端適合「值得等、值得多花」的長任務，不適合你五秒就想看到結果的小改動。

雲端環境的 agent 預設可以上網嗎？會不會有安全風險？

agent 工作階段預設「斷網」，只有 setup 階段為了裝依賴才有網路。你可以手動開白名單（None／常見依賴／全開三檔），還能限制只允許 GET 這類唯讀方法。官方建議用最小權限、從 None 開始加，因為開網路會帶來 prompt injection、資料外洩、惡意依賴等風險。對碰機密程式碼的人，這層預設斷網反而是雲端的一大優點。

本機的 Codex 檔案好幾十 G，可以清嗎？

可以，但先搞清楚是什麼在吃空間。Codex CLI 的狀態在 ~/.codex（Windows 是 %USERPROFILE%\.codex），裡面的 session log 會越積越大，官方 issue 有人回報單檔上看 GB；再加上各專案的 node_modules 跟快取，就是幾十 G 的來源。可以定期清理舊 session log、用 node_modules 清理工具，或把不常動的專案歸檔。與其搬到新電腦，先瘦身往往更實際。

結論：別急著選邊，讓對的工具做對的事

寫到這裡，回頭看我那個凌晨一點的 port 大戰，其實答案很簡單——我一開始就問錯問題了。我以為要在「本機 vs 雲端」「Claude vs Codex」「一台 vs 兩台」之間選一個贏家，但真正的解法是分工。

本機環境快、直接、省，留給需要即時看畫面、一直微調的工作；Codex 雲端環境乾淨、能並行、能丟著跑，交給值得等的長任務跟需要隔離的場景。兩個 AI agent 會打架，不是因為它們不能共存，是因為你還沒給它們各自的跑道——固定埠號、容器隔離、或把一個丟上雲，比你想像中簡單，也比買第二台電腦省太多。

我自己現在的配置就是這樣：本機留給天天要開預覽的主力專案，長任務跟探索型工作丟給雲端，幾十 G 的環境我選擇定期瘦身而不是搬家。AI 沒有讓我更清閒，但至少現在我的兩個 agent 不再半夜互相廝殺了。如果你也在養一群 AI agent、想看它們還能怎麼分工，我把三大付費 AI 怎麼選整理成一篇，可以接著看。覺得這篇有幫到你的話，可以訂閱我的部落格，我會不定期把這類踩坑筆記寄給你。