Codex 雲端環境指南：建立、Publish 發布到 Republish 更新的生命週期

Codex 雲端環境，官方的定義是任務可重複使用的整組設定，內容是四個元素的組合：儲存庫、相依套件、工具與存取設定；任務則是你每一次交代的工作，跑在從環境生出來的獨立工作區裡。把工作交給 Codex 在雲端跑，多數人卡住的地方不是指令難下，而是心裡的模型沒有換過來：本機的使用習慣是「打開資料夾就開工」，雲端卻多出一層要先備妥的東西，叫做環境。分不清這兩層，就會冒出「本機明明有這個檔案，雲端怎麼說找不到」「上次任務裝好的工具，這次新任務為什麼不見了」這類困惑。這篇教學以生命週期為主軸，把環境從建立、Publish 發布、複用到更新的四個階段完整走一遍，補上任務驗收的三件事與卡住時的排查方法，幫你對雲端這條路建立一套用得起的心智模型。

先把答案講完：環境建立後按下 Publish，Codex 會把準備好的檔案系統封存起來，之後每個任務都從它拿到一個獨立工作區，電腦睡眠照跑；專案變了就編輯環境再 Republish，既有任務不受影響。這套「建立、Publish、複用、Republish」的循環就是全文主軸，後文依四個階段展開官方機制、常見誤讀與該盯的細節，再補上任務驗收三件事、卡住排查與手機上的分界線。涉及功能名稱與機制的段落，都以 2026 年 10 月查閱的 OpenAI 官方 Codex 文件為準。

環境是資產，任務是消耗品

先給全文最重要的一組對照：環境是資產，任務是消耗品。雲端環境的官方定義寫得很直白，它是任務使用的可重複使用設定，內容涵蓋儲存庫、相依套件、工具與存取設定；而每一個新任務，都會從已發布的環境拿到一個屬於自己的隔離工作區。這句話拆開來看有兩層意思：第一，你在任務裡做的任何事，都不會回頭污染環境本身，任務內的檔案修改不回寫環境；第二，想讓未來的任務享受新的設定，唯一的路是回去改環境再重新發布，而不是在某個任務裡偷偷裝了什麼然後期待它留下。

這組對照為什麼重要？因為它決定了你該把力氣花在哪裡。把環境當消耗品的人，每次開任務都重新描述一次專案怎麼裝、測試怎麼跑，做了十個任務等於把同樣的設定講了十遍；把環境當資產的人，花一次功夫把設定整理進環境，之後每個任務都站在同一個起點上。官方文件對雲端環境的價值主張正是這一句：跨任務重複使用你的儲存庫、相依套件與工具，每個任務保有自己的工作區，專案變了就更新設定。換句話說，環境是投資，任務是花費，投資做得扎實，花費才會便宜。

還有一個前置觀念要先立起來：雲端環境的標準建立流程抓的是 GitHub 儲存庫。官方建立流程的第一步就是選擇 GitHub 儲存庫，視需要連接 GitHub 帳號（GitLab 另有 Beta 整合，本文稍後交代邊界）。如果你的專案還活在本機資料夾裡、從來沒有推上版控，雲端這條路對你暫時是封閉的；對儲存庫與 Pull Request 這套語言還很陌生的人，可以先讀過〈GitHub Repo 的非工程師入門〉，把儲存庫、分支、commit 這幾個詞弄熟，後面所有關於環境與任務的討論才會有共同的詞彙基礎。

Local、Worktree、Cloud：工作到底跑在哪台機器

開任務之前，Codex 會先問你一個問題：Work in，要在哪裡工作。官方文件給出三個選項，Local 是直接在你目前的專案資料夾工作，Worktree 是把修改隔離在一個 Git worktree 裡，Cloud 則是從一個已發布的可重複使用環境，啟動一個擁有獨立工作區的遠端任務。三者最本質的差別只有一句話：Local 與 Worktree 的對話都跑在你的電腦上，Cloud 的任務跑在 OpenAI 管理的雲端工作區裡。誰在執行工作，決定了後面所有限制的形狀。

這張表真正要想的是右邊那一列。Local 與 Worktree 的優勢是就地：你正在看的檔案、已經登入的服務、裝好的工具鏈，全部垂手可得。Cloud 的優勢是非同步與可重現：任務不依賴你的電腦，官方文件明確說它可以在你的電腦睡眠時繼續工作，而且同一個任務可以在不同裝置上重新打開接續。代價也寫在官方文件裡：你電腦上的本機檔案、執行中的程序、瀏覽器登入狀態與 VPN 存取權，都不會自動轉移到雲端，雲端任務只能使用它的環境裡備妥的檔案與服務。把執行位置搬上雲端的同時，本機的便利也就留在本機；評估工作該放哪一邊時，先確認它依賴的檔案與服務能不能進環境。

所以選擇的判斷不難下。工作需要本機才有的東西，例如只有你電腦裝得上的內部工具、不能離開機器的敏感檔案，就留在本機，怕弄亂專案就加開 worktree；工作範圍能用一個 GitHub 儲存庫講清楚、想要背景跑、想要之後從手機或別台機器接手，就走雲端。兩者也不是二選一，官方的定位是同一個代理的兩個執行位置，白天在本機互動式來回，晚上把長任務丟雲端，是很多人實際的節奏。三種模式的底層邏輯與官方依據，整理自官方環境模式文件在 2026 年 10 月的內容。

建立階段：五步流程的概觀，與最先要盯的兩個欄位

五步流程之前，先做一輪可用性檢查。個人要建立自己用的私有環境，門檻有三個：第一是 ChatGPT 方案，Codex Cloud 不包含 Free 與 Go，可用的是 Plus、Pro、Business、Enterprise，以及 Edu、Edu Plus 與 Edu Pro 教育方案，guest、K-12 與 view-only 這類席位同樣不能建立雲端環境；Healthcare 這類醫療相關帳號，界線寫在官方 HIPAA 設定指引裡：BAA 不涵蓋 Codex Cloud，也不得用 Codex Cloud 處理 PHI（受保護健康資訊），這類帳號能不能建立雲端環境，要依官方帳號與合規文件另行確認；第二是 workspace 的雲端存取，工作區管理端能控制雲端功能的開放程度，帳號方案到位、工作區沒開，一樣進不了門；第三是儲存庫權限，環境要連的 GitHub 儲存庫，你的帳號必須有存取權，否則流程會停在選庫那一步。第四個門檻只在工作區層級才出現：官方對權限邊界分得很清楚，「Use Codex in the cloud」控制的是能不能使用雲端任務，「Manage workspace environments」控制的是工作區共用環境的建立與編輯；個人私有環境不需要這個權限，要建立或編輯工作區共用環境的帳號，才需要先被授予它。個人門檻過了就能進下面的流程，要動共用環境，四項都得過。

建立的完整流程，官方雲端文件給的是五步：在網頁或桌面 App 登入，Work in 選 Cloud、打開 Select environment，選 Create environment；挑選要處理的 GitHub 儲存庫，按 Get started，視提示連接 GitHub；接著 Codex 會檢查儲存庫、安裝相依套件與工具、測試工作流程；你檢視設定與測試結果、儲存變更、按下 Publish，等到出現 Environment published；然後開始第一個任務。這五步的每一步畫面細節、雲端版的帳號與方案門檻、與其他三個安裝入口的對照，站上的〈Codex 安裝與入口選擇完整指南〉已經逐項走過，這裡不重複教學，只談建立階段裡最先值得盯的東西。

最先要盯的是兩個執行欄位，它們是環境的骨幹。第一個是 Install script，官方定義是安裝相依套件、準備開發資產的命令，例如裝套件、編譯資產這類每次從零開始都要做的事；第二個是 Start skill，定義是啟動服務並確認服務就緒的指示，例如把資料庫或開發伺服器跑起來的步驟。這兩個欄位之所以關鍵，是因為發布機制在後面會把整個準備好的檔案系統封存起來，之後每個新任務都從這份封存出生。附帶一個精確點：Publish 保存的是檔案系統與設定基準，不是執行中的程序；Start skill 描述的是每次把服務跑起來的指示，不會把某次執行中的服務原封不動存進環境。Install script 與 Start skill 寫得完整，每個任務的起點就完整；寫得含糊，每個任務都會在同一個坑裡跌一次。把它們當成環境的 DNA 來寫，是建立階段報酬率最高的投資。這兩個欄位之外，儲存庫選擇、網際網路存取、環境變數、網路憑證（官方英文 Network secret，後文統一稱網路憑證）、隱私設定乃至 OIDC 與 VPN，其餘骨幹同樣在建立流程中一併備妥，本文在存取設定與其後的章節展開；按下 Publish 前，把它們當成一張檢查清單掃過一遍再出手。

建立過程中 Codex 不是安靜的。官方機制的描述是它會檢查專案、走完設定流程，遇到無法判斷的設定或缺漏的存取權就回頭問你，例如專案需要哪個版本的工具、下載套件時缺哪張憑證。這時別只被動等它問，主動下一句驗收型的指令：請確認這個專案需要哪些工具，試著執行現有的測試，並列出還沒完成的設定。這句話的價值在於它強迫產出一份可檢查的清單，你能看到失敗的原因是否解決、測試是否真的執行過；若回報裡只有一句安裝完成，那還不能當作專案可用的證明。這個標準會在後面的驗收章節反覆出現，因為它同樣適用於環境建立與任務結案。

順帶建立一點規模感。雲端任務跑在一台由方案決定規格的虛擬機上：官方文件把預設值列成三列，Plus 與 Edu Plus 是 2 個 vCPU、8 GiB 記憶體與 8 GiB 磁碟；Pro、Business 與 Enterprise 是 4 個 vCPU、16 GiB 記憶體與 32 GiB 磁碟；Edu 與 Edu Pro 同屬 4 個 vCPU、16 GiB 記憶體與 32 GiB 磁碟的等級。更大的規格屬於 Enterprise 的客製範圍。對多數網站與應用專案的建置與測試來說，這個規格是夠用的訊號；但若你的專案要跑重型編譯或大型資料處理，先知道天花板在哪，比事後埋怨任務慢更有用。

託管平台的邊界也要誠實交代：雲端環境的標準建立流程以 GitHub 為主，環境選單裡挑的是 GitHub 儲存庫；GitLab 與自架的 GitHub Enterprise Server 並未進入這條標準流程，官方將兩者列在雲端環境目前不支援、但已排上發展藍圖的項目裡。不過 GitLab 並非整個被關在門外：官方另有 GitLab Beta 第三方整合，走的是 project environment 這條獨立路徑：可以建立 GitLab project environment、在合併請求裡請它審查、用 @codex 交辦任務，支援專案層級的憑證、網路存取與安裝命令，一樣跑在 Codex 雲端上；它沒有的是 GitHub 版那套桌面 App 的儲存庫控制，例如直接建 Pull Request 的入口。可用性上，這條 Beta 路徑跟標準流程不同：官方標明它開放所有 ChatGPT 方案，真正的卡點落在 GitLab 端的權限與連線設定：gitlab.com 走 ChatGPT 裡的標準連接流程即可，self-managed 與 Dedicated GitLab 的前置條件重得多，要由 workspace 管理員先發布範本、在設定裡接好 service account，牽涉群組層級活動與簽名 webhook 的場合還需要 GitLab 19.0 以上；入場門檻要跟標準流程分開核對，別把 GitHub 的操作步驟直接照搬。自架的 GitHub Enterprise Server 則仍在限制中，尚無對應的整合路徑。專案託管在 GitLab 的人，動手前先到官方文件確認最新狀態，別只信任何教學的轉述，包括這一篇。文件類的資訊本來就有保存期限，這也是為什麼這篇寧可把判斷框架講厚，而不把畫面路徑背給你聽。

Publish 發布：封存一份「準備好的檔案系統」

Publish 是整個生命週期的樞紐，也是最多人誤讀的一步。官方雲端環境設定文件對它的機制描述只有一句，但每個字都有分量：發布會把準備好的檔案系統封存起來，供新任務使用。拆解這句話：被封存的是檔案系統的當下狀態，包含裝好的套件、設定好的工具、抓下來的儲存庫；封存的目的是給未來的新任務當起點；而 Environment published 這個狀態一出現，環境就進入了可被任務使用的生命期。「封存」也要理解精確：發布固定的是 setup 基準，也就是裝好的套件、設定好的工具與設定檔；儲存庫內容並不因此凍結，任務進行中仍可經官方的背景 repository refresh 取得新的 commit，而且不重跑安裝與啟動命令，這個機制留到複用階段展開。反過來說，還沒發布的環境會掛著 Unpublished 標記，任務選不到它，官方文件明說未發布的環境無法供任務使用。發布不是形式，是開關。

三個常見誤讀需要在這裡一次清理。誤讀一：以為 Publish 之後網站就公開上線了。沒有這回事。發布封存的是工作環境，是給 Codex 任務用的準備狀態，與你的網站要不要部署、要不要公開完全是兩個層面的事，網站上線走的是專案自己的部署流程。誤讀二：以為 Publish 等於任務完成。發布的是環境不是任務，按下 Publish 之後你才要開始第一個任務。誤讀三：以為發布就是定稿，改不了了。環境可以編輯後重新發布，這正是生命週期裡更新階段的入口，後面會專門談。把這三個誤讀排掉，Publish 的定位就乾淨了：它定義新任務的起點，而且這個起點是可以養的。

發布還有一個裝置面的限制要知道：建立環境與發布環境的動作，只能在網頁或桌面 App 上做；手機上的 Codex 可以挑一個已發布的環境來開任務，但不能從無到有建立新環境。這個分工背後的道理不難猜，環境設定涉及儲存庫授權、安裝腳本檢視這類需要大螢幕與耐心的操作，手機適合消費進度，不適合生產設定。實務上的節奏因此很自然：在辦公桌前把環境建立並發布好，之後不管人在哪裡，任務都隨時可以開。

複用階段：每個任務有自己的工作區，環境是共用的起點

環境發布之後，價值兌現的方式是複用。官方對這個階段的描述有三個互相咬合的性質：每個任務有自己的工作區，任務可以在你的電腦睡眠時繼續工作，同一個任務可以在不同裝置上重新打開接續。把這三句合起來讀，雲端任務的面貌就出來了：它是一個獨立存活在雲端的工作單元，你的裝置只是它的遙控與顯示器。早上在辦公室送出的調查任務，中午闔上筆電去開會，它照跑；晚上回家用桌機打開同一個任務，看到的還是同一份工作區。這種跨裝置跨時間的連續性，是本機模式原理上給不了的。

但工作區的壽命有但書，而且這個但書直接影響你怎麼安排工作節奏。官方文件寫明：預設情況下，任務保存的 VM 狀態，在你最近一次啟動一輪對話或恢復任務之後，最多七天內可恢復。注意兩個精確點：官方的起算點是最後一次啟動一輪對話或恢復任務，每次啟動新回合或恢復任務，七天的可恢復期限就重新起算，不是從任務送出那一刻一路算到底；而且官方在同一段落補了一句提醒，保存狀態不能取代版控。這句提醒值得放大：任務工作區裡那些還沒 commit 的修改、還沒推上儲存庫的成果，七天後可能就跟著 VM 狀態一起回收。重要的東西，當下就 commit。

工作區與環境之間還有一個自動化的細節，處理得相當體貼：任務進行中，儲存庫的更新會在背景自動執行，官方說它會保留相依套件的快取，不會重跑安裝或啟動命令。意思是任務不必為了拿到儲存庫最新的 commit 而整個重置，你也不用擔心背景更新把你裝好的依賴沖掉。這個設計讓「環境給穩定性、儲存庫給新鮮度」兩件事互不干擾，是複用階段能長期運轉的技術基礎。

既有任務的延續性也值得單獨說：官方描述既有任務會帶著自己保存的檔案繼續，包括未提交的修改與已安裝的工具。所以如果你在一個任務裡裝了某個分析工具、改了幾個檔案還沒 commit，下次回到同一個任務，這些都還在。關鍵是「同一個任務」四個字：延續的是任務，不是環境。想讓這個工具出現在所有未來任務裡，正確的動作不是在任務裡裝了就不管，而是回環境把安裝寫進設定再重新發布。任務內續命與環境級升級，是兩條不同的路，走錯條就會一直重複勞動。

更新階段：Republish 的時機、後果與團隊共用

專案會變，環境要跟著變，這就是生命週期的第四個階段。更新的官方流程是：打開環境的選單選 Edit，讓 Codex 重新準備並測試，儲存變更後按下 Republish。按下之後發生兩件事，官方把它們寫得很清楚：新任務會用到更新後的設定，而既有的任務保留自己的狀態。這句話的實務含義是 Republish 不會中斷任何正在跑或已完成的任務，只是悄悄改變了之後每個新任務的出生地。但不影響既有任務，不等於對團隊零影響。共用環境的重大設定變更，特別是網路、憑證、OIDC、VPN 這一類，會直接改變團隊成員之後新任務的起點，仍應記錄變更內容、讓該知道的人知道。個人的環境改完就發布，可以像程式碼一樣高頻迭代；團隊共用的環境，多一道留話的通知手續，是把它當資產經營的一部分。

還有一個方向性的事實要釘死，官方環境模式文件寫得不含糊：任務裡的檔案修改不會更新可重複使用的環境，想改變任務的起點，必須重新發布環境的設定。這構成一條單行道：設定只能從環境流向任務，不能從任務倒流回環境。很多人以為在某個任務裡把環境弄好了，環境就自動變好了，這是本機直覺的殘留。辨別自己想做的到底是哪一種，一個簡單的問句：這個改動，是只有這個任務需要，還是之後每個任務都該有？前者留在任務裡，後者寫回環境。養成這個分流習慣，環境才會越用越順，散落的設定也才有收進軌道的一天。

環境可以私有，也可以共用，這是它作為團隊資產的另一面。官方機制是環境的隱私設定裡有一個「誰可以使用」的選項，設成你的工作區並儲存（環境尚未發布的話再發布一次），工作區裡的人就能用這個環境開任務。邊界畫得相當細：每個任務的工作檔案是分開的，能使用設定不代表能鑽進別人的任務；建立與編輯工作區共用環境的能力，由「管理工作區環境」這個權限控制；儲存庫存取與個人連線，則取決於執行任務的那個帳號。換成白話：共用的是廚房，不是彼此的鍋，而且誰能改建廚房、誰能開火，各有各的鑰匙。團隊導入時把這三層講清楚，能省掉大量「為什麼我看不到」「為什麼他連不上」的往返。

企業環境還有一個把環境推進日常通訊流程的用法值得知道：官方文件寫到，在已啟用 Cloud delegation 的 ChatGPT Enterprise workspace 裡，可以直接從 Slack 或 Microsoft Teams 請 ChatGPT 處理某個儲存庫的工作，Codex 會挑一個工作區共用的環境來執行。這個設計把「挑環境」的步驟整個藏了起來，交辦的人不必知道環境的存在，照樣把工作送進雲端。但藏起來不等於不重要，環境的品質仍然是每個任務品質的天花板，越是這種感覺不到基礎設施的用法，維護環境的人越該把設定顧好，因為沒有人會在出事之前想起它。

存取設定這一塊，環境變數與網路憑證的區別是最值得學的一課，因為它們看起來都像「填個值」，安全模型卻完全不同。官方定義：環境變數是程式必須直接讀取的值，會直接傳給程式；網路憑證則是傳送給特定 HTTPS 服務的認證資料，程式拿到的是佔位符，真正的值由代理伺服器在允許的目的地上代換，而且代換只作用在 443 埠的 HTTPS 流量、涵蓋設定與任務兩個階段，原始憑證永遠不會落到本機程序或檔案裡。把這個區別記住，分類的判準就只剩一句話：程式需不需要直接讀到原始值。資料庫連線字串，或者 SDK 必須直接讀取的 API 金鑰，都該放環境變數，因為程式拿不到原始值就動不了；只有能交給代理伺服器、在特定 HTTPS 目的地代換的憑證（例如套件 registry 或 API 的 token），才適合放網路憑證。儲存環境層級的網路憑證時，官方機制是把該憑證對應的目的地加入受限網路政策的允許範圍，憑證與目的地綁定；這不代表整個環境的對外連線就此打通，其他網域能不能連，仍取決於整體允許清單怎麼審、怎麼開。

更外圍的連線選項知道存在即可：OIDC 可以讓任務換取存取雲端資源的短期憑證，屬於 Enterprise 工作區按需求申請開通的功能；VPN 目前支援的供應商是 Tailscale，驗證金鑰需要同時開啟可重複使用與臨時性兩個屬性。這些是環境可以掛上的進階配件，個人使用者碰到需要它們的場景時，再回官方文件對細節，日常的建立、發布、複用、更新用不到它們。

任務驗收三件事：完成訊息只是檢查的起點

環境備妥、任務送出、Codex 回報完成，接下來才是品質真正被決定的時刻。官方對任務收尾的流程描述是：檢視被改變的檔案並檢查結果，要求後續修改，準備好了再提交或開 Pull Request。順序上有個重點：檢查在提交之前，官方把這個順序寫成了建議流程。把驗收收斂成三件事，每件都有明確的檢查動作與不通過的處置。

第一件事，看檔案差異，確認只改了預定的內容。打開任務的檔案變更清單，逐檔對照修改前後的內容，問自己兩個問題：該改的有沒有改到，不該動的有沒有被動到。預定改兩段文案的任務，擴散成幾十個檔案的變更，就算內容看起來都有道理，也值得先問原因再決定留不留。看不懂程式碼不是免檢的理由，把標準降一半就行：請用我看得懂的方式，逐項解釋這些修改，說明每項修改會改變什麼畫面或行為。這句句式的關鍵在「對回實際檔案」四個字，解釋必須能對照到具體的檔案與行，不能只是一段聽起來合理的摘要；答不出對應關係的解釋，本身就值得追問。與任務來回修正的對話技巧，〈Codex 零起點提問框架〉有整套方法可以借用。

第二件事，看測試與檢查結果，而且要把「沒有測試」與「測試全部通過」分開。翻任務實際執行了哪些檢查、結果是成功還是失敗，如果專案本來就沒有自動化測試，就要求它說清楚能檢查到哪裡、不能檢查哪裡。這兩種狀態在結案報告裡看起來都很平靜，含義卻天差地遠：前者是誠實的邊界聲明，後者是驗證過的品質。把混過去的「沒有測試」當成「通過」，等於把未爆彈貼上合格標籤。這裡還有一個雲端特有的坑：官方文件在目前限制裡列明，雲端環境尚不支援電腦操作與瀏覽器操作。推論隨之而來：互動式的瀏覽器與電腦操作型驗收，雲端任務自己做不了，它改完了網頁，沒辦法自己打開瀏覽器點點看；非互動的證據它仍生得出來，例如建置與測試的成敗、執行過程的日誌。截圖是例外中的例外：除非專案環境已經裝了 Playwright、Chromium 這類 headless 工具，雲端任務才可能用命令列自己產出畫面截圖，而且產出的終究是靜態畫面，不是互動操作。所以改版面、改互動的任務，最終的畫面確認仍必須由你把成果拉下來、在自己機器上跑起來親眼確認，或交給本機與桌面 App 側的畫面工具代勞。會操作電腦畫面的 Computer Use 與拍照提問的 appshots 屬於桌面 App 側的工具箱，跟雲端環境是不同入口的能力，分工的細節可以回〈Codex Appshots 與畫面提問〉對照。不要讓「雲端跑完了」掩蓋「畫面沒人看過」這個缺口。

第三件事，保存成果，再決定要不要開 Pull Request。檢查滿意的修改，commit 進儲存庫留下可追溯的版本，要進入協作流程就開 PR 讓人審。兩個觀念先立正：commit 是把你這組變更記錄成版本，PR 是提出合併的請求，開了不等於合併了，合併了也不等於上線了。但有一條地雷要主動排查：如果專案設有自動部署，例如儲存庫掛了 CI/CD，合併到主分支可能直接觸發正式環境的部署，實際走〈用 Codex 架站的部署實例〉這類流程的專案尤其如此。所以合併之前，先確認專案的發布規則：哪個分支會自動上線、部署到哪個環境、有沒有人該在通知名單裡。把合併當成一個需要簽核的動作，別讓它淪為收尾的儀式感，這個習慣在雲端工作流裡特別重要，因為雲端讓開 PR 變得太順手，順手到容易忘記它後面掛著什麼。

用一個最小的例子把三件事串起來。假設任務是把首頁標題與自我介紹兩段文字換掉，其他一律不動。結案時你打開差異清單，先確認變更只落在預定的那一個檔案、只動了那兩處文字；再看它回報的檢查，若它說專案沒有自動化測試可跑，就要求它列出實際執行過的替代檢查，例如語法檢查或建置流程有沒有通過；接著自己把改好的頁面在本機跑起來，親眼確認標題換了、按鈕還能按、版面沒有跑掉。三關都過，才 commit，才考慮開 PR。這個例子看起來瑣碎，但驗收的紀律正是靠一次次瑣碎的完整走過建立起來的，跳過任何一關，那關遲早會用更大的代價把你找回來。

卡住排查：三軸診斷法與七症狀快查表

雲端任務卡住時，先做結構化的排查，勝過反覆重送同一段指令。幾乎所有「本機可以、雲端不行」的卡點，都能歸進三條軸線：檔案在不在雲端儲存庫裡、工具裝了沒、服務授權了沒。這三軸分別對應環境定義的三個元素，等於把官方的環境模型直接拿來當診斷框架用。逐軸問下去：這個檔案有沒有被 commit 並 push 進環境連結的儲存庫？這個工具或命令，有沒有被寫進 Install script 或安裝進環境？這個服務，環境有沒有拿到連它的憑證與網路許可？三個問題各自的答案，會把你的下一步限制在一個很小的範圍裡，這比盯著錯誤訊息憑感覺快得多。

七個最常見的症狀，對照三軸與第一個動作，整理成快查表。用的時候建議照著表的順序走，先確認缺的是哪一軸，再動手修，修環境層的問題記得收尾要重新發布才會生效。

表裡有兩列值得展開。授權軸那一列的「分開檢查」是精髓：網路層允許連到某個網域，與服務層給了這個帳號存取權，是兩個獨立的閘門，全開了才通，官方的網路憑證機制甚至刻意把這兩層設計成不同的設定面。環境的網路設定預設附帶套件管理器的白名單，讓安裝依賴這件事開箱即用，超出這個範圍的網域要自己加進允許清單，所以「下載套件很順、連自家 API 卻失敗」是相當典型的授權軸症狀，不是網路壞了，是白名單還沒開到那裡。skill 那一列則是高頻誤區：官方文件明說，你本機電腦上的個人 skill 不會同步到雲端環境，能被雲端用的是放在儲存庫裡的 skill。所以依賴個人工作流的人上雲端前要有心理準備，你習慣的那套提示詞整理與自動化，要跟著專案一起進儲存庫才算數。這個「放在儲存庫讓它跟著專案走」的思路，與〈給 Codex 一份專案說明書〉談的 AGENTS.md 是同一套哲學：會跟著儲存庫走的指示，才有跨機器跨環境的可攜性，活在個人機器上的設定，永遠只有一台機器的壽命。

用量那一列也要留意分寸。方案與額度決定了哪些入口與功能對你的帳號開放，官方也明言功能推出與方案內容會調整，畫面上看不到某個選項時，先確認方案等級與版本，不要直接下「壞掉了」的結論。跨工具的額度算法與延長用量的思路，〈ChatGPT 與 Claude 的額度算法〉有完整整理，概念是相通的，Codex 的即時額度仍以官方方案頁與帳號內的用量顯示為準。

手機上的雲端任務：與 Remote 的分界線

手機打開 Codex 能做的事，剛好落在前面鋪陳過的限制上：可以挑一個已發布的環境開新任務，可以看著既有任務的進度、核准它等待的權限、跟它繼續對話，但建立與發布環境要回網頁或桌面 App。這個分工本身不難記，難的是它旁邊站著一個容易混淆的兄弟：Remote。兩者的差別用一句話就能釘住：雲端任務的工作跑在 OpenAI 管理的環境裡，你的手機只是遙控與顯示；Remote 則是手機遙控你自己的某台機器，任務實際跑在那台機器上，讀的是那台機器的檔案與工具。Remote 的連線拓撲要畫準：手機先連的，是自己配對過、保持醒著、登入同一帳號的 Mac 或 Windows 桌面 App 主機；專案放在 SSH 主機或其他遠端開發環境時，是由那台桌面主機再連過去，不是手機直接遙控遠端機器。桌面主機休眠或斷網，遠端存取就跟著停，官方對 Remote 的要求正是主機保持醒著並連網。

分界線畫出來之後，選擇就變成一道簡單的題目：工作需要的東西在雲端環境裡備得齊，用手機看雲端任務，電腦關了都不影響；工作離不開你那台機器上的檔案、授權或工具，才需要 Remote，而且要接受主機必須常開的代價。一個常見的誤判是把「我在手機上操作」當成「任務在雲端」，於是誤以為闔上筆電它還會跑，結果它停了；反方向的誤判則是為了背景執行而特地留一台電腦不關機，卻不知道同樣的需求用雲端環境就能滿足。Remote 的完整設定流程、主機條件與配對細節，站上的〈Codex 進階操作與遠端接手〉有逐段拆解，這裡只把分界線講清楚，因為選錯邊的挫折感，通常不是工具的問題，而是模型套錯了。

把生命週期當迴圈經營，而非一次性設定

四個階段走完，回頭看會發現它們構成一個迴圈：建立的產出餵給發布，發布的封存餵給複用，複用中發現的改善點回饋給更新，更新的重新發布又成為下一輪任務的起點。會用雲端環境的人與用得好的人，差別就在有沒有把這個迴圈轉起來。判斷自己有沒有轉起來，三個訊號可以自檢：新任務的前幾輪對話，是不是還在處理「裝東西、找檔案」這類本該由環境吸收的雜務；團隊成員開任務，是不是各自描述著同一套略有出入的設定；曾經在某個任務裡手動修好的環境問題，是不是又在新任務裡出現了一次。任何一個訊號亮起，都代表有該寫回環境的東西還散落在任務裡。

環境的數量也順勢談一下。一個環境對應一組儲存庫與一套設定邏輯，所以切分環境的自然單位是專案的性質，與任務跑了幾次無關：同一個產品的前後端可以共用一個環境，性質迥異的兩個專案就該分開，避免 Install script 塞成一鍋粥。發布狀態與隱私設定定期巡一遍，未發布的殼、早就沒人用的共用環境，清一清，選單乾淨，團隊的選擇負擔就小。

收在一個立場上。雲端環境把「準備工作場所」這件事從每一次任務裡抽出來，變成可以累積、可以共用、可以迭代的資產，這是它比本機多出來的那一整層價值；但資產不會自動增值，它考驗的是你願不願意在第一次多做十分鐘、在每次卡住時多想一步「這該不該寫回環境」。把紀律建立起來，環境會越用越順，任務會越交越快；把紀律省下來，雲端就只是一個每次都要重新設定的執行位置。工具已經把迴圈畫好了，轉不轉，看你。